SAML WebSSO & Federation Made Easy

 

This week I found myself on a SalesForce/SAML/Federation journey which turned out to be very enlightening. Until a few days ago I really had no idea how SAML or Federation worked and it took me a few hours to get my head around it, so I’m going to try explain SAML in a way that’s easy to understand.

SAML 2.0 (Security Assertion Markup Language).

2 Companies:
Company A (Service Provider – SP) has a web application
Company B (Identity Provider –  IdP) has a database of people who need to access Company A’s application

We have a few options here:

  1. Company A could create a new database of people with usernames and passwords within the web application
  2. We could synchronise the database of people including their usernames and passwords from Company B to Company A
  3. We could make a link from the web application to Company B’s database of people and do lookups in real-time
  4. We could tell the web application at Company A to trust users who come from Company B

Options 1 through 3 are pretty crappy.  Option 4 is called federation and it’s cool.

Here’s what happens (part analogy, part reality):

Both companies have a pair of keys. A public key and a private key.  Once something is locked with the private key only the corresponding public key can open it.  Company A has a copy of Company B’s public key and vice versa.

A user in Company B tries to access the web application at Company A.  The web application looks for a cookie in the user’s browser to see if he is already authenticated, he is not so the web application (SP) redirects the browser to Company B’s IdP, telling him – “Go and get a ticket!”

The browser goes to Company B’s IdP who authenticates the user against Company B’s database of users. The IdP at Company B locks the user’s employee ID with his private key, gives it to the browser and tells him – “Here’s your ticket now go back to the SP you came from!”

The browser goes back to the web application (SP) at Company A and presents his ticket.  The SP uses Company B’s public key to unlock the ticket.  The web application says to himself –  “It works! This user MUST have come from Company B because otherwise this public key could NOT have unlocked this ticket. And look, the ticket contains an employee ID and I have a rule that says that this employee ID is allowed access!” And so the web application gives the browser a cookie which allows him access.

 

In SAML the ticket is called an Assertion.  In this case we sent the Employee ID but any other user-unique attribute could be used, it just needs to be agreed between the 2 parties.

In reality the web application might not support SAML directly but instead maybe protected by a federation product which takes care of the SAML SP stuff.  The IdP stuff will also likely be handled by a federation product which is backed by some kind of LDAP directory or maybe SQL.  The browser cookie stuff mentioned above is outside the scope of SAML but I included it for completeness – It’s typical of how these things work.

 

The neat thing about federation is that you don’t need any links between Company A and Company B. Once the trust is established everything else takes place “browser to SP” and “browser to IdP” through a series or re-directs and http POSTs.

 

Ok so that’s SAML.  Actually there are a lot more parts to it than that but that’s the way it’s most commonly used today i.e. for WebSSO.  Now that you have the concept, you can dig into the technical details.

I found Google’s explanation useful:
http://code.google.com/googleapps/domain/sso/saml_reference_implementation.html

and Wikipedia :

http://en.wikipedia.org/wiki/SAML_2.0

 

The best way to learn this stuff is to give it a go.  Check out Shibboleth which is an open source SAML SP and IdP implementation.  I’ve got the Shibboleth SP side talking to ADFS 2.0  as the IdP but I haven’t played with the Shibboleth IdP yet.

 

Next time I’ll show you how to put SAML to use with Active Directory Federation Services 2.0 and cloud provider SalesForce.  In the mean time feel free to ask questions or make corrections.

, , , , , ,

10 Responses to SAML WebSSO & Federation Made Easy

  1. http://www.jdspropertiesstl.com/ June 5, 2016 at 2:35 am #

    Personnellement, je disais ça pour la bonne et simple raison que je reçois encore et toujours quelques courriers de lecteurs qui cherchent « Comment faire pour réussir à draguer toutes les filles ? »Et en même temps, ça ne m’étonne pas vraiment de leur part quand je vois les intitulés marketing de certains produits qui vont dans ce sens.

  2. Ivo April 11, 2015 at 9:37 am #

    I AM the system administrator. Who do I call?

    – Call to Lord

  3. John Edwards March 13, 2014 at 6:06 am #

    Hi Rhys,

    Thank you for the explanation. One thing i was unsure about was the following:

    “The browser goes to Company B’s IdP who authenticates the user against Company B’s database of users. The IdP at Company B locks the user’s employee ID with his private key, gives it to the browser and tells him – “Here’s your ticket now go back to the SP you came from!””

    Does this mean that the employee id in company b needs to be stored as the user id for company a? This would imply that a sychronisation of user id’s is still require across applications.

    • RhysGoodwin March 17, 2014 at 9:05 am #

      Hi John, thanks for stopping by. Yes the user would need a record in Company A’s application. This would typically be in the form of a user profile within the application which controls what the user is allowed to access within the app. Even within a purely AD sso environment users would typically need to be added to the individual application.

      This could be done manually, with some kind of synchronization or with user provisioning via SAML. For example SalesForce supports Just-in-time provisioning with SAML. Basically when you submit a valid SAML token and a user doesn’t exist in SalesForce one will be created on the fly with some default permissions.

      HTH
      Cheers,
      Rhys

  4. Oleg Cohen March 29, 2013 at 3:28 am #

    Here is a blog entry I wrote comparing WS-Federation to SAML. You may find it useful in comparing the two.

    http://www.assurebridge.com/sso/saml-vs-ws-federation-for-single-sign-on/

    Thanks,

    Oleg

    • RhysGoodwin March 31, 2013 at 10:33 am #

      Thanks Oleg. Great article.
      Cheers,
      Rhys

  5. Oliver Wulff February 21, 2012 at 3:07 am #

    Hi there
    I’m wondering what you think about the WS-Federation passive requestor profile (browser). The benefit I see is the re-use of the WS-Trust semantic and the decoupling to a specific SAML protocol version.
    Instead of a samlp:response you get the RSTR of the WS-Trust STS. An additional benefit is the re-use of the STS for Web Services communication. Attribute based access control can be achieved by the Claims dialect standardized by WS-Trust and WS-Federation.
    What do you think?

Trackbacks/Pingbacks

  1. (2012-05-06) Setting Up SALESFORCE.COM With ADFS v2.0 « Jorge's Quest For Knowledge! - May 6, 2012

    […] my last post I went over the basic concept of federation using SAML 2.0, today I’ll show you how to configure […]

  2. Claims Based Authorization And Federation Explained The Easy Way « Jorge's Quest For Knowledge! - May 6, 2012

    […] ORIGINAL SOURCE: SAML WebSSO & Federation Made Easy […]

  3. SalesForce SSO with ADFS 2.0 – Everything you need to Know - April 4, 2011

    […] About « SAML WebSSO & Federation Made Easy […]

Leave a Reply