Shibboleth Developers

["Cantor, Scott E." <>]

> Come to think of it, most of our users probably don't go to any of our
> external SPs directly; they usually follow links from our pages, either
> our HR self-service page, our library's list of databases, our career
> services site, or our local landing pages for Google Apps.  In all those
> cases, why add an extra request/redirect to the loop, if you know what
> the IdP is going to be from the get-go?  Until you add either multiple
> IdPs or custom authentication requirements, this seems like the simplest
> path.

But whose requirements are they? You don't know what the SP's request should 
look like, so why should you have to guess? That's why I don't think the flow 
makes any sense. It offloads work that is the SP's job to the IdP 
administrator. I find that obnoxious just on principle.

Not to mention the RelayState issue...

There's also a XSRF issue with IdP-initiated SSO that one *could* mitigate in 
the SP-initiated case. The Shibboleth SP doesn't at the moment partly because 
it has to support the IdP-initiated case and it can't be mitigated there.

-- Scott