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