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