Shibboleth handler invoked at an unconfigured location

[Peter Schober]

* reda sabir <sabiretude at gmail.com> [2016-05-20 11:49]:
> >     <Sessions lifetime="28800" timeout="3600" relayState="ss:mem"
> >               checkAddress="false" handlerURL="/Shibboleth.sso"
> > handlerSSL="false" cookieProps="; path=/; domain=example.com; 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
> wso2.shibboleth.example.com which should be wso2 instead.

Can't be from your config, no? You're not enforcing any active
protection on https://wso2.shibboleth.example.com so there'd never be
a redirect to any IDP.
Unless you mean the above to say you're in fact accessing
http://wso2.shibboleth.example.com/secure/ 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="http://wso2.shibboleth.example.com/Shibboleth.sso/SAML2/POST" index="1"/>
    <AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
      Location="http://openam.shibboleth.example.com/Shibboleth.sso/SAML2/POST" 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