Setting up ECP in shibboleth SP

[Chad La Joie]

On 1/2/12 6:55 PM, Anand Somani wrote:
> But if I use the SSO browser profile, on auth failure I get redirected
> back to SP with a message that access was denied.

Not if you're using the Shib IdP you don't.  The only time the IdP can
send back an error is if the authentication requirements aren't meant
(e.g., force/passive authn is required but not supported).

> I understand that with the container based approach it is not possible
> to do this, but why is it that Shibboleth (for ECP profile) uses the
> container auth
> (https://wiki.shibboleth.net/confluence/display/SHIB2/IdPAuthRemoteUser)
> and not the external auth
> (https://wiki.shibboleth.net/confluence/display/SHIB2/IdPAuthExternal).
> It seems like with ExternalAuth it would be possible to return a SOAP
> error instead of 401.

We, the Shib team, didn't develop the ECP code and so it's only loosely
integrated with the IdP itself.  The authentication APIs in IdPv2 don't
provide any official support for non-browser based mechanisms.  It
simply wasn't part of the designed intent for v2 and the developers of
the ECP code didn't add that infrastructure.

> What would be the best thing to do, if I wanted to write a ECP Client
> then, I mean if things are not in the spec then it would almost depend
> on the IDP implementation which would force the client to be
> customizable and hence a headache to maintain?

Well, if you want a truly robust client, you're going to have to deal
with errors that occur anywhere in the protocol stack.  Whether that
means being unable to open a socket, getting an HTTP error, getting a
SOAP error, or getting a SAML error.  So, even if the v2 IdP did what I
wished it did, that doesn't mean you can simply assume you'd never get
an error from something below SAML in the protocol stack.