Is Azure Access Control and WIF suitable when some of the relying parties might not be .Net based

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 I开发者_运维百科dentity 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?

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:

• Identity Training Kit
• Claims based Identity Guide (http://claimsid.codeplex.com)

For a very quick intro, check Scott's latest webcast: http://scottdensmore.typepad.com/blog/talks.html

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.

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?