我正在使用 Azure ACS 并将其整合到我的 .NET 4.0 网站的 SSO 策略中。我在规则组页面上看到可以存储一堆不同的声明并将其传递回 RP（例如国家、街道地址、电话等）。看起来您还可以返回您想要创建的任何声明类型。这让我想到了许多与为用户存储信息有关的问题：
【问题讨论】：
标签： azure claims-based-identity acs
简短的回答通常是“是”，但当然还有更长的回答:-)。
在 ACS 与本地数据库表中存储用户信息（除了名称标识符）是否有意义？ 是的，这可能是有道理的。但出于优化目的，您可能会在其他地方（应用程序本地）保留一些用户配置文件信息的副本。 ACS 规则信息将是“主记录”，您将在获得令牌时更新本地存储中的值并检查是否有更改。
听起来你可以在其中创建无限的规则组和规则。对吗？ 不，“无限”是一个很大的数字。命名空间、依赖方和规则的数量都有限制。检查文档。 ACS 还支持“级联”转换，这可以帮助您减少规则数量。
例如：
只要发出类型为“公司”、值为“Contoso”的声明，就会触发第二条规则。
那么你可以：
将自动添加“语言”声明。
我将与公司内部的不同公司和用户打交道。为每个公司创建一个规则组，然后为每个用户制定规则是一个明智的选择吗？ 在多租户环境中，每个租户都有一个依赖方可能会更好。这就是我们在示例 7（与多个合作伙伴的联合）中所做的工作：http://claimsid.codeplex.com
看起来 API 相当健壮，可以通过注册页面等自动完成。正确还是错误？ 是的
是否可行并建议对 ACS 运行查询以返回有关用户的信息（例如，在他们离线时查询他们的电子邮件地址以向他们发送有关某事的消息） 有可能的。但是，ACS 中没有“用户”的概念。所以你必须从规则中解码。你不能有像“GetUserprofile(string user)”这样的电话
您能否从 ACS 获取大量信息以用于报告目的？ API 支持批量信息，但对于报告，最好在您自己的数据库中复制信息。
最后一个想法：今天的 ACS 规则引擎非常简单，只进行简单的转换（加上级联），但与今天的 ADFS 相比没有什么，因为规则可能非常复杂（例如数据库查找等）
【讨论】：