1. Introduction
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.
2. Why IAM?
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
3. What are the Available Deployment Options?
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.
- Commercial off-the-shelf products
- Identity as a service
- Open source solutions
- Homegrown solutions
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.
4. Why Open Source IAM?
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.
- Freedom
- Extensibility or customization
- Lower cost
- Speedy innovation
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.
5. The Risks of Opting for an Open Source IAM Solution and Mitigations
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.
- Reliance on community
- Project stalling
- Challenges in retaining in-house talent
- Less secure because it is open
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.
6. What to Look for When Choosing Open Source IAM?
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 ability to meet the functional requirements -
Whether it’s open source or not, the IAM solution should have all the features to meet the
project’s functional requirements. In addition to referring to community resources for more
details on the feature set, conducting a proof of concept sometimes helps to correctly evaluate
the solution.
-
Open source, not just open core -
There are plenty of business models based on open source software. When choosing the open
source provider, one with an open source software model is preferred than that with an open
core model. An open source model provides the complete solution free of charge under an open
source licensing model; however, in the open core model, only the core of the software is
available as a free offering, with other critical functionality being only available through a
commercial license. Owing to this, selecting an open core model is no different than locking
yourself into a commercial solution.
-
Ease of extending and customizing -
Having the flexibility to customize the solution is a necessary requirement for any IAM
solution. The open source solution should have enough extension points to customize it to give
a user experience that is different from competitors.
-
Integration with heterogeneous technology stacks -
The IAM solution is going to act as an entry point to all applications of the digital business.
Plenty of integrations are required to have a centralized authentication and authorization for
all the applications. The open source product should support integration with applications
developed using a variety of technology and deployed on cloud or on-premise.
-
Cloud vs. on-premise deployments and interconnectivity needs -
Some open source products have limitations on supported deployment choices. The choice of the
IAM solution should support the deployment that already has been used to deploy the rest of the
systems. If the deployment requires modification to the solution or a change in the deployment
practice of an organization, then, the solution is going to be hard to adopt.
-
Ensuring that you can incorporate the latest algorithms and security protocols when
they emerge -
Whenever there is a better standard introduced for doing things in a more secure and efficient
way, the project should be able to have the bandwidth to incorporate it within the product or
solution. If the community is sufficiently large and active, this leads to the product being
updated with the latest security standards.
-
Compliance with security standards and industry regulations -
Depending on the diversity of the community, the compliance coverage will be limited to what
the community is looking for. If the community lacks members from a certain industry or
territory, then the project would not give priority to standards required by that industry or
territory.
-
Open standards support -
Support for open standards is required to be free from vendor lock-in. When there are many
integrations, having a solution based on open standards will enable replacing providers with
minimal changes.
-
The strength of the open source community -
The strength and size of the community is an important indicator of the sustainability of the
open source solution. When the community is large, it is easy to obtain support from community
members and hire.
-
The level of commercial support -
Having commercial support for maintaining the solution based on open source is similar to an
insurance policy for mitigating risks.
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).
7. Introduction to 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.
8. Customizing WSO2 Identity Server
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.
8.1 User Management Extension
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.
8.2 Extending User Stores
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.
8.3 User Store Operations Listeners
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.
8.4 User Management Errors Event Listener
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.
8.5 Customizing Error Messages
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.
8.6 Custom Password Validator
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.
8.7 Extending Authentication
Based on how the authentication is done, the supported authentication mechanisms in WSO2 Identity Server can be categorized as follows.
- Local authentication
- Federated authentication
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
8.8 Extending Provisioning
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
8.9 Authorization Extension
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.
9. Migrating from Proprietary IAM
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.
- User data
- Applications
- Configurations
9.1 Approaches to Migrate User Data
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
9.2 Approaches to Migrate Applications
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
9.3 Approaches to Migrate Configurations
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)
10. Conclusion
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.
11. References