Office 365 integration with WSO2 Identity Server for multiple domains
WSO2 Identity Server 5.9.0 is just out, offering a spectrum of new features and significant upgrades. The focus of WSO2 Identity Server as an open-source industry leader in the IAM ecosystem is to have support for open standards and to provide flexible CIAM solutions matching the present world demands.
In this blog post, I’ll be explaining a key feature introduced with the 5.9.0 release. However, before I get into the new feature explaination I would like to brief a few facts that will pave the path to understand the feature more clearly :)
Fact 01:
Identity federation and Single-Sign-On are two major concepts facilitated by WSO2 IS. These two aspects play hand in hand in the field of IAM.
- Identity federation facilitates authentication across different enterprises in different trust domains based on a trust factor.
- Single-Sign-On (SSO) enables users to access multiple applications by providing a single set of credentials only once. The user will have access to each application until the session termination happens. SAML is a frequently used standard to implement SSO.
Fact 02:
Microsoft Office 365 is one of the most widely used cloud-based SAAS product in many business environments. Office 365 integration with existing enterprise infrastructure is not an easy task as it requires users in on-premise user stores to be synced to Microsoft Azure Active Directory in the cloud. WSO2 IS Office 365 integration allows enterprises a hassle-free office 365 deployment.
Enough with the background facts! Let's get into the interesting part. Revealing the new feature…
“Integrating multiple Office 365/Azure domains in WSO2 Identity Server.”
Wait! So wasn’t Office 365 Federation already available in the previous releases?
Yes, it was already available. Then what is actually new with this release? Let me guide you through how we have extended the current Office 365 federation capability to provide a more flexible experience to the users.
When it comes to performing federation with multiple Office 365 or Azure AD domains there is an additional constraint to be considered which is not required when federating a single domain. As quoted from the official Microsoft Azure documentation,
“Azure AD has a constraint that does not allow the IssuerUri property to have the same value for more than one domain.”
In summary,
- Azure AD uses the IssuerURI to identify the domain that the token is associated with.
- The token issuer for each domain requires to be unique.
When analyzing how the aforementioned requirement comes into the picture with Office 365 integration with WSO2 IS, the following factors were identified.
- Two domains in Office 365 use the same Service Provider entity id (SP issuer name).
In WSO2 IS two domains are represented as two service providers. Each service provider should have a unique issuer name.
2. Office 365 requires to have a unique IDP entity ID (token issuer) for each domain.
In WSO2 IS the same IDP entity ID is utilized for all service providers available in a given tenant.
Therefore by considering the aforementioned points, the solution with previous IS releases was to have an IS tenant configured per domain. However, in a requirement where this needs to be done in a single IS instance, the releases prior to WSO2 IS 5.9.0 didn’t have support for this.
The 5.9.0 release provides a solution to this. We have introduced two new attributes for SAML inbound authentication configurations when creating a Service Provider.
- Service Provider Qualifier: The value defined here will be appended to the end of the “Issuer” value when registering the SAML SP in the Identity Server. This allows us to configure multiple SAML SSO inbound authentication configurations for the same “Issuer” value. Simply put into words this property allows a Service Provider to be configured for each domain with the same issuer name. How the issuer name is made unique within the IS SP configurations is by the appended Service Provider Qualifier value.
- IdP Entity ID Alias: “Identity Provider Entity ID” specified under SAML SSO Inbound Authentication configuration in “Resident IdP” can be overridden with this value. Thus, each domain can have a unique token issuer identifier as mentioned in the Microsoft documentation.
Below provided screenshot depicts the newly introduced attributes when defining SAML inbound authentication configuration for each domain (each domain is represented via a service provider).
With these two SP attributes, every domain can have a unique SP and also a unique issuer identifier :) For more information on SAML2 Web SSO Service Provider related configurations check here.
I hope this blog post gave you an understanding of integrating multiple Office 365/Azure domains using WSO2 Identity Server in a single-tenant instance.
For configuration information on SAML2 authentication for Office 365 with WSO2 Identity Server in multiple domains check here.
References: