Integrating Office 365 with WSO2 Identity Server

  • By Pamoda Wimalasiri
  • 4 Jul, 2019

Over the past few decades, Microsoft Office has become the dominant productivity suite for enterprises. Owing to the emergence of cloud computing, the company converted its already popular office productivity suite into a cloud-based solution. Office 365 is Microsoft's answer to the office in the cloud.

Microsoft Office comprises a well-iterated set of products. Therefore, as expected, the cloud offering has become the go-to solution for enhanced enterprise productivity. As of April 25, 2019, the company, reported that it had over 180 million monthly active users in Cloud Office 365.

Microsoft’s vision for Office is the cloud, and the way how Office products are evolving right now justifies this. For example, Office 2013, the popular on-premises version of Microsoft Office, is heavily integrated with the cloud. A user can log into the cloud within the on-premises applications and licenses are managed through the cloud as well.

Therefore, moving into the cloud office is becoming a critical decision for enterprise businesses. Gartner expects more than 70% of businesses to move into the cloud office by 2021.

Problems with Integration

For many enterprises, moving into the cloud office requires deploying Office 365 to an already existing infrastructure. This has some heavy limitations owing to the nature of how Office 365 integration is designed to be deployed to existing infrastructure.

In order to provide office 365 capabilities, Microsoft requires user identities to be available in Microsoft Cloud. Microsoft will then use its licensing management capabilities and other existing capabilities implemented with its cloud infrastructure for Office 365. However, in an enterprise business infrastructure, user identities are stored in user stores, which is not always Microsoft Cloud. Thus, Office 365 integration requires an additional effort to manage identities available in the existing infrastructure, in addition to Microsoft Cloud.

To do this, Microsoft has provided tools such as Microsoft Active Directory Sync and Active Directory Federation Services (ADFS). However, they work with only one type of on-premises user store: Active Directory. If the already existing infrastructure is not based on an Active Directory user store, it requires a user store migration, which is an additional costly operation that many enterprises are not willing to take. And, even with an Active Directory user store, Microsoft keeps a copy of the identities available in the on-premises user store in the cloud. This, again, is a costly and heavy operation.

Therefore, Microsoft’s approach to deploying Office 365 to existing infrastructure forces enterprises to take additional efforts to prepare infrastructures for Office 365. This is not a feasible approach, as an enterprise expects a smooth and effortless integration with minimal changes to existing infrastructure.

How WSO2 Identity Server Overcomes the Integration Hurdle

As discussed earlier in this article, integrating Office 365 with existing user stores by using only the tools and software provided by Microsoft is not an easy task. Therefore, WSO2 has come up with an easily manageable approach to integrate Office 365 with its identity and access management (IAM) solution.

WSO2 Identity Server simplifies IAM-related activities in the enterprise. The product supports seamless and easy integration capabilities with applications, user stores, directories, and other identity management systems. Its extensible architecture and connector store of 40+ connectors makes WSO2 Identity Server the ideal solution to overcome the challenge of integrating on-premises user stores with cloud-based Microsoft Office 365.

Most importantly, many organizations require identity management for non-Microsoft services and applications. WSO2 Identity Server’s support and capabilities are trusted by customers in a variety of identity and access management implementations.

Organizations that already have WSO2 Identity Server deployed can easily integrate Office 365 without an additional cost. Organizations who onboard WSO2 Identity Server as the identity provider for Office 365 will acquire an additional set of IAM enterprise-grade capabilities with the deployment. This solution is also cost-effective as WSO2 Identity Server is fully open source. Heterogeneous user store support; seamless user synchronization; and intelligent, on-demand user provisioning make this integration the most convenient solution in the domain.

Microsoft’s traditional approach limits the user store to Active Directory. Either you have to use on-prem AD or move/create your user base to Azure AD cloud. The user stores of the organizations are designed based on the requirements and constraints they have. Limiting the user-store to AD is not feasible and would not serve the purpose. WSO2 Identity Server has overcome this limitation and provides the capability to connect with Office 365 applications using the existing user base, regardless of the underlying technology.

WSO2 Identity Server provides support to heterogeneous user stores. It is compatible with JDBC, LDAP, and Active Directory user stores out of the box. In addition to these default user stores, users can plug-in their own custom user stores. Therefore, following minor configurations, any existing user store can be easily connected to WSO2 Identity Server.

Figure 1: WSO2 Identity Server and Single Sign On

Users may require seamless access to all enterprise resources with one set of credentials. The intended single sign-on (SSO) experience differs based on organizational requirements. In integrating with Office 365, WSO2 Identity Server acts as an identity provider SSO to log-in to multiple applications. WSO2 Identity Server enables SSO across multiple applications given that the applications communicate via standard identity protocols such as SAML/OpenID. As an example, if a user logs into a desktop application via WSO2 Identity Server, he or she will be logged into Office 365 web applications without receiving prompts for credentials.

Synchronizing Users with the Cloud

Microsoft Office 365 requires users in on-premises user stores to be synced with Microsoft Azure Active Directory in the cloud to facilitate user authentication. It supports cloud identity, synchronized identity, or federated identity. In the cloud identity, users are created, stored, and managed by Azure AD in the cloud itself. The synchronized identity approach manages the user identities at the on-premises server, but the password hash is synced to the cloud so that Azure AD is responsible for user verification. Federated identity is similar to synchronized identity but user verification is also performed by the on-premises identity provider. Thus, the password hash is not required to sync with the cloud.

