I'm tasked with developing an SSO system, and was guided towards using the SAML spec. After some research I think understand the interaction between a Service Provider and an ID Provider and how a user's identity is confirmed. But what happens when I redirect the user to another Service Provider? How do I ascertain the user's identity there? Do I send his SAML assertion tokens along with the redirect request? Or does the second Service Provider need to contact the ID Provider all over again?
- Anybody can ask a question
- Anybody can answer
- The best answers are voted up and rise to the top
Ok, it has been a little while for me but I'll try. I have worked with both SimpleSAMLphp and Shibboleth implementations of SAML. SimpleSAMLphp being the easier of the two to setup demo IdPs and SPs.
Anyway, when your user visits another SP's domain that uses the same IdP that they have already authenticated to then you can either have your IdP re-authenticate them by the cookie on their machine or force them to enter their username/password again. You can also configure how long their login session lasts on the IdP.
The way you figure out their identity on the second SP is basically the same way that you would on the first SP. You can configure what user data will be sent to each SP individually, each SP can be sent the same user data or custom user data depending on the needs of that SP.
EDIT RE: Do I send his SAML assertion tokens along with the redirect request? Or does the second Service Provider need to contact the ID Provider all over again?
I believe the SAML spec allows both. I remember that I could have the user visit the second SP's domain where the SP would then hit the IdP to get the assertion tokens or you can have the user visit the IdP first with a query string identifying the second SP and then redirect the user to the second SP along with the assertion tokens.
EDIT#2 By the way I would recommend NOT writing your own implementation of SAML unless you have a lot of time and other team members helping. Heck, last I checked Shibboleth didn't have a full implementation of the SAML spec, and they are the "SAML people." In addition, you may run into interoperability issues if you plan on supporting 3rd party SPs or IdPs if you have a custom written implementation.
You actually don't have to do any of the work if you don't want to. I agree with the previous comment -- don't build a SAML library -- they exist in many shapes and forms.
Read this to start with: https://wiki.shibboleth.net/confluence/display/SHIB2/UnderstandingShibboleth
SSO is out of the box with Shibboleth so you don't have to even monkey with trying to re-invent the wheel either. If you want a full walk through of this, read the training material which will walk you through an entire install for the IdP and a Drupal SP:
You will need to work out how you want to register the trust for your 'internal federation of IdP & SP' but that is a small piece of the puzzle in the grand scheme of things.
So your questions are:
But what happens when I redirect the user to another Service Provider? Ans: the SP software will intercept the request and validate if the user is logged in. If not, redirection occurs. If so, the SP configuration will be the gate for attributes being released (usually after the IdP releases the attributes to it).
How do I ascertain the user's identity there? Ans: see above. Choose your identifier wisely. Highly recommended to NOT use email as the identifier. TL;DR is email changes and it's a bad choice.
Do I send his SAML assertion tokens along with the redirect request?
Ans: you don't care. Let the Idp+SP software deal with it. Read the docs if you need to go deeper into what happens, but app folks don't need to be bothered with it.
Or does the second Service Provider need to contact the ID Provider all over again?
Ans: The IdP is consulted to retrieve attribute information when the user has signed in properly.
The 'I'm tasked with developing an SSO system' likely needs some planning and scale considerations (e.g. technology, # of sites etc, user audience plus a number of other planning questions). It would be healthy to nail those down :)