<br><br><div class="gmail_quote">On Mon, Jan 2, 2012 at 4:09 PM, Chad La Joie <span dir="ltr"><<a href="mailto:lajoie@shibboleth.net">lajoie@shibboleth.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="im"><br>
<br>
On 1/2/12 6:55 PM, Anand Somani wrote:<br>
> But if I use the SSO browser profile, on auth failure I get redirected<br>
> back to SP with a message that access was denied.<br>
<br>
</div>Not if you're using the Shib IdP you don't. The only time the IdP can<br>
send back an error is if the authentication requirements aren't meant<br>
(e.g., force/passive authn is required but not supported).<br></blockquote><div>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? <br>
</div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="im"><br>
> I understand that with the container based approach it is not possible<br>
> to do this, but why is it that Shibboleth (for ECP profile) uses the<br>
> container auth<br>
> (<a href="https://wiki.shibboleth.net/confluence/display/SHIB2/IdPAuthRemoteUser" target="_blank">https://wiki.shibboleth.net/confluence/display/SHIB2/IdPAuthRemoteUser</a>)<br>
> and not the external auth<br>
> (<a href="https://wiki.shibboleth.net/confluence/display/SHIB2/IdPAuthExternal" target="_blank">https://wiki.shibboleth.net/confluence/display/SHIB2/IdPAuthExternal</a>).<br>
> It seems like with ExternalAuth it would be possible to return a SOAP<br>
> error instead of 401.<br>
<br>
</div>We, the Shib team, didn't develop the ECP code and so it's only loosely<br>
integrated with the IdP itself. The authentication APIs in IdPv2 don't<br>
provide any official support for non-browser based mechanisms. It<br>
simply wasn't part of the designed intent for v2 and the developers of<br>
the ECP code didn't add that infrastructure.<br></blockquote><div><br>I have not tried it yet, but if I configured using ExternalAuth would shib Idp prevent me for the ECP profile case? <br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="im"><br>
> What would be the best thing to do, if I wanted to write a ECP Client<br>
> then, I mean if things are not in the spec then it would almost depend<br>
> on the IDP implementation which would force the client to be<br>
> customizable and hence a headache to maintain?<br>
<br>
</div>Well, if you want a truly robust client, you're going to have to deal<br>
with errors that occur anywhere in the protocol stack. Whether that<br>
means being unable to open a socket, getting an HTTP error, getting a<br>
SOAP error, or getting a SAML error. So, even if the v2 IdP did what I<br>
wished it did, that doesn't mean you can simply assume you'd never get<br>
an error from something below SAML in the protocol stack.<br></blockquote><div><br>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.<br>
<br>Thanks<br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div><div></div><div class="h5">--<br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.net</a><br>
</div></div></blockquote></div><br>