Deploy Office 365 with WSO2 Identity Server!
Microsoft Word, Powerpoint, Excel…. and the familiar list go on and on. When I started using a computer, these were the mainstream apps, actually the only apps I started using!
Microsoft Office suite is been there for a long, long time. In fact, it was originally released on November 19, 1990, 28 years ago!
Since then Microsoft has been changing its shape with each iteration. You have to do that, when you have something great, it has to adapt to the changing technology. Otherwise, someone, at some point will knock you out.
We have come to the age of cloud computing. Most of the software that we see today is SAAS, Software As A Service. This is common for the office suits as well. GSuit for an example, the office suite offered from Google is a complete cloud-based office suite.
Now Microsoft has answered to the cloud office, with their already awesome office suite. This is Office 365. Personally, I think Microsoft will rock the cloud office space as well. Because their products are well iterated for a long time now. It does not matter what would be the platform, the customer requirements addressed with non-cloud(on-premise) office products are common in everywhere as well.
Do We Need To Care About The Cloud Office Integration?
Looking at how the Office products are evolving now, It’s obvious that the future of Microsoft Office is in the cloud. Just take a look at Office 2013, or any standard on-premise version of Microsoft Office from the version 2013 onwards. You can log in to Office 365 from the app itself. Your licenses are managed with the cloud account. Basically, cloud integration is everywhere!
Following this, many of the organizations are moving with the cloud office as well. Gartner says by 2021, more than 70% of businesses will move on to the cloud office. This means, sooner or later everybody has to consider the fact, integrating office 365 with their organization.
The Integration Problem
The problem is, deploying office 365 with existing infrastructure is not easy, if not impossible! Why would I say this?
Usually, in an organization, user identities are stored in a user store. In order to provide office 365 capabilities for the users, these identities need to be available in the Microsoft Office Cloud, which is also the Microsoft Azure AD.
Now with existing infrastructure, we need to manage identity in two places at once. Both in the Microsoft office cloud, as well as the on-premise. To do this, Microsoft has provided some tools, Microsoft Active Directory Sync, ADFS, etc. But they all work with only one type of on-premise user store, an Active Directory. If the already existing infrastructure is not based on an Active Directory user store, you would need a user store migration, which is a real pain!
Therefore, it is obvious that we have to use some other IAM, Identity and Access Management based solution in order to deliver office 365 Integration smoothly into an existing infrastructure. Fortunately, many of the IAM products today deliver this integration capability.
For this blog, we will be looking at the open source WSO2 Identity Server for the office 365 integration. WSO2 Identity Server provides some interesting and very useful features in order to make this integration smooth.
WSO2 Identity Server’s Approach
In the WSO2 Identity Server’s perspective, Office 365 integration is just another integration with your organization.
For example, you may already have Salesforce connected with the Identity Server in your organization. Office 365 is then connected to this existing infrastructure. After that, users will be able to use Office 365 privileges right away, alongside with the Salesforce.
The Basic Integration Scenario
The core principle behind this integration is the Identity Federation. In the office 365 cloud, the Azure AD, we can configure a domain to be federated to an external identity provider.
For example, imaging our organization’s domain name is abc.com. Now we want to deploy office 365 in our organization. Our users would log in to the Microsoft Office 365 using the user name format, username@abc.com.
We will configure Microsoft Azure AD, to federate identity of any user in the domain abc.com to the Identity Server instance in the abc.com organization. Now, any user tries to login with username@abc.com, will be directed to the corresponding identity server instance. Once the identity server completes the authentication, the Office 365 login process would be completed.
In the above diagramme, we are using SAML to communicate between Identity Server and Azure AD.
That’s it! WSO2 Identity Server as a federated identity provider with the Microsoft Azure AD.
Note that this integration of Office 365 is based on the existing user store configured with WSO2 Identity Server. Therefore, any of the user store type supported by WSO2 Identity Server is now allowed to be involved in this integration!
Since the WSO2 Identity Server supports all major user store types including LDAP, JDBC, and Active Directory, as well as provides extension points called Custom User Store Managers to plug-in any user store type, the organization would not be locked with an Active Directory user store.
Please refer to the official WSO2 documentation on configuring this flow[1].
But Wait!
We have a problem. Even though the Identity Federation is configured correctly, Office 365 would not allow for federated user login. You will see this by trying out the basic integration scenario above.
This is because of Microsoft Office 365 requires the identity of the logged in user to be present in the cloud, the Azure AD. This identity is used for purposes like license management.
Therefore, even if we federate abc.com properly and a user called John tries to log in Office 365 using his user name john@abc.com, Office 365 would not log him in until John’s identity is available in the cloud.
Therefore Office 365 integration requires a Hybrid Identity of users. Hybrid Identity is a term used by Microsoft to define an identity which is both presents at on-premise as well as in the cloud, same time. Which means the identity in both places is synced.
Hybrid Identity With Role-Based User Provisioning
The WSO2 Identity Server solves the Hybrid Identity problem by something called, Role-Based User Provisioning.
Some examples of Roles in an organization are Engineer, Administrator, etc.
Likewise, we need to create a separate role to identify users, who will be granted with Office 365 privileges. This can be any name, but let’s just say it will be office365Role.
WSO2 Identity Server has a dedicated connector for Microsoft Azure AD. This connector is configurable with the Office 365 role. Once configured, Microsoft Azure AD connector in WSO2 Identity Server will listen to the user events attached to this role.
If the office365Role is assigned to a user, the connector will automatically provision that user to the Azure AD. If the role is removed, the same will be done in the Azure AD as well. And also, if any of the user attributes are updated, again the same will happen to the user at the Azure AD.
That’s how the Hybrid Identity is achieved in both on-premise and Azure AD, by WSO2 Identity Server.
You need to follow the Configuring Microsoft Azure AD Outbound Provisioning Connector[2] documentation for this task.
Handling Existing Users
Deploying Office 365 into an existing infrastructure, we have to consider existing users and grant Office 365 privileges to them as well.
With the role-based user provisioning, an Administrator needs to be present and add the Office 365 role for any of the existing users who might need Office 365 privileges.
Isn’t this inconvenient? In an organization with thousands of users, maybe more than that, manual operations per user does not seem to be a pretty idea!
WSO2 Identity Server has an answer to this. They are providing a way to fully automate the task of handling existing users, based on their Adaptive Authentication feature.
On-Demand User Provisioning!
WSO2 Identity Server has a feature called Adaptive Authentication. With this, an authentication flow is no longer static but can be changed based on the authentication context.
This can be injected into the task of handling existing users for Office 365 integration. During the authentication, Adaptive Authentication can get additional user context-related information before completing the authentication flow. Based on that, it will decide whether this user need Office 365 privileges.
If needed, Identity Server will add the Office 365 role to that user before completing the authentication flow. Now, remember that the Azure AD connector is always listening to this role. It will then immediately provision this user to the Azure AD cloud.
This happens almost instantaneously. By the time, the authentication flow in WSO2 Identity Server is completed and the successful authentication message is sent to the Azure AD, our user’s identity will be provisioned and present in the Azure AD cloud. Thus the Microsoft Azure AD will have the identity of the logged in user to complete the rest of its authentication flow, like assigning licenses based on the user attributes.
Notice that the Azure AD will never notice this user’s identity was never in the cloud when the user requested to log in, in the first place. WSO2 Identity Server made sure that the user identity is present in the cloud at the right time. Not after, or not before.
Cool! right? The on-demand user provisioning based on Adaptive Authentication is one of the strong features provides by the WSO2 Identity Server, for the Office 365 integration.
You need to refer to the Configuring On-Demand Provisioning with Azure AD documentation to test On-Demand User Provisioning.
Managing Licences In Azure AD
In the Azure AD, it is possible to create user groups. An Azure AD group serves several purposes, including license management.
We can allocate Azure AD users to any group of our choice. Then that user will benefit from the license schemes assigned to a group.
Imagine a scenario, the administrator only wants full business capabilities of Office 365 to be available only for admin users. He also wants engineers to have limited access for some Office 365 apps.
A use case like this can be achieved with Azure AD groups, with different license schemes assigned to each one of them.
But having a federated user identity with Office 365 would restrict this scenario. Especially when the users are dynamically provisioned. All the users in the expected domain, still not present in the Azure Cloud. We need to do the licensing management for these users, who are expected to be provisioned in the future.
WSO2 Identity Server solves this problem by working with the Dynamic Membership Rules provided in the Azure AD. With this, an Admin can create membership rules for Azure AD user groups, and apply that to the federated users with the WSO2 Identity Server.
Azure AD connector in WSO2 Identity Server then provision users, with an indication to the Azure AD, based on which user attribute to take the decision for group assigning.
For example, if an Engineer is to be provisioned, WSO2 Identity Server will indicate to the Azure AD that this user is an Engineer. Then the Azure AD’s membership rule will decide to which group, this user should be added to. According to that, the provisioned user will have the licensing scheme allocated for Engineers.
Again, this will be a seamless task. The user story still is just to login into Office 365, and the WSO2 integration will take care of the rest.
You can find more information about this in the Configuring Microsoft Azure AD Outbound Provisioning Connector documentation, under the topic, Create a user group in the Azure AD.
Wrapping it up..
At the beginning of this blog, we started talking about Office 365, which would be an important integration for any organization, in the near future.
Then we talked about the drawbacks of this integration. Especially, how difficult it would be with the vendor-lock-in situations from Microsoft provided tools. We understood that we better look for another IAM solution, in order to have a smooth integration experience.
Then we talked about the WSO2 Identity Server for Office 365 integration. With WSO2 Identity Server, an organization is allowed to use any user store types. Also, it provides seamless user provisioning and licenses assigning capabilities, which would come very handy especially for organizations having more than thousands of users in their user store.
The following screencast demonstrates what we have discussed in this blog.
Find out more about the Identity Server from https://wso2.com/identity-and-access-management/.
