Second Office365 Domain requires different "Issuer URI"

Mon May 2 17:33:19 EDT 2016

It appears this is not possible via Office365's SAML implementation, but they wanted me to check with the shibboleth team for more support to see if there is a workaround that can be used on the shibboleth end.  I'm trying to configure a second Office365 domain with my shibboleth IdP, but it appears they will only allow you to configure one Office365 domain per shibboleth IdP [entityId].

I've been using shibboleth with Office365 since June 2013 and although initial config was a beast (due to their poor Office365 documentation/implementation at the time), it's been working well.  When I try to configure a second Office365 domain with the same federation settings [as we have multiple UPNs in our AD], I receive the error "Unable to convert the domain. The settings you selected are already in use. Change the settings and try again.".  Through trial and error I found that the setting that has to be unique is the "IssuerUri" parameter when running the Set-MsolDomainAuthentication command to configure federation.  If I set it to something different for the secondary domain, the command runs successfully, however I'm unable to log on to Office365 successfully with a user in that domain - I'm guessing because the issuer/entityid in the assertion does not match the value I used for "IssuerUri" at that point.  In other words, if they would just accept the command to set the same issueruri/entityid for both domains, it would work no problem, but since there is a mismatch for one of the domains, they don't accept the assertion with our actual entityId.  So I thought maybe if I can set up two relying parties with the same "SP" entityId, but different providerIds, then I could set the secondary domain's IssuerUri to the new providerid, but in my testing, it appears when you have multiple relying parties with the same id, it uses the providerid specified in the last configured relying party within the assertion.  In other words, if my new providerId is mentioned in the last listed relying party then my first office365 domain is broken even though potentially my second one would be working.  So I guess what they are asking is, is there a way to customize the saml token / assertion depending on the domain of the user logging in (or through any sort of programmatic check) so that I can send a different issuer/entityId to them depending on who is logging in (or other check)?  That is what would need to happen in order to use a single shibboleth IdP with multiple office365 domains.  I fear I will need to bring up an entirely separate instance just for this one use case, which is pretty ridiculous.  Obviously that will require additional resources, will remove the single sign-on properties for this SP for the end users, and may confuse end users since there will be a different web page address for the new instance as well.  Anyone have any thoughts on how to make this work with a single IdP?  I am still running IdP 2.x, by the way, but obviously will need to migrate to 3.x within the coming months.

I also want to provide the exact information the Microsoft Support Engineer gave in case I did not interpret it correctly in my above description:
"I understand that you are trying to federate two top level domains on O365 with Shibboleth as Identity provider.
I am afraid this is a task which is not that easy and entirely depends on how flexible Shibboleth can be while providing the SAML token to O365.
To explain further, there are two protocols that O365 supports for Identity federation which are "WS-Fed" and "SAMLP".

Using WS-Fed mostly in ADFS cases there is a parameter available called "Support Multiple Domains" that one can use and then can federate as many domains they want with the same provider. However on the other end using SAML -P the domain federation becomes more of a manual configuration and where you provide each parameter to O365 manually through command line. The parameter "Support multiple Domain " is not available in the Set-MsolDomainFederationSettings command let and hence is the issue that you are facing.

The difference here is the way "Issue URI" Parameter is sent to O365 by the federation provider to o365 in cases of multiple domains.

With WS-Fed and the Support Multiple domain parameter , there is a Claim rule which gets added to ADFS rules to send this parameter as per the domain the user authenticates to.

On O365 end, Issue URI is unique to every domain even if the federation server is the same.

So, with SAMLP if there is a possibility of Shibboleth being able to send a particular URI that is different than what we already have on portal , this will work.

We have come across a similar scenario with another third party federation provider where the issue was exactly the same and was resolved only after the federation provider created a separate cluster in the same federation server for the new domain which had the parameters different.

I am afraid this is the way the protocols are setup to work and you will have to seek help from Shibboleth team to figure this out to configure a way to set a unique Issue URI on o365 and send the same one in the token from the federation server each time a user under this domain tries to login.

I hope the answer above gives you more clarity about this and points us in the right direction."

Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20160502/9bb48beb/attachment.html>