Setting up ECP in shibboleth SP

Anand Somani meatforums at
Tue Jan 3 00:25:18 GMT 2012

On Mon, Jan 2, 2012 at 4:09 PM, Chad La Joie <lajoie at> wrote:

> 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 am using Shibboleth IDP with external auth and am able to get this
behavior, so not sure if this is just a coincidence (because of some
misconfiguration or incorrect coding) or what?

> > 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
> > (
> > and not the external auth
> > (
> > 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.

I have not tried it yet, but if I configured using ExternalAuth would shib
Idp prevent me for the ECP profile case?

> > 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.

Its not about robust code for the well defined protocol, but more about
open API (for authentication) which makes this more of customization based
on the customer's IDP and hence a potential headache for maintenance.  I am
just trying to get a feel for what to expect based on your experience.


> --
> To unsubscribe from this list send an email to
> users-unsubscribe at
-------------- next part --------------
An HTML attachment was scrubbed...

More information about the users mailing list