Shibboleth.sso not replying on SP in 2.3.1

Cantor, Scott cantor.2 at osu.edu
Fri Oct 5 13:17:42 EDT 2012


On 10/5/12 12:45 PM, "Ken Demarest" <ken.demarest at gmail.com> wrote:
>
>My understanding (maybe wrong) is that mod_shib captures all traffic
>heading for /Shibboleth.sso/ and handles it.

It tries to, but when there are connectors involved that are dispatching
requests to things behind Apache, sometimes they get control first.
Otherwise it's generally true.

>I think (again maybe wrongly) that the directory name Shibboleth.sso is
>defined for shib 2.3.1 in the shibboleth2.xml file, with this line:

Yes, that's the case. When a request comes in, what it does is compute the
handler that applies for the request based on the request's mapping to an
applicationId, and then to the handlerURL in that element. If that matches
the URL of the actual request, it dispatches control to the handler code.

>I've done one other installation, with shibboleth 2.5, and it eventually
>worked fine (on OSX) with a MUCH simpler shibboleth2.xml file.

That part is more or less the same.

>I suspect that somehow Apache is masking the Shibboleth.sso directory
>from mod_shib, so it never gets handed over to shibd. (am I right?)

No, I don't think it's Apache doing it, it's some connector running in
Apache. For example, mod_proxy_ajp can do it if you proxy the root but
don't unmount /Shibboleth.sso as an exception.

>To further confirm the problem, when I log in to the idp, it replies with:
>
>No peer endpoint available to which to send SAML response
>
>I imagine this is because it can't find /Shibboleth.sso/ and the
>subdirectories shibd simulates, which the idp would normally interact
>with.

Nope. That means your metadata's wrong and the request to the IdP contains
an invalid location to return to.

>But I don't have much hope.

You're looking entirely in the wrong place.

But if you want 

>Here is my shibboleth2.xml file:

It's very unlikely to involve the SP at all. If it's not running the
handler, either it doesn't think the request actually matches the handler
location, or something's jumping ahead of the module to handle the request.

-- Scott




More information about the users mailing list