Setting up ECP in shibboleth SP

[Anand Somani]

On Mon, Jan 2, 2012 at 4:09 PM, Chad La Joie <lajoie at shibboleth.net> 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
> > (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.
>

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.

Thanks

> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20120102/b3c8a359/attachment-0001.html