ECP and determining Shibboleth "contact"

[Cantor, Scott]

On 3/12/15, 2:40 PM, "Nathan Potter" <ndp at opendap.org> wrote:
>
>1) How are clients expected to determine when the SP is initiating/requiring a Shibboleth authentication flow?

At the HTTP level, the MIME type is very specific when an SP issues a challenge using ECP (which it won't do unless the HTTP client advertises that it can handle that).

>Specifically:
>
>1a) How is a client to determine that when an SP returns a 302 (redirect) response that it is specifically an invitation to a Shibboleth flow, and not to an OAuth2 flow, or simply a 302 to a relocated resource?

It's not a 302, that's the point. That's not an appropriate mechanism for anything but hacking things on top of browsers. A 302 is not meant to mean "you need to login", that's just how we hack SSO into dumb clients.

>1b) When ECP is the designated Shibboleth authentication profile, is it expected that the client will always transmit an Accept header with "application/vnd.paos+xml" and a PAOS header for every request?

Yes. Just read the standard, it's very early on.

>As far as I can see (which I'm thinking isn't very far) the ECP flow is predicated on the client having already identified that a particular SP is a Shibboleth protected site, or that the client is always going to transmit the HTTP headers to initiate a Shibboleth ECP flow with every request.

The latter. You have no choice, not with a session/cookie-based implementation, since you never know when you'll be challenged.

> I think both cases create challenges for client authorship: In the former case the client must maintain/manage a potentially huge list of services/resources protected by Shib. In the latter the client may be requesting one type of content (such as DAP2/4 binary data responses), but must always be prepared to intercept a Shibboleth ECP response by evaluating the value of the Content-Type header.

That's exactly what it has to do, but the "client" involved should generally be a library, not an application, and ideally never exposes any of that.

ECP is explicitly about trying to avoid reliance on a browser as the UI for the login, but that has very non-trivial costs. All the mechanisms that aren't browser-based have issues like this in various ways.

-- Scott