SSO using SAML2.0 in asp.net

Question

My requirement is to implement SSO using SAML2.0 in asp.net. I do have 2 vendors at my end. Wanna pass the user from one site to other site without logging into the second. I ha

Answer 1

First let's differentiate protocol with token format. I assume you are talking about the protocol and not the token format. But just in case here are the differences:

• SAML 2 token format. This is simply the format of the token that your application will udenrstand. This is supported by WIF out of the box.
• SAML 2 Protocol. This is the HTTP interactions your application will have to understand to get a token in the app. This is not supported by WIF but there is an extension you can download (http://connect.microsoft.com/site1168/Downloads/DownloadDetails.aspx?DownloadID=36088)

On the other hand you have a scenario in which there are multiple identity providers. The book that Wiktor suggested (which I co-authored) explains this scenario in more detail on the Federated Identity with Multiple Partners chapter. I recommend you to read it to get the concepts behind identity federation. Let me give you the short version of the article and some implementation details. There are two ways of solving this:

• Implementing it at the application level. WIF will allow you to trust on more than one identity provider token (this is done with X509 certificates). Then you will have to generate sign in requests for each identity provider depending on a url (like https://idp1.yourapp.com or https://yourapp.com/idp1) or the user choosing (by having a home page with two links, one for each identity provdier). You will also have to normalize the claims coming from those identity provider (maybe one of them will send you a "name" claim and the other a "upn" claim).

  YourApp --> Identity Provider 1
          \-> Identity Provider 2
  

• Using what is called a "federation provider". This is another server that will issue tokens to your application and it will have the trust relationships against your identity provider. Instead of having your application trust the two identity providers, you trust only on your federation provider and the fed provider will trust the identity providers. It's a trust chain.

  YourApp --> Federation Provider --> Identity Provider 1
                                  \-> Identity Provider 2
  

This architecture allows you to:

• grow your identity providers without touching your application
• if you later have a second application you just copy your implementation of the first one
• you get single sign on for free
• you get a claim transformation engine (if you use something like ADFS)
• if you use something like ADFS you get SAML 2 protocol built in (instead of having to implement it by hand with the extension mentioned below)

Of course the downside is that you now have something else to mantain (the ADFS server).