当某些依赖方可能不是.Net时,Azure Access Control和WIF是否合适

Question

我们目前在不同的域上有一些.Net应用程序,每个域都有不同的成员资格.我们正在转向使用单点登录(并且希望单点注销)和Azure上托管的集中成员身份的联合登录.

我们的自然选择似乎是为Azure的访问控制创建我们自己的身份提供者,我们所有的站点都将使用WIF进行身份验证,但非.Net站点可能会在将来对此进行身份验证.

这仍然是一条可以接受的路线吗？

Answer 1

ACS是"联盟提供者".它基本上允许您的"依赖方"(您的应用程序)将身份验证委派给它.

如果您愿意,ACS本身可以信任许多"身份提供者",包括您的身份提供者.目前(ACS V2)支持WS-Federation和OpenID(用于网站),WS-Trust和OAuth(用于Web服务).这些是"协议".ACS支持2种令牌格式:SAML(1.1和2.0)和SWT.它还预先配置了Google,Yahoo!,Facebook和LiveID.

如果您的应用信任ACS,那么您可以接受任何这些服务中具有帐户的用户.ACS可以使用支持任何协议的"任何"IdP.

WIF是.NET上的一个框架,用于"声明启用"您的应用程序,并在ASP.NET(和ASP.NET MVC)和WCF等应用程序堆栈中无缝工作.它可以在其他应用程序堆栈上工作,但它需要互操作.但是,每个平台通常都有一个WIF等价物,只要它符合标准(例如WS-Fed,SAML令牌等),它就可以工作.

Interop也是两种方式.例如:依赖于非MSFT身份提供者的ACS/ACS的非.NET应用程序.

如果您想保留您的成员资格数据库以进行身份​​验证(这意味着您仍然拥有用户名/密码),您可以使用STS(使用WIF构建)将其包装起来并将其添加到身份提供者列表中.那么任何应用程序(.NET或不是)都可以使用基于它的身份验证:

当然,您可以将两者结合起来:让您的应用程序信任ACS,然后ACS信任您的IdP(除了其他IdP).这为您提供了额外的灵活性

通常,如果在基于.NET的网站上使用WIF,则无需编写太多代码(如果有).一切正常.

所有这些的例子都可以在这里找到:

• 身份培训套件
• 基于声明的身份指南(http://claimsid.codeplex.com)

如需快速入门,请查看Scott的最新网络广播:http://scottdensmore.typepad.com/blog/talks.html