Lar*_*ann 6 identity azure claims-based-identity wif acs
我一直在研究Azure访问控制服务(ACS),它看起来特别擅长处理来自异构(可配置)身份提供程序的身份验证.然后还有一些它似乎支持的其他方案(参见例如ACS How-To).
我的问题恰恰相反:为了正确使用它,它真的有助于我理解ACS 不利于什么.ACS有哪些局限性,和/或哪些情况下ACS不合适？
(假设,为了争论,我计划创建一个 - 盈利的) - 公共Web API和相应的网站前端,托管在Azure中 - 即,我确实关心用户身份.如果您愿意,可以进一步假设我的系统将使用.NET构建.)
谢谢!
您不应将ACS用作身份提供者.
偶尔我会看到ACS服务的角色有些混乱.ACS at核心是一个联合提供程序,但是有一种有效的方案,您希望您的后端服务(受信任的子系统)使用共享密钥或证书直接向ACS进行身份验证.这可以使用服务标识来完成.但是,我不止一次看到过要提供多个帐户的ACS方案,这将通过为每个用户创建服务标识来实现.
那不是ACS的设计方式.如果您突然拥有数千名用户,那么使ACS成为权威的源用户目录将无法扩展.ACS提供了一个很好的规则引擎,用于规范来自各种身份提供者的传入声明类型,或者用于简单的授权策略,例如生成角色声明.
但ACS的功能不应与完全供电的目录,身份验证和授权解决方案(如AD和ADFS)混淆.简而言之,ACS不是AD/ADFS的版本.
| 归档时间： |
|
| 查看次数： |
1123 次 |
| 最近记录： |