当某些依赖方可能不基于 .Net 时，Azure 访问控制和 WIF 是否合适
目前，我们在不同的域上有一些 .Net 应用程序，每个应用程序都有单独的成员资格。我们正在转向具有单点登录（并且希望单点注销）的联合登录以及托管在 Azure 上的集中式会员资格。
对我们来说，自然的选择似乎是为 Azure 的访问控制创建我们自己的身份提供程序，我们的所有站点都将使用 WIF 进行身份验证，但将来非 .Net 站点可能必须使用此身份验证。
这仍然是可以接受的路线吗？
We currently have a few .Net applications on different domains with separate membership on each. We are moving to a federated login with single sign-on (and hopefully single sign-off) and a centralised membership hosted on Azure.
The natural choice to us seemed to be creating our own Identity Provider for Azure's Access Control which all of our sites would authenticate with WIF but there might be the possibility of non .Net sites having to authenticate with this in the future.
Is this still an acceptable route to take?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
ACS 是“联邦提供商”。它基本上允许您的“依赖方”（您的应用程序）将身份验证委托给它。
ACS 本身可以信任许多“身份提供商”，如果您愿意，也可以包括您的身份提供商。目前（ACS V2）支持 WS-Federation 和 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 令牌等），它就可以工作。
互操作也是双向的。例如：依赖 ACS 的非 .NET 应用程序/依赖非 MSFT 身份提供商的 ACS。
如果您想保留您的会员数据库用于身份验证（这意味着您仍然拥有用户名/密码），您可以使用 STS（使用 WIF 构建）将其包装并将其添加到身份提供商列表中。然后任何应用程序（.NET 或非 .NET）都可以使用基于它的身份验证：
当然，您可以将两者结合起来：让您的应用程序信任 ACS，然后 ACS 信任您的 IdP（除了其他 IdP）。这为您提供了额外的灵活性。
一般来说，如果您在基于 .NET 的网站上使用 WIF，则无需编写太多代码（如果有）。一切正常。
所有这些的示例都可以在这里找到：
如需快速介绍，请查看 Scott 的最新网络广播：http://scottdensmore.typepad.com/blog/talks.html
ACS is a "Federation provider". It basically allows your "relying parties" (your applications) to delegate authentication to it.
ACS can itself trust many "identity providers", including yours if you wanted. Currently (ACS V2) supports WS-Federation & OpenID (for web sites), WS-Trust & OAuth (for web services). These are the "protocols". ACS supports 2 token formats: SAML (1.1 & 2.0) and SWT. It also comes pre-configured with Google, Yahoo!, Facebook and LiveID.
If your app trusts ACS, then you can accept users with accounts in any of those services. ACS can work with "any" IdP that supports any of those protocols.
WIF is a framework on .NET for "claims enabling" your app and works seamlessly in app stacks like ASP.NET (and ASP.NET MVC) and WCF. It can work on other app stacks, but it requires interop. However, each platform usually has a WIF equivalent, and as long as it is compliant with the standard (e.g. WS-Fed, SAML tokens, etc.) it works.
Interop is also both ways. For example: a non .NET app relying on ACS / ACS relying on a no-MSFT identity provider.
If you want to retain your membership databases for authentication (this means you would still have username/passwords), you can wrap it with an STS (built with WIF) and add it to the list of identity provider. Then any application (.NET or not) can use authentication based on it:
Of course you can combine both: have your apps trust ACS and then ACS trust your IdP (In addition to the other IdPs). This gives you additional flexibility.
In general, if you use WIF on your .NET based web site, you don't need to write much code (if any). Everything just works.
Examples of all this are available here:
For a very quick intro, check Scott's latest webcast: http://scottdensmore.typepad.com/blog/talks.html
哎哟我得意忘形了，在写完答案后注意到了依赖方部分！最后一部分仍然成立。 ACS 使用 REST 并发出 SAML 或 SWT 令牌，因此任何应用程序了解他们可以使用 ACS。
WIF 和 ACS 不需要客户站点上有 .NET。事实上，最简单的使用方法是通过 AD 联合身份验证服务 进行身份验证用户针对其 AD 域并将 SAML 令牌传递给 ACS。
事实上，ACS SDK 包含有关配置 ACS 以使用 Google 的文章， Facebook 和 Yahoo 作为身份提供商。
如果您需要针对不同的系统（例如内部 SSO 系统、数据库等）进行身份验证，您可以编写自己的身份提供程序来对用户进行身份验证并向 ACS 发送正确的令牌。由于 ACS 使用 REST API，您可以使用您喜欢的任何平台或语言来创建提供程序。
OUCH I got carried away and notice the relying parties part AFTER I wrote the answer! The last part holds though. ACS uses REST and issues SAML or SWT tokens so any application that understands them can use ACS.
WIF and ACS doesn't require .NET on the customer's site. In fact the easiest way to use it is through AD Federation Services which authenticate users against their AD domain and pass a SAML token to ACS.
In fact, the ACS SDK contains articles on configuring ACS to use Google, Facebook and Yahoo as Identity providers.
If you need to authenticate against a different system (e.g. an internal SSO system, a database, whatever) you can write your own identity provider that will authenticate the user and send the proper tokens to ACS. Since ACS uses a REST API you can use whatever platform or language you like to create your provider.
如果“非基于 NET”是指 Java 应用程序之类的东西，则可以联合 Java（例如使用 OpenSSO 或 PingFederate）和 ADFS。
ADFS 可以与 ACS 联合。
有许多 ADFS 2.0 互操作性分步指南
我不确定您是否可以删除 ADFS 并简单地将 ACS 与这些其他产品联合起来？有什么意见吗？
If by "non NET based", you mean something like Java applications, you can federate Java (e.g. using OpenSSO or PingFederate) and ADFS.
ADFS can federate with ACS.
There are a number of ADFS 2.0 Step-by-Step Guides to interoperability
I'm not sure if you could remove ADFS and simply federate ACS with these other products in its place? Any comments?