Shibboleth SP - What triggers redirection through Embedded Discovery Service?

[Ken Weiss]

Thank you, Scott. I more than half suspected this was the expected
behavior when crossing domains, but promised my team I'd dig deeper. Now I
can go back to feeling clever about that rewrite rule... :-)

--Ken

------------------------------------------------------------
Ken Weiss                                 ken.weiss at ucop.edu
UC Office of the President              510-587-6311 (office)
California Digital Library              916-905-6933 (mobile)
UC Curation Center
415 20th Street, 4th Floor
Oakland, CA 94612






On 5/9/14 4:43 PM, "Cantor, Scott" <cantor.2 at osu.edu> wrote:

>>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
>
>
>--
>To unsubscribe from this list send an email to
>users-unsubscribe at shibboleth.net