简短的答案通常是“是”,但当然还有更长的答案:-)。
在 ACS 与本地数据库表中存储用户信息(名称标识符除外)是否有意义?
是的,这可能是有道理的。但出于优化目的,您可能会在其他地方(应用程序本地)保留一些用户配置文件信息的副本。ACS 规则信息将是“主记录”,您将在获得令牌时更新本地存储中的值并检查是否有更改。
听起来您可以在其中创建无限的规则组和规则。那是对的吗?
不,“无限”是一个很大的数字。命名空间、依赖方和规则的数量都有限制。检查文档。ACS 还支持“级联”转换,这可以帮助您减少规则数量。
例如:
- 电子邮件:eugeniop@mail.com -> 公司:Contoso
- 公司:Contoso -> 语言:英语
每当发出类型为“Company”、值为“Contoso”的声明时,都会触发第二条规则。
然后你可以拥有:
- 电子邮件:rob@othermail.com -> 公司:Contoso
“语言”声明将被自动添加。
我将与公司内部的不同公司和用户打交道。为每个公司创建一个规则组,然后为每个用户制定规则是一个明智的选择吗?
在多租户环境中,每个租户都有一个依赖方可能会更好。这就是我们在示例 7(与多个合作伙伴的联合)中所做的,可在此处获取:http ://claimsid.codeplex.com
看起来 API 非常健壮,并且可以通过注册页面等自动完成。正确还是不正确?
是的
是否可行并建议对 ACS 运行查询以返回有关用户的信息(例如,在他们离线时查询他们的电子邮件地址以向他们发送有关某事的消息)
这是可能的。但是,ACS 中没有“用户”的概念。所以你必须从规则中解码。你不能有像“GetUserprofile(字符串用户)”这样的电话
您能否从 ACS 获取大量信息以用于报告目的?
API 支持批量信息,但对于报告,最好将信息复制到您自己的数据库中。
最后一个想法:今天的 ACS 规则引擎非常简单,只进行简单的转换(加上级联),但与今天的 ADFS 可以做的相比,规则可能非常复杂(例如数据库查找等)