Joint SP configuration for two applications- attributePrefix conflict

Klingenstein, Nate nklingenstein at calstate.edu
Wed Nov 23 22:30:37 EST 2016


Alex,

> Our ultimate goal is that when the user logs into Site A (through Shibboleth) and then navigates to Site B, Site B recognizes that the user was previously authenticated and the user does not have to click Login again to make the round-trip to the IdP.

This is something that federated identity generally doesn't do well because there is no central "hub" for everything, so there's nowhere to do this check on a large scale.

You ultimately want login for one application to effect login for the other application.  That, to me, smells like "looks like one application to the IdP".

Do you have any use cases where the IdP could want to distinguish between these two pieces?  Sending different attributes, trusting only one site, etc.?  If not, then I would pursue the common entityID approach you've been using.  If so, I would use a shim as described below.

It's still very hard to give any advice without knowing the details here.  All we can do is point you towards questions we think you should be asking.

> It would be much better if this round-trip was done behind the scenes, so that our two applications can seamlessly function as one and users are not confused by having to click Login multiple times.  I am not sure exactly how to accomplish this.. is there any way to make the Shibboleth IdP create session cookies for both subdomains whenever an IdP user logs in?

The IdP doesn't create session cookies for applications.  The IdP gives the user a SAML assertion payload that they deliver to the SP, at which point it's processed, consumed, and turned into a cookie-based session.

You could rely on these cookies directly or as a bridge into another session persistence mechanism.

> Scott, you mentioned "manipulating the cookie to live on a shared domain."  Could you please elaborate on what this entails and whether or not it could help in our case?

You can explicitly set cookie properties at the SP:

https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPCookieUsage

> I suppose if Shibboleth cannot generate a shared cookie that would be readable by both applications, I can code each application to generate such a shared cookie to serve as a flag every time IdP authentication takes place.

You could do it in a thousand ways.  A shared cookie is one option.

This remoting of identity is basically what SAML was designed for, so you're effectively doing a second layer of federated identity if you want to have a shim or your own layer.  That's not to say it's a bad idea, but you should think of it as another SSO protocol, ish.

> Please let me know what you guys think would be the best solution here.  Thanks again.

It remains personal preference, in my eyes.  If this should really be seen always as 1 combined application, then I would set cookies that will be legible to both A and B using cookieProps, but there are many ways to skin this potato.

Hope this helps, and thanks for taking the time to think deeply on it,
Nate.


More information about the users mailing list