<div dir="ltr"><div><div><span style="font-family:verdana,sans-serif">Answering the original question, I can say that you just need to define different "idp.home"s. You can do this in web.xml file, like the following:<br><br>    <env-entry><br>        <env-entry-name>idp.home</env-entry-name><br>        <env-entry-type>java.lang.String</env-entry-type><br>        <env-entry-value>/path/to/your/home</env-entry-value><br>    </env-entry><br><br></span></div><span style="font-family:verdana,sans-serif">I have installed multiple idps on the same server successfully (IBM WebSphere) before.<br><br></span></div><div><span style="font-family:verdana,sans-serif">I am not getting into discussion if this is a good idea intentionally. <br></span></div><div><span style="font-family:verdana,sans-serif"><br></span></div><span style="font-family:verdana,sans-serif">Thanks,</span><br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 7, 2016 at 7:53 AM, Peter Schober <span dir="ltr"><<a href="mailto:peter.schober@univie.ac.at" target="_blank">peter.schober@univie.ac.at</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thanks for sharing, Vincent. I had no idea about that specific<br>
vendor's practices and limitations,  no doubt that's all rather<br>
unfortunate. I just wonder what other SAML implementations offer<br>
sufficient flexibility here to Just Work in such circumstances.<br>
Probably only those where bilateral peering/federating amounts to<br>
setting up another IDP instance for each new SP anyway...<br>
-peter<br>
<br>
* Kozlek, Vincent <<a href="mailto:vkozlek@bloomu.edu">vkozlek@bloomu.edu</a>> [2016-07-06 21:09]:<br>
<span class="">> The problem with that is it's a single SP entityId at Microsoft for any and all domains, so shibboleth won't know which entityId to use (not to mention you literally can't configure two different configurations on the IdP for the same SP entityId).  The IdP would have to choose an entityId based on which username is logging in (either @<a href="http://domain.edu" rel="noreferrer" target="_blank">domain.edu</a> or @<a href="http://something.domain.edu" rel="noreferrer" target="_blank">something.domain.edu</a>), so that the expected entityId is in the assertion and then the login will succeed.  If any examples or documentation can be pointed to that will get this to work on a single IdP, I'd appreciate it.<br>
><br>
> I feel like it's time to just set up a second shibboleth IdP environment to get this working.  I blame Microsoft for not allowing more than one "top-level" domain be configured with the same "Issuer URI"/entityId and that fact that federation inheritance to a child domain can't be set up after the fact.<br>
><br>
><br>
> Some side info on the subject for others:<br>
> If you're dealing with an actual top-level domain and a subdomain of the top-level domain, so long as the actual top-level domain was added to your office365 tenant first, the federation settings set on the top-level domain will apply to the child domain.  If you first added the subdomain to your tenant (as I did), office365 considers it a top-level domain and if you add the actual-top-level domain afterwards, you end up with two top-level domains and there is currently no way to let the actual-subdomain inherit federation settings from the actual-top-level domain other than completely removing the actual-subdomain from the tenant and re-adding it - then it will be considered a child domain to your actual top-level domain.  If you already have users using the actual-subdomain, then removing the domain from the tenant is a risky process that involves lots of workaround and outages for the users (basically renaming their accounts to a temporary domain during the time you are deleting<br>
  t<br>
>  he domain - a large undertaking which does not scale well with lots of implications I won't go into right now).<br>
> Moral of the story:  Set up your initial tenant with your top-level domain and add the domain even if you don't put users there initially. It will help you with federation inheritance down the road.  When they converted us from Live@EDU to Office365, we didn't have the choice to set the initial tenant or add our top-level domain first, and also didn't realize this would be a problem down the road anyway.<br>
><br>
> -----Original Message-----<br>
> From: users [mailto:<a href="mailto:users-bounces@shibboleth.net">users-bounces@shibboleth.net</a>] On Behalf Of Peter Schober<br>
> Sent: Wednesday, July 06, 2016 9:36 AM<br>
> To: <a href="mailto:users@shibboleth.net">users@shibboleth.net</a><br>
> Subject: Re: One container, two IDPs?<br>
><br>
> * Matthew Slowe <<a href="mailto:m.slowe@kent.ac.uk">m.slowe@kent.ac.uk</a>> [2016-07-06 15:34]:<br>
> > Office365 wants the IDP entityid to be unique across its system per<br>
> > authenticated "domain". We have two domains (user principle name<br>
> > suffixes) in play so need two different IDP entityids.<br>
><br>
> Setting a different entityID when federating with a specific SP is possible and much easier than any alternative you're considering.<br>
> -peter<br>
<br>
--<br>
</span>mfg<br>
-p.schober<br>
<div class="HOEnZb"><div class="h5">--<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>