But if I use the SSO browser profile, on auth failure I get redirected back to SP with a message that access was denied. <br><br>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 (<a href="https://wiki.shibboleth.net/confluence/display/SHIB2/IdPAuthRemoteUser">https://wiki.shibboleth.net/confluence/display/SHIB2/IdPAuthRemoteUser</a>) and not the external auth (<a href="https://wiki.shibboleth.net/confluence/display/SHIB2/IdPAuthExternal">https://wiki.shibboleth.net/confluence/display/SHIB2/IdPAuthExternal</a>). It seems like with ExternalAuth it would be possible to return a SOAP error instead of 401.<br>
<br>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?<br>
<br><br><div class="gmail_quote">On Mon, Jan 2, 2012 at 3:15 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">
In my opinion, and Scott may disagree, but because the SAML spec does<br>
not actually cover authentication it also doesn't cover the case when<br>
authentication is done by an external system and fails.<br>
<br>
In a perfect world, I would want the IdP to return a SAML error saying<br>
authentication failed. But there is no way to actually do that when you<br>
call out to another system and it never returns control back to the IdP.<br>
<div class="im"><br>
On 1/2/12 6:08 PM, Anand Somani wrote:<br>
> So is response (for auth failure in case of ECP) within the spec or not?<br>
> The reason I ask is if our customer wants to use another Idp, would our<br>
> ECP code be different because it handles the credential validation<br>
> differently so instead of a 401, it returns a proper SOAP with auth denied.<br>
><br>
> Thanks<br>
><br>
><br>
><br>
> On Fri, Dec 30, 2011 at 3:56 PM, Chad La Joie <<a href="mailto:lajoie@itumi.biz">lajoie@itumi.biz</a><br>
</div><div class="im">> <mailto:<a href="mailto:lajoie@itumi.biz">lajoie@itumi.biz</a>>> wrote:<br>
><br>
> That is the expected behavior currently. Authentication occurs<br>
> outside the IdP so its the web server or servlet container giving you<br>
> that error.<br>
><br>
> On Fri, Dec 30, 2011 at 18:35, Anand Somani <<a href="mailto:meatforums@gmail.com">meatforums@gmail.com</a><br>
</div><div class="im">> <mailto:<a href="mailto:meatforums@gmail.com">meatforums@gmail.com</a>>> wrote:<br>
> > Follow up question on the setup for ECP. Everything seems to work as<br>
> > expected for a successful login, but for a bad password the client<br>
> gets a<br>
> > 401 and a html response body, I would have expected a SOAP<br>
> response/fault<br>
> > (from Idp) with a rejection/denied that I could pass to SP. Is<br>
> this not the<br>
> > correct expectation? Maybe my Idp setup is not complete, even<br>
> though it<br>
> > seems to work?<br>
> ><br>
> > Thanks<br>
> ><br>
> ><br>
> > On Wed, Dec 21, 2011 at 5:56 PM, Cantor, Scott <<a href="mailto:cantor.2@osu.edu">cantor.2@osu.edu</a><br>
</div><div class="im">> <mailto:<a href="mailto:cantor.2@osu.edu">cantor.2@osu.edu</a>>> wrote:<br>
> >><br>
> >> For the sake of the list archive, the crash was in an old<br>
> log4shib version<br>
> >> that was fixed several years ago and has nothing to do with ECP in<br>
> >> particular.<br>
> >><br>
> >> -- Scott<br>
> >><br>
> >> --<br>
> >> To unsubscribe from this list send an email to<br>
> >> <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.net</a><br>
</div>> <mailto:<a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.net</a>><br>
<div class="im">> ><br>
> ><br>
> ><br>
> > --<br>
> > To unsubscribe from this list send an email to<br>
> > <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.net</a><br>
</div>> <mailto:<a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.net</a>><br>
><br>
><br>
><br>
> --<br>
> Chad La Joie<br>
> <a href="http://www.itumi.biz" target="_blank">www.itumi.biz</a> <<a href="http://www.itumi.biz" target="_blank">http://www.itumi.biz</a>><br>
<div class="im">> trusted identities, delivered<br>
> --<br>
> To unsubscribe from this list send an email to<br>
> <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.net</a><br>
</div>> <mailto:<a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.net</a>><br>
<div><div></div><div class="h5">><br>
><br>
><br>
><br>
> --<br>
> To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.net</a><br>
--<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>