Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
add comment

2 Answers 2

up vote 1 down vote accepted

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.

share|improve this answer
    
RE: "Building my own implementation" I hear you. I get nervous building anything security wise. What I'm trying to do right now is to build a demo proof of concept sort of thing so that our architect can assess what to do next. –  System Down Nov 16 '12 at 20:38
add comment

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:

https://spaces.internet2.edu/display/ShibInstallFest/Shibboleth+Workshop+Series+-+Linux+Identity+Provider+%28Centos+6.2%29

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 :)

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.