Most organizations maintain on-premises user stores. However, what if all these existing user accounts had to be recreated and migrated to the cloud? It will not be an easy task and will require continuous updates for the accounts. Duplicating the user accounts might also cause inconsistencies in information. Moreover, from a user perspective, they will have to remember credentials for multiple accounts. WSO2 Identity Server adopts the best approach for user synchronization and identity management when integrating with Microsoft Office 365. It utilizes federated identity so that the user authentication is provided by the on-premises WSO2 Identity Server.

In the Office 365 cloud, a domain can be configured with the federation to an external identity provider. WSO2 Identity Server acts as the external identity provider in this scenario. As an example, assume that the organization’s domain name is wso2.com and employees of the company should be given permission to access Office 365 cloud. To achieve this, WSO2 Identity Server can be configured as a federated identity for users with the domain name wso2.com. Therefore, when a username in the domain wso2.com is entered, the authentication is redirected to the WSO2 Identity Server.

Figure 2: The Identity Federation Flow

IOffice 365 requires the identity of the logged in user to be present in the cloud, i.e., Azure AD for purposes such as license management. Therefore, federated users are not authorized to access applications until the account is synced with the cloud. For user authorization, Office 365 integration requires hybrid identities. Microsoft defines a hybrid identity as an identity that presents at on-premises as well as in the cloud at the same time. It means that identities are synchronized between environments.

Role-Based, On-Demand User Provisioning

Overcoming all the above-discussed problems, WSO2 Identity Server introduces role-based, on-demand user provisioning to synchronize on-premises users with the cloud when they are authenticated for the first time. The on-demand user provisioning based on adaptive authentication is one of the strongest features provides by the WSO2 Identity Server for the Office 365 integration.

WSO2 Identity Server has a dedicated connector for Microsoft Azure AD. This connector has the capability to provision and de-provision on-premises users to Azure AD. The management of user groups also can be configured via the WSO2 Microsoft Azure AD Outbound Provisioning Connector. Configuring Microsoft Azure AD Outbound Provisioning Connector refers to the official WSO2 documentation. The logic behind the role-based user provisioning is that the provisioning connector is triggered when a user is assigned with a role or a role is removed from a user. Once the connector is configured with a specific role, it will listen to all the user events related to that role. By this approach, only a specific set of employees in the organization can be granted access to Office 365 applications. Thus, the WSO2 solution provides high controllability access management.

With role-based user provisioning, role mapping has to be done manually, which leads to consuming many human hours. When the user base of the organization is large, the overhead growth is exponential. WSO2 Identity Server addresses this issue by introducing on-demand user provisioning.

As WSO2 Identity Server also includes adaptive authentication, an authentication flow is no longer static. It dynamically changes based on the authentication context. In integrating WSO2 Identity Server with Office 365, adaptive authentication is applied for user management. During a successful authentication to the cloud, adaptive authentication scripts in WSO2 Identity Server analyze context-related information and decide whether the user is entitled to Office 365 privileges. Based on the analysis, a user is assigned a pre-defined role. From then on, the Azure AD Outbound Provisioning Connector handles the role-based user provisioning.

Figure 3: Seamless User Provisioning to the Cloud

Even though the process involves several action items, all these happen while the user is authenticated to the cloud. When the user enters his/her credentials at the cloud login, WSO2 Identity Server starts the user verification. The user’s identity is seamlessly provisioned to the cloud with the successful authentication message that is sent back to Azure AD. Thus, Microsoft Azure AD can continue the authorization flow.

License Management With Dynamic Member Allocation

In Azure AD, it is possible to create user groups. These groups serve several purposes including license management. Azure AD also supports dynamic membership by determining rules based on user or device properties. These rules are evaluated when adding and removing users, and the users are dynamically assigned to the relevant groups.

Combining the Dynamic Membership Rules in Azure AD, WSO2 Identity Server provides the feature to dynamically allocate the provisioned users to the groups defined in Azure AD. A WSO2 identity admin only has to define the rules when configuring the provisioning connector; the integration handles the remaining allocation tasks. Thus, the administrative overhead of adding and removing users to groups is reduced. This feature also utilizes user role mapping to the groups in Azure AD.

For example, if an engineer is to be provisioned, WSO2 Identity Server will indicate to Azure AD that this user is an engineer. Then, Azure AD’s membership rule will decide to which group this user should be added. According to that, the provisioned user will have the licensing scheme allocated for engineers.

Conclusion

This article discussed the cloud transformation of Microsoft’s Office suite and how crucial it is for enterprise businesses. It then discussed the drawbacks of deploying Office 365 into existing enterprise infrastructure owing to the vendor lock-in situations arising from Microsoft’s tools. We explain how these drawbacks can be avoided by utilizing WSO2 Identity Server.

WSO2 Identity Server treats Office 365 as just another integration and makes use of many OOTB features, such as SSO with other applications and heterogeneous user store support with any user store type. WSO2 Identity Server’s integration with Office 365 also has the capability to provide seamless integration with on-demand user provisioning and license management, which would come in handy especially for organizations who have thousands of users in their user stores.

About Author

  • Pamoda Wimalasiri
  • Software Engineer
  • WSO2
Pamoda is a software engineer at WSO2. She holds a Bachelor of Science from the University of Moratuwa, Sri Lanka, specializing in computer science and engineering. As part of her final year project, Pamoda worked on developing a personal cloud storage device.