Office 365 + Shibboleth ?

[Kozlek, Vincent]

The problem is there is no separate relyingparty.  All Office365 domains use the same entityId of "urn:federation:MicrosoftOnline".   As far as modifying the IdP entityId in the response depending on the domain of the user authenticating, it's too late to change that.  If anyone figured out a way to make that happen, perhaps based on what is contained in the AuthnRequest, please let me know.  I actually did not dig into the AuthnRequest as I was running IdPv2 at the time and didn't have dynamic capability at that time and just had to get Office365 auth up and running.

We ended up having to set up a separate IdP instance for our Faculty/Staff domain (@bloomu.edu) when we wanted to start offering Office ProPlus, OneDrive, and Office Web Apps to them after we already configured our student domain (@huskies.bloomu.edu) for Office365 email (even with both domains within the same Office365 "tenant domain").  This of course makes our Faculty/Staff lose SSO features since the other resources are configured for our primary IdP instance, but I worked with Microsoft support a couple years ago and they had no other solution other than telling me to put in a feature request that would allow you to configure multiple domains with the same "IssuerUri" (IdP entityID).  I can't find the URL at the moment, but if we can we should all upvote it.  Actually, I don't believe the feature request I entered or voted on is still listed on the current Customer Feedback page (it may have been entered on an old feedback system and perhaps they did not migrate data to the new one).

Actually I was just looking back through my emails with them and I see there is a gotcha regarding multiple domains within a tenant.  As long as you first have your root domain (i.e. bloomu.edu) added first and configured for Federation, when you add a child domain (i.e. huskies.bloomu.edu) it will inherit the federation settings.  In my case, since they migrated our huskies.bloomu.edu domain from Live at EDU to Office365 and we had nothing to do with the initial setup on Office365, it set up huskies.bloomu.edu as a "top-level domain".  Since I added bloomu.edu later, there was no parent/child relationship between bloomu.edu and huskies.bloomu.edu (hence no inheritance of settings).  So I highly recommend that you add your root domain to Office365 first to prevent issues (unless you don't want your multiple domains to be forced to use the same federation settings!).  I considered going through a process that would include moving all of our student accounts to a temporary domain so that I could delete the huskies.bloomu.edu email from Office365 and then re-add it so that it would be considered a child domain to bloomu.edu, but I came to the conclusion that it would be way too risky, would probably take too long, and too much of an inconvenience for the users (it would have to be considered an outage to them - an outage of unknown length).  Keep in mind, all the mailboxes, OneDrive files, Office ProPlus installation activations, etc.. would need to associated with the temporary domain, and moved back.  While in a non-federated temporary domain, the users would not have access to their mail/files, etc... during the moves because a random password will be set up on the account.  Plus the powershell rename commands and backend processes would need to happen in a quick manner (who knows how long it would really take), permissions would all need to remain intact when it was all over (and the OneDrive team eluded to the fact that that may not happen 100% of the time correctly), etc.. So I went with two IdP instances in the hope one day they would allow two domains to be set up with the same IdP entityId...

-----Original Message-----
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Peter Schober
Sent: Thursday, October 12, 2017 9:11 AM
To: users at shibboleth.net
Subject: Re: Office 365 + Shibboleth ?

* Tom O'Neill <oneill at sigcorp.com> [2017-10-12 13:27]:
> We ended up deploying a second IdP instance using a different port, which made the entity ID unique.
> I looked at doing something dynamic with a single instance but felt it 
> was potentially too involved and I didn’t have the time to spend on 
> it.

The documentation should cover the case of using a separate entityID value with specific RelyingParties. Should be a simple configuration change, definitively less involved (and fully supported) than running a separate IDP instance (and giving up on SSO, too, with 2 IDPs).
-peter
--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net