Home/ Questions/Q 4343236
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-21T11:43:24+00:00

We currently have a few .Net applications on different domains with separate membership on

  • 0

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?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    ACS Simple

    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:

    enter image description here

    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

    • 0