IDP initiated SSO

Paul Hethmon paul.hethmon at
Tue Aug 7 16:14:13 EDT 2012


What you are asking for is outside the scope of SAML as a protocol. What you are looking for is a way for the browser, on behalf of the user, authenticate to a SAML IdP (namely Shibboleth). So Shibboleth itself doesn't really do authentication. It ships with a couple of ways to do it, but is really designed to be orthogonal to the whole process.

I could see something like this working (as long you have plenty of bubble gum, bailing wire, and duct tape):

1. User logs into App1 via App1 mechanism. No SAML involved.
2. User clicks link in App1 to go to App2.
3. App1 sends authenticated user to what I'll call a bridge application where this bridge application knows the user is authenticated.
4. Bridge app constructs SAML AuthnRequest to send to Shibboleth IdP.
5. Shibboleth IdP gets request.
6. Now is where the duct tape is needed. How does Shibboleth get told that the user is authenticated? Assume that happens for now.
7. Shibboleth IdP sends the user to App2 with the SAML Response. User is happy, joy, joy.

But how does step 6 happen? Well, perhaps the bridge app lives on the same server as Shibboleth, but at the ROOT context point. So when App1 sends the user to the bridge, the bridge consumes that authentication information (whatever that is), and sets a session cookie that is good for the entire Shibboleth server. Then you set up a Shibboleth RemoteUser login handler that knows how to read that cookie and provide the information back to Shibboleth.

So there is an outline for something that would work in theory. Probably with plenty of security holes and possible attack vectors.

So now you've done all that work to put the square peg into the round hole and you're not really any richer or wiser. I would look at making App1 SAML compliant. I am assuming you don't have that as an option for some reason because you haven't asked the question. However, that would be the wiser approach. You do that work one time to make App1 compliant and now fitting it into the SAML world is simple.

Also, your statement about sending credentials for App2 to Shibboleth is not really what happens. Actually  a better way to state that is that App2 does not have credentials. App2 is SAML compliant and will trust the SAML Response sent to it by Shibboleth. So it does not care and cannot care how the user is authenticated.


From: Susan Forr <susan_forr at<mailto:susan_forr at>>
Reply-To: Shibboleth Users <users at<mailto:users at>>
Date: Tuesday, August 7, 2012 1:58 PM
To: Shibboleth Users <users at<mailto:users at>>
Subject: RE: IDP initiated SSO

I did read those two docs when I started with SAML. Maybe I am still missing to understand some piece and put it all together. That is why your help is so important.

User logs in to my App (App1) and is authenticated by some mechanism. Till this point we don’t care what mechanism is used.

Let me focus on the part when user clicks the link to a web application (App2) that is protected by saml: When this happens App1 will somehow map the logged in user and get the credentials for App2 (which is different from the login credentials used for App1). Now App1 will send the credentials for App2 to the Shibboleth IDP. (This is what I need to implement). I want the IDP to create a SAML assertion and send it to the SP.

So my question is: what classes/package do I need to use from the Shibboleth IDP to send the credentials and attributes to the IDP? Is this more of a developer community question because I will be developing a layer over the Shibboleth IDP to send these credentials?

Thanks for your help. Your guidance will help me understand SAML and Shibboleth IDP better.

From: paul.hethmon at<mailto:paul.hethmon at>
To: users at<mailto:users at>
Subject: Re: IDP initiated SSO
Date: Tue, 7 Aug 2012 00:35:17 +0000


I'd recommend some reading material to help you understand better what SAML does as an SSO protocol:

OASIS SAML Committee:

Executive Overview:

Technical Overview:

Definitely read the executive overview, it's only about 8 pages.



-- To unsubscribe from this list send an email to users-unsubscribe at<mailto:users-unsubscribe at>
-------------- next part --------------
An HTML attachment was scrubbed...

More information about the users mailing list