Login across SPs, one IdP

Peter Schober peter.schober at univie.ac.at
Wed Sep 14 08:39:51 BST 2011

* Charity Sipe <orders at charitylynn.net> [2011-09-14 05:37]:
> I would like to login to an application on sp1, and automatically be
> authenticated when I login to the applications on the others - so
> the authentication and attributes span across the domain.

If you have active protection on these SPs (i.e., by means of web
server directives or shibboleth2.xml configuration, enforcing only
access with a valid session) this is what should happen.

If on the other hand you're using lazy authentication or protecting a
resource only used for bootstrapping an application session then users
will have to click "login" (or whatever) to start the process on each
SP, but that's all.
You can get around this requirement by using isPassive="true" thereby
automatically establishing a session at the SP *iff* one exists at the
IdP -- if no session existed already at the IdP then you'll end up
back at the SP with no session either (since you wanted "lazy
sessions", i.e., not enforcing them).

> This was working with an OpenAM IdP using a federation, but I have
> been unable to replicate this with a Shib IdP.  After authenticating
> by accessing an application on an SP, accessing an application on a
> different SP redirects to the IdP for login;

If "redirects to the IdP for login" means users having to explicitly
authenticate again each time then your SSO with the IdP is broken
(e.g. disabled PreviousSession logni handler at the IdP) somehow.
If you're saying that to establish a session at any one SP there needs
to be a redirect of some sorts to the IdP and back to the SP without
interaction at the IdP (except for the initial authentication), then
you've just described the normal flow of things for the SAML Web
Browser SSO profile.

> for lazy sessions it does nothing.

That' the purpose of lazy sessions: "it" does not enforce a session
when someone is accessing a resource, "it" expects you to provide
means to the user to intiate a session by clicking on some link.
If you don't want that bahaviour, don't use lazy sessions (i.e.,
always require a session).

> It doesn't recognize the Shib session authentication and attributes
> from the login via the other SP.

That's not the way SAML works.

> * In shibboleth2.xml, added a domain name to cookieProps in order be
> sure the cookie is shared across the domain, ie,

The whole point of SAML is to get WebSSO working across DNS domains.
While you can scope cookies to a domain it doesn't change the way
things work. Each SP and IdP will still establish its own session with
the user agent, sequentially.

Nothing about federation or metadata or anything else you wrote about
matters here.

More information about the users mailing list