<div dir="ltr">Hi Peter,<div><br></div><div>Thank you for your help, it led us in the right direction. The unneeded application override was, as you said, masking the real errors, and once we removed it we got to deal with "understandable" errors in our application.</div><div><br></div><div>So, again, thanks a lot!</div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-05-11 11:49 GMT+02:00 Peter Schober <span dir="ltr"><<a href="mailto:peter.schober@univie.ac.at" target="_blank">peter.schober@univie.ac.at</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">* Enrique Pérez Arnaud <<a href="mailto:eperez@emergya.com">eperez@emergya.com</a>> [2015-05-11 11:30]:<br>
<span class="">> > What gave you the impression you'd have to set the SP's entityID to<br>
> > "<a href="https://ipnett-pre.emergya.es:5000/Shibboleth.sso" target="_blank">https://ipnett-pre.emergya.es:5000/Shibboleth.sso</a>" specifically?<br>
> > See <a href="https://wiki.shibboleth.net/confluence/display/CONCEPT/EntityNaming" target="_blank">https://wiki.shibboleth.net/confluence/display/CONCEPT/EntityNaming</a><br>
><br>
><br>
> We changed it to <a href="https://ipnett-pre.emergya.es/Shibboleth.sso" target="_blank">https://ipnett-pre.emergya.es/Shibboleth.sso</a><br>
<br>
</span>I'd also drop the URI part that identifies the content handler for<br>
mod_shib. It's a name, it doesn't need to resolve to anything, and<br>
certainly not to a URL that returns HTTP 500 status (Internal Server<br>
Error).<br>
<span class=""><br>
> > So I'd start by commenting out the application override in your<br>
> > shibboleth2.xml and commenting out the applicationId parameter in your<br>
> > httpd conf. Then try again, and this time also check your Shib logs<br>
> > (including native.log).<br>
><br>
> If we do that, when, after logging in to the IdP, the browser is<br>
> redirected to our app (that requires shibboleth authn), we get a 404<br>
> response with body:<br>
><br>
> {"error": {"message": "Could not find Identity Provider:<br>
> <a href="https://ipnett-idp.emergya.es/idp/shibboleth" target="_blank">https://ipnett-idp.emergya.es/idp/shibboleth</a>", "code": 404, "title": "Not<br>
> Found"}}<br>
<br>
</span>1. Doing "that" (i.e., not using an application override with a<br>
nonsensical duplicate entityID) is the normal way of running the<br>
software. Everyone does it that way. If you're experiencing issued<br>
with "that", the workaround is not to apply bogus config changes that<br>
mask any actual underlying errors.<br>
<br>
2. I don't know what that JSON is or where it comes from, but it's not<br>
coming from the Shibboleth SP.<br>
Note that the Shib SP does know your IDP, as it sends a SAML authn<br>
request to the IDP when asked to (e.g. by accessing<br>
/Shibboleth.sso/Login) which it couldn't if it "Could not find [the]<br>
Identity Provider".<br>
<span class=""><br>
> I have all logs set to DEBUG, but after the 404 all I can see in the<br>
> logs is:<br>
<br>
</span>The Shib SP does not issue an HTTP 404 when it's confronted with an<br>
unkown entityID.<br>
<br>
>         <!--MetadataProvider type="XML" file="idp_1-metadata.xml"/--><br>
><br>
>         <ApplicationOverride id="idp_1" entityID="<a href="https://ipnett-pre.emergya.es/Shibboleth.sso" target="_blank">https://ipnett-pre.emergya.es/Shibboleth.sso</a>"><br>
>         </ApplicationOverride><br>
><br>
>     </ApplicationDefaults><br>
<br>
Note that the ApplicationOverride is still in your config.<br>
<div class="HOEnZb"><div class="h5">-peter<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><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">Enrique Pérez Arnaud</div></div>
</div>