Azure ACS 并在其上与本地存储用户信息？
我正在使用 Azure ACS 并将其合并到我的 .NET 4.0 网站的 SSO 策略中。我在规则组页面上看到可以存储一堆不同的声明并将其传递回 RP（例如国家/地区、街道地址、电话等）。看起来您还可以返回您想要创建的任何声明类型。这让我思考了与存储用户信息相关的许多问题：
- 在 ACS 与本地数据库表中存储用户信息（名称标识符除外）是否有意义？
- 听起来您可以在其中创建无限的规则组和规则。这是正确的吗？
- 我会与不同的公司和公司内部的用户打交道。为每个公司创建一个规则组，然后为每个用户制定规则是否是明智的选择？
- 该 API 似乎非常强大，并且可以通过注册页面等自动完成此操作。正确还是错误？
- 是否可行并建议对 ACS 运行查询以返回有关用户的信息（例如，在用户离线时查询他们的电子邮件地址，向他们发送有关某件事的消息）？
- 您能否从 ACS 中获取批量信息以用于报告目的？
I'm working with Azure ACS and incorporating it into an SSO strategy for my .NET 4.0 website. I see on the Rule Groups page that a bunch of different claims can be stored and passed back to the RP (e.g. country, streetaddress, phone, etc.). It looks like you can also return back any claim type you want to create. This got me thinking about many questions relating to storing information for users:
- Does it make sense to store user information (other than the nameidentifier) in ACS vs local database tables?
- It sounded like you could make unlimited rule groups and rules inside of them. Is that correct?
- I would be dealing with different companies and users inside the company. Would creating a rule group for each company and then making rules for each user be a wise choice?
- It appears that the API is pretty robust and would enable this to be done automatically as a result of a sign up page, etc. Correct or incorrect?
- Would it be feasible and recommended to run a query against ACS to return information back about a user (e.g. query for their email address when they're offline to send them a message about something)
- Could you grab bulk information for reporting purposes off of ACS?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
简短的答案通常是“是”，但当然还有更长的答案:-)。
将用户信息（名称标识符除外）存储在 ACS 与本地数据库表中是否有意义？
是的，这可能有道理。但出于优化目的，您可能会在其他地方（应用程序本地）保留一些用户个人资料信息的副本。 ACS 规则信息将是“主记录”，每当您获得令牌并检查是否发生更改时，您都会更新本地存储中的值。
听起来您可以在其中创建无限的规则组和规则。这是正确的吗？
不，“无限”是一个很大的数字。命名空间、依赖方和规则的数量都有限制。检查文档。 ACS 还支持“级联”转换，这可以帮助您减少规则数量。
例如：
每当发出“Company”类型、值“Contoso”的声明时，就会触发第二条规则。
然后您可以：
将自动添加“语言”声明。
我将与公司内部的不同公司和用户打交道。为每个公司创建一个规则组，然后为每个用户制定规则是明智的选择吗？
在多租户环境中，每个租户都有一个依赖方可能会更好。这就是我们在示例 7（与多个合作伙伴联合）中所做的事情：http://claimsid.codeplex.com
看来 API 非常强大，并且可以通过注册页面等自动完成此操作。正确还是错误？
是的
是否可行并建议对 ACS 运行查询以返回有关用户的信息（例如，在用户离线时查询他们的电子邮件地址以向他们发送有关某事的消息）
这是可能的。但是，ACS 中没有“用户”的概念。所以你必须从规则中解码它。您不能进行像“GetUserprofile( string user)”这样的调用
您可以从 ACS 中获取批量信息以用于报告目的吗？
API 支持批量信息，但为了报告，最好在您自己的数据库中复制信息。
最后一个想法：今天的 ACS 规则引擎非常简单，只执行简单的转换（加上级联），但与今天的 ADFS 可以做的事情相比，这没什么可比的，其中规则可能非常复杂（例如数据库查找等）
The short answer is generally "yes", but of course there's a longer answer :-).
Does it make sense to store user information (other than the nameidentifier) in ACS vs local database tables?
Yes it could make sense. But for optimization purposes you might keep a copy of some of the user profile information somewhere else (local to the app). ACS rules information would be the "master record" you would update the values in your local store whenever you get a token and check whether there've been changes or not.
It sounded like you could make unlimited rule groups and rules inside of them. Is that correct?
No, "unlimited" is a big number. There are limits in the number of namespaces, relying parties and rules. Check the documentation. ACS also supports "cascading" transformations, which can help you reduce the number of rules.
For example:
The 2nd rule will be triggered whenever a claim of type "Company", value "Contoso" is issued.
Then you can have:
The "language" claim will be automatically added.
I would be dealing with different companies and users inside the company. Would creating a rule group for each company and then making rules for each user be a wise choice?
In a multi-tenant environment, it might be better to have a Relying Party per tenant. This is what we do in sample 7 (Federation With Multiple Partners) available here: http://claimsid.codeplex.com
It appears that the API is pretty robust and would enable this to be done automatically as a result of a sign up page, etc. Correct or incorrect?
Yes
Would it be feasible and recommended to run a query against ACS to return information back about a user (e.g. query for their email address when they're offline to send them a message about something)
It is possible. However, there's no concept of "user" in ACS. So yuou would have to decode that from the rules. You can't have a call like "GetUserprofile( string user)"
Could you grab bulk information for reporting purposes off of ACS?
The API supports bulk info, but for reporting it might be better to have replicated information on your own database.
One last thought: ACS rules engine today is very simple and only does simple transformations (plus cascading), but nothing compared to what ADFS can do today, where rules can be really complex (e.g. db lookups, etc)