By Ajanthan Balachandran, Lead - Solutions Engineer, WSO2
Current estimates suggest widespread adoption of open source software (OSS) in organizations worldwide. Compared to sectors such as operating systems and big data, adoption in the security and identity management sector has been low until now. While there were a number of open source projects around libraries for security and identity management-related functionalities, there were only a few projects based on an end-to-end security or identity and access management (IAM) solution. However, in recent years, some open source IAM projects have started to receive mainstream attention. With the arrival of open source options, choosing the right IAM solution for enterprise requirements only on a feature comparison basis is no longer a viable approach since most vendors offer similar functionalities. In contrast, users are now forced to look at other none-feature aspects. Open source IAM solutions provide better alternatives to close-sourced software owing to inherent strengths such as deployment flexibility, extensibility, usability, and lower costs.
This white paper discusses the benefits of adopting an open source IAM solution, how to choose the right open source IAM solution, and how WSO2 Identity Server helps to build a new IAM solution or migrate from an existing proprietary solution.
Identity and access management are indispensable to the security, governance, and usability of online resources. Whether for authentication, creating a personalized user experience, or access certification, identity is at the core of making processes function properly. Securing digital assets such as data, applications, systems, devices, and APIs through access control and managing the identity is generally called IAM; it is an integral part of digital businesses. As it is the gateway, the IAM solution should be carefully designed from the beginning rather than as an afterthought.
Figure 1: IAM in enterprise digital businesses
Building an IAM solution requires a range of software and hardware, but the central part of the solution comprises the software, or sometimes a cloud service, that is responsible for managing identity and handling authentication and authorization. These software and services are generally referred to as IAM products/services and based on the licensing model and ownership, can be categorized as follows.
Among these options, open source solutions have many benefits that are not offered by the rest. In the following sections, we will analyze these benefits.
Gartner expects the adoption of open source IAM to increase to 30% by 2021 up from 20% at the end of 2016, owing to the successful adoption of open source software in cloud-based enterprises and other areas [1]. In general, open source software offers the following benefits compared to commercial counterparts.
Open source software is free to use, modify, and share. The software can be used right away in evaluations or proof of concepts without waiting for a license. There is no need to go through a salesperson and do any paperwork to get started with a project. The open source licensing model even allows the software to be embedded into a proprietary solution and add value to the solution without any legal implications. This freedom to use the software without any legal implication also prevents from locking up with a single vendor or platform.
Open source communities tend to have users and developers from multiple industry verticals with diverse backgrounds. Typically, open source software architectures are designed to accommodate requirements and ideas from large, diverse communities, which, in turn, allows projects to accommodate changing requirements and customizations. Moreover, the IAM user experience should be customizable to offer a unique digital experience among competitors; open source IAM facilitates this as it offers customizations through extensions and modifications.
An incurring cost significantly impacts a project’s return on the investment. The initial acquisition cost for open source IAM is much lower than commercial licensing costs. During a project’s initialization, consultancy services might be required to kick start the project. This is the only initial non-recurring cost for an open source option. Once the project is live, the only recurring cost is for support and maintenance services, which is also typically lower compared with commercial options.
With the ability to experiment safely and fail fast and cheaply, organizations could fuel the innovation cycles. If one open source IAM does not work during the evaluation, teams can easily take a look at another one since there is no upfront investment cost during the evaluation.
Similar to other options, open source options also have some risks involved. There are avenues to mitigate these risks. There are some ventures out there that are purely based on open source risk mitigation. The following are the major risks that an organization would likely face during the lifespan of a project.
Open source software is built by the community for the community. The contributors have in-depth knowledge of the software since they are the ones who designed and developed it as a group. When there is an issue, which requires in-depth knowledge to find a solution, often, users need to rely on the community. Help from the community does not have any SLAs associated with it. They do not have an obligation to help users. This poses a large risk for enterprises that aim to use open source software in mission-critical operations.
Enterprises that use open source in their project try to mitigate the risks by building in-house talent by hiring the contributors or training the existing workforce. Employees moving out poses a risk for enterprises, as it takes time to build a resource pool.
When the lead contributor leaves the community or the community loses interest, open source projects tend to stall without any progress without anybody to maintain the software. This will place enterprise projects in danger.
There is a misconception that open source is less secure because intruders can look at the source code and target vulnerabilities. However, open source software uses the same secure software development processes as closed source. There are many open source security scanning tools available to build a secure software development process, and, sometimes, commercially available security scanning tools offer free services to detect security vulnerabilities in open source. Also, in the case of open source, there are many eyes that can look at the source code, compared to a few in closed source.
Choosing an open source software backed by a commercial entity with a sustainable business plan will ensure the longevity of the maintenance. Commercial services, such as enterprise support with aggressive SLAs and professional services, can mitigate most risks with legal guarantees.
When one decides to go with open source IAM for their use-cases, there are plenty of choices out there. There are differences from features to licensing models. One should carefully vet these differences against the requirements. An evaluation should at least cover the following aspects in order to have a successful IAM project.
The rest of the article discusses how an open source IAM can be an advantageous choice by presenting the example of WSO2 Identity and Access Management (WSO2 Identity Server).
WSO2 Identity Server [2], a part of the WSO2 Integration Agile Platform, is an open source IAM solution that facilitates single sign-on between applications and federates identities between multiple heterogeneous systems. It is optimized for securing APIs, microservices, and customer IAM (CIAM) projects. It offers enterprise-grade capabilities, such as identity federation, single sign-on (SSO), strong and adaptive authentication, account management, and identity provisioning, to help digital native organizations become integration agile through CIAM and API security.
WSO2 Identity server is built on top of an extensible architecture, where there is an extension for customizing the product’s most important functionalities. Since these extensions are reusable, WSO2 has hosted an online store [3] with all the official extensions. These extensions are available under the Apache 2 license and can be downloaded and plugged into the product on demand. The following section discusses some of the most important extensions.
Figure 2: WSO2 extension store
User stores are the main part of the user management functionality. It is an abstract representing data stores, such as LDAP, Active Directory, and databases, where the user data is stored. The aspects of the user store can be customized through extensions.
There are varieties of data stores that can act as a directory service or user store. There is a corresponding user-store extension for each type of directory services. The user store for standard directory services, such as LDAP or Active Directory, is already shipped with the product, and for other non-standard or new types of data stores, an extension can be built and integrated with WSO2 Identity Server.
If there is a need to listen to user management events such as create, edit, or delete a user or role and perform an action based on the event, then this extension should be used. This can be utilized whenever the external system should be notified of changes happening in the local user store.
This is similar to the previous event listener extension. The only difference is that the notification is sent only if there are any errors during any of the operations.
The error messages that are shown during the authentication process can be customized through this extension, and common error pages, such as the 404 page, can be set to a theme to be in line with corporate requirements.
During the user creation or registration process, a user-provided password can be validated through this extension. The password strength and complexity can be enforced through this extension.
Based on how the authentication is done, the supported authentication mechanisms in WSO2 Identity Server can be categorized as follows.
Authenticating users with a locally connected user store is known as local authentication. Federated authentication is for authenticating users in external identity systems using federated authentication protocols.
There are multiple ways to verify a user’s identity via local authentication. Validating usernames and passwords, biometrics, and certificates are well-known user identity verification or authentication mechanisms. Each method can be implemented as an extension and plugged into WSO2 Identity Server.
Figure 3: Local authenticator extensions in WSO2 extension store
Each extension provides different ways of performing federated authentication: an extension could be written for a federation protocol, or a system could use its own way. Extensions to implement well-known standard federation protocols are shipped with the product.
Figure 4: Federated authentication extensions in WSO2 extension store
WSO2 Identity Server supports inbound, just-in-time, and outbound provisioning. The inbound provisioning method is for provisioning users, just-in-time provisioning adds users to the local user store during federated authentication, and outbound provisioning is for provisioning users in the external system.
The System for Cross-domain Identity Management (SCIM) is one of the inbound provisioning mechanisms supported by WSO2 Identity Server. SCIM has its own way of representing users (i.e ., resource) and attributes through a schema. A custom attribute should be added to the schema through a schema extension. WSO2 identity server has an extension to add custom attributes to the SCIM schema.
Support for outbound provisioning for external systems is provided via an extension. Each system and SaaS has the corresponding extension for outbound user provisioning. When there is a need to support outbound provisioning for a new system or SaaS, it could be implemented as a new extension.
Figure 5: Provisioning extensions in WSO2 extension store
In addition to built-in role-based access control, WSO2 Identity Server supports OAuth2 and XACML.
The XACML policy information point is the interface through which the XACML engine retrieves user attributes. To support retrieving user attributes from multiple different sources, WSO2 Identity Server provides the policy information point extension.
In the OAuth2 implementation, WSO2 Identity Server provides an extension to add a custom grant type; this enables to customize the way a token receiver is authenticated.
Having extensive support for customization is key for projects; however, for existing projects, that use proprietary IAM, the migration path should be smooth. Migrating from one IAM solution to another IAM solution requires the following three things.
If the users are available in a standard user store, such as LDAP or Active Directory, then it is straightforward to migrate users to WSO2 Identity Server by connecting the user store and configuring it. However, if the users are in a database with custom schema, a new user-store extension should be written and plugged into the product in order to integrate.
If users from the current system can be exported to a CSV or XLS file, then, this data can be imported into a WSO2 Identity Server instance with a fresh user store by using the user import feature.
Another complex approach is to continue running the current system and enable federation between the current system and WSO2 Identity Server with a fresh user store. With just-in-time provisioning enabled, as users log in, they will be dynamically added to the user store. At one point, when almost all the users are imported to the new deployment, federation can be disabled and the old system can be torn down.
Figure 6: Options for migrating users
Applications that are integrated to authenticate and authorize against the IAM solution should be changed if the IAM solution is migrated to a different one. If the integration is done using an open standard, such as OAuth2, SMAL2, OpenID connect, or XACML, the changes required for the migration is minimal.
WSO2 IAM also supports OpenID connect. If the application is designed to use OpenID connect discovery to automatically discover the OpenID connect provider details, the migration would involve changing the discovery URL.
If the application is integrated using a proprietary federation protocol, an extension should be written to perform the integration. WSO2 Identity Server supports adding a proprietary federation implementation through an extension.
Figure 7: Options for integrating applications
The configurations are there to customize the product’s standard behavior. For the entire deployment, the basic configurations should be done according to documented best practices. There is no way to skip it. There are some other configurations such as service provider and identity provider configurations, which can be automated to avoid repetition based on the number of service providers and identity providers in use.
There are open standards to exchange configuration metadata through export and import. SAML SP/IDP metadata specification defines a standard endpoint through which the SAML2 service provider and identity provider data can be exported. Most proprietary IAM solutions support SAML2 metadata export. WSO2 IAM supports creating service providers and identity providers by providing metadata.
If the proprietary IAM provides APIs to obtain those repeating configurations, it can be automatically imported into WSO2 IAM using product APIs and metadata import. WSO2 IAM has APIs to create service providers and identity providers through non-standard APIs. Those APIs are collectively known as product administration APIs. There are some open standard APIs also available. For example, OAuth2 applications can be automatically created using an OAuth2 Dynamic Client Registration API.
The look and feel of most of browser-based interfaces are usually customizable via web standards such as CSS and HTML. IAM vendors follow it strictly to achieve compatibility of their products with all the web browsers. WSO2 IAM is not an outlier in that case. The same CSS and HTML could be reused during the migration with minimal changes to achieve the same look and feel as earlier.
Figure 8: Migrating Identity providers(IDPs) and service providers(SPs)
Open source IAM solutions are now gaining attention from enterprises similar to proprietary and commercial IAMs. Enterprises should consider open source IAMs for their use cases as these solutions present unique value propositions, owing to openness, usability, extendability, and low cost. In the future, more and more enterprises will adopt open source IAM without any hesitation given the above illustrations. If you want to learn more about WSO2 Identity Server, read our white paper here.
For more details about our solutions or to discuss a specific requirement
