Shibboleth handler invoked at an unconfigured location

reda sabir sabiretude at
Mon May 23 03:38:15 EDT 2016

Indeed, it was http misconfiguration. And with that, I close this thread.
Thank you very much for your help and your patience.

Now, for all people that want to do like me and develop one SP with
multiple IdP, you can my previous post. I didn't change anything from the
code that I've posted.

Thank you again

2016-05-20 12:58 GMT+02:00 Peter Schober <peter.schober at>:

> * reda sabir <sabiretude at> [2016-05-20 11:49]:
> > >     <Sessions lifetime="28800" timeout="3600" relayState="ss:mem"
> > >               checkAddress="false" handlerURL="/Shibboleth.sso"
> > > handlerSSL="false" cookieProps="; path=/;; http">
> The "; http" at the end of your cookieProps value is wrong, but that's
> not the source of the behaviour you're seeing. (Either use the
> provided shortcut vaues 'https'/'http' or specify the full string to
> use for the Cookie.)
> > The problem is that I do have the same problem again. I dug a bit
> > and I found that if I remove one vhost, it works correctly and if I
> > put two vhost or more, it will always take me into the idp that have
> > entity id of the first vhost.
> First make sure the seconf vhost is actually ever matched by your
> requests, commenting out all Shibboleth-specific things: Put differing
> content (e.g. differing index.html pages) in both vhosts and/or check
> httpd logs (or make sure both the requested and the matched vhost are
> logged in the access log; see httpd docs for the latter). With
> different content it should be trivial to see what vhost you're in.
> If that shows requests to both vhosts ending up in the same httpd
> vhost (same content, not different content) then your problem has
> nothing to do with Shibboleth, the second vhost is simply never seeing
> your request, i.e., httpd misconfiguration.
> *Only* if you're sure httpd treats those vhosts as different continue
> with any Shibboleth specifics.
> Note you're only specifying the entityID content setting for /secure
> not for the full vhost (Location /). So what resource are you trying
> to access? Something within /secure or something anywhere else?
> > I will be redirect to openam when I access
> > which should be wso2 instead.
> Can't be from your config, no? You're not enforcing any active
> protection on so there'd never be
> a redirect to any IDP.
> Unless you mean the above to say you're in fact accessing
> and that this takes you to
> opendm, not wso2?
> Ignoring the shared domain cookie for a moment (i.e., with the default
> of cookieProps="http") the behaviour from your config should be like
> this, I think:
> * Without any sessions (fresh browser) accesing / on either vhost
>   should be permitted, nothing enforced or redirected. No attributes
>   available.
> * Without any sessions (fresh browser) accesing /secure/ on either
>   vhost should initiate a session with the configured IDP and bring
>   you back to the vhost accessed. Attributes avalable at both /secure/
>   and any other resource on that vhost (e.g. / ).
>   (Note that those SAML IDPs would need SAML Metadata with protocol
>   endpoints for *all* vhosts on your SAML SP as part of the same
>   EntityDescriptor, e.g.
>     <AssertionConsumerService
> Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
>       Location="
>" index="1"/>
>     <AssertionConsumerService
> Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
>       Location="
> index="2"/>
>   Though I don't know those SAML implementations and couldn't say what
>   they support or how.)
> * *With* a previously established session (from any of those 2 IDPs)
>   accessing both SP vhosts at / should be permitted, no redirects,
>   attributes from previous session available.
> * *With* a previously established session (from any of those 2 IDPs)
>   accessing both SP vhosts at /secure/ should be permitted, no
>   redirects either.
>   ("require shib-session" would be met with sessions from either IDP).
>   Again, attributes available anywhere on the vhost.
> So with those httpd rules you shouldn't even need the shared domain
> cookie, unless I'm overlooking something here (or forgetting, this
> thread is kinda long and I don't re-read it on every post)?
> That was just meant as a way to work around protential issues with
> your slightly contradictory (as pointed out earlier) requirements.
> The HTTP Cookie shared across all SP vhosts could also just be an
> application-specific one, taking the Shib SP out of the picture
> completely once an application-session for any vhost exists.
> -peter
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the users mailing list