Shibboleth SP - What triggers redirection through Embedded Discovery Service?

Cantor, Scott cantor.2 at osu.edu
Fri May 9 19:43:04 EDT 2014


>When the user is redirected from the Berkeley site to the UCOP site, they
>are sent through the EDS again first.

It's very simple, assuming you're using requireSession.

1. Access protected URL.

2. Does a session valid for that vhost exist? If so, fine.

3. If not, then is the entityID content setting in place? If so, request
login from that IdP. If not, look for a discoveryURL and route there to
determine IdP to use, and then request a login from it.

So from your description, by definition, there is no session on the vhost
you've redirected them to and you have discovery deployed for new sessions
on that vhost, and so that's what happens.

> They do not need to enter any credentials again. They simply need to
>select their IDP, and then they are immediately sent to the destination,
>directly from the EDS page, without going through the IDP.

I very, very much doubt that. You would never see the EDS unless no
session existed, unless you manually directed the browser to it.

> At least, that's how it looks from the browser. I guess it's possible
>that they are, under the covers, being sent to the IDP and then
>immediately sent to the UCOP site.

It's more than possible I suspect.

>6) Shibd intercepts the request for dash-dev.ucop.edu, and even though
>the user has a valid session, sends them back to the EDS page

No, they didn't have a valid session. They had a session cookie assigned
by dash-dev.berkeley.edu, not ucop.edu. Sessions based on cookies cannot
span vhosts that don't at least share a domain tail, that's not physically
possible with cookies. The SP may consider both vhosts part of one
application, but there's still no way for a single session to cross them.

>7) User selects the UCOP IDP and is immediately delivered to
>dash-dev.ucop.edu, without re-entering their credentials or even seeing
>the UCOP IDP.

I guarantee it accessed the IdP.

>Steps 6 and 7 are the problem. I don't understand why my SP is sending
>the user back to EDS when they already have a valid Shibboleth session.

It wouldn't, so they don't.

> Can anyone give me some clues as to how to even begin to debug and
>resolve this? Or is this an expected behavior
> - just part of the way we expect Shibboleth to behave when crossing from
>one DNS domain to another?

The only SSO systems capable of SSO across domains without revisiting a
session authority somewhere else (i.e., an IdP) are ones that bury the
session token in URL query parameters and pass it around on every link. Or
something based on client certs that doesn't need to use cookies.

So yes, it's expected.

If you want to work around it, you could change the rewrite rule to
instead manually request a session on the other vhost by routing the
browser to /Shibboleth.sso/Login on that vhost, provide target pointing to
the eventual resource, and add an entityID parameter set to the right IdP
to use (the value of the variable you're switching off). That bypasses
discovery on a per-case basis. The actual rule is far beyond my
mod_rewrite experience, but I'm sure it's possible.

-- Scott




More information about the users mailing list