基于

Question

目前我们在每个单独的成员不同领域的一些.Net应用程序是Azure的访问控制和WIF适合当一些依赖方可能不被.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令牌等）的功能。

互操作也是双向的。例如：依赖于非MSFT身份提供者的依赖ACS/ACS的非.NET应用程序。

如果您想保留您的会员资格数据库以进行身份​​验证（这意味着您仍然有用户名/密码），则可以使用STS（使用WIF构建）将其包装并将其添加到身份提供商列表中。然后任何应用程序（。NET与否）可以根据它使用的身份验证：

当然，你可以结合两种：有你的应用程序的信任ACS，然后ACS信任您的IDP（除其他国内流离失所者）。这给你额外的灵活性。

一般来说，如果您在基于.NET的网站上使用WIF，则无需编写大量代码（如果有）。一切正常。这一切

例子都可以在这里：基于

• 身份的培训工具包
• 索赔身份指南（http://claimsid.codeplex.com）

对于一个非常快速的介绍，检查斯科特的最新网络直播：http://scottdensmore.typepad.com/blog/talks.html

Answer 2

OUCH我被带走了，并注意到依赖方部分后我写了答案！最后一部分虽然成立。 ACS使用REST并发布SAML or SWT tokens，因此理解它们的任何应用程序都可以使用ACS。

WIF和ACS不需要在客户现场.NET。事实上，最简单的使用方法是通过AD Federation Services来验证用户的AD域并将SAML令牌传递给ACS。

事实上，ACS SDK包含有关配置ACS使用Google,Facebook和Yahoo作为标识提供程序的文章。

如果您需要针对不同系统（例如内部SSO系统，数据库等）进行身份验证，您可以编写自己的身份提供程序来验证用户身份并将适当的令牌发送给ACS。由于ACS使用REST API，因此您可以使用任何您喜欢的平台或语言来创建提供商。

Answer 3

如果通过“非基于.NET”，你的意思是类似Java应用程序，你可以联合Java（例如使用OpenSSO或PingFederate）和ADFS。

ADFS可以与ACS联合。

有许多的ADFS 2.0 Step-by-Step Guides to interoperability

我不知道，如果你能删除ADFS并简单地用这些其他产品在其位联合ACS？任何意见？