[Article] Identity Management Best Practices with WSO2 Identity Server

What is the computing troika?

The three biggest trends impacting the new information age are called the computing troika and include the following:

Mobile Computing - refers to not only handheld devices, heterogeneous platforms that are available at present, which include notebooks, tablets, smartphones, and other mobile device management platforms

Social Computing - not only applies to internal users, but also includes integrating with partners, customers, prospects, and leads

Cloud Computing - has several deployment patterns that involve public cloud, private cloud, and hybrid model.

The computing troika and security

A key concern with regard to the above trends is security; therefore, the following factors would need to be considered when designing an effective security solution:

Extended enterprise: The security solution should be able to handle the widening systems perimeters, which would in turn translate to a continual growth in the number of partners, customers, etc. it would be connecting with.

Globalization: Given that a system or company’s reach is now expansive, covering regions and continents, the solution should ideally be able to capture this as well.

Agile business processes: Business processes are volatile and prone to constant changes; therefore, an efficient security system should be able to promptly configure or tweak the security solution to align with the changes.

Dynamic organizational policies: The security policies should be easily configurable and dynamic.

Economies of scale: This is the cost advantage that an enterprise obtains due to its increase in size and cannot be achieved if there is recreation or duplication; therefore, as more applications are deployed, duplication must be eliminated to achieve economies of scale.

Innovation: Security solutions must be forward-looking and should pre-empt future implementations.

Identity explosion: The rate at which the number of users that are being dealt with by a system is increasing constantly; therefore an efficient security solution should be able to cope with this increase.

In the traditional approach to security, information silos were used in what could be described as an introversive approach. Hence, there was a lot of duplication and it was difficult to reach economies of scale.

Sometime later, there was a need for ‘federation’ and soon people were connecting directly between services and partners, resulting in management nightmares. In this method, direct links such as SSL connections, VPNs and Basic Authentication were used. This technique was also not scalable even though it was a step-up from the previous silo solution.

The new and improved approach to federation has been explained in Figure 1. As illustrated, there is now a centralized Identity as a Service Provider. It is still an overall n to n relationship. There is a 1 to n relationship from federation partner to consumer services (where multiple consumer services rely on a single centralized federated Identity Provider for security) and a 1 to n relationship from consumer service to federation partners (where a single consumer service can rely on multiple Identity providers for security). This model ensures greater efficiency.

Figure 1

Identity management tools and practices

The following is a list of tools and practices that can be used to provide this type of security solution:

Versatile authentication

A good security system should be able to provide versatile authentication. The unfortunate thing about authentication is that apart from the world of SOAP (Simple Object Access Protocol) Web Services Security (WSS) there is no other standard policy languages that describe the authentication mechanisms for other domains. The approach that WSO2 takes provides a composable framework for you to plug in your authenticators and configure them as required. There are several authenticators plugged into the authentication process. This architecture enables multifactor authentication, which includes username and password verification, the use of tokens, and the use of biometric scanning, such as fingerprint recognition, among others. This mechanism is further illustrated in Figure 2.

Figure 2

Context-based access control authorization

Unlike the authentication process, in the authorization process (access control) there is a standard policy language – XACML (eXtensible Access Control Markup Language). The advantages of XACML are that it is policy based, declarative, externalized, and is very fine grained. When an access request comes in, the XACML primarily looks at the subject resource action and other necessary context information and carries out an authorization check to classify what the person is authorized to do.

Auditing

The only standard surrounding auditing is Distributed Audit Server (XDAS). However, there has been a general lack of enthusiasm towards it probably because auditing was not taken that seriously in the beginning. It is now seen as a vital part in any security solution, but we haven't seen a updated standard that could be adopted. The main approach WSO2 takes to auditing is File System based Logs. When requests come for privileged operations the information is published to the Business Activity Monitor (BAM). For real-time notifications, information is published to the Complex Event Processor (CEP).

How can authentication, authorization, and auditing be enforced?

There are several places in a single system where all these processes are enforced; therefore, it is critical to ensure that they are not duplicated in all the applications or services. The processes need to be factored in because they are common for any service or application.

Management console - Whenever administration services are evoked there is a set of Axis2Handlers that gets invoked and executes the authentication, authorization and auditing processes. In the Enterprise Service Bus (ESB) we have mediators and handlers that engage for APIs. If you consider our API Management Solution, there are handlers that will execute the processes of authentication, authorization, and auditing. If a web application is run on the WSO2 Application Server then it would use a Java Servlet Filter to engage in the above three processes.

Identity delegation

This process can be explained as follows; a client gets an assertion from a trusted Security Token Service (STS) and then they present that assertion to a protected service that they’re trying to access. The protected service in turn trusts the Identity Provider of the assertion and verifies the client’s identity and attributes and grants them access to their service.

There are two popular standards of Identity Delegation; WS-Trust and OAuth2.

WS-Trust: This is very popularly used in the SOAP web services space. There are many federation patterns that are possible with WS-Trust. E.g. once the client has a SAML (Security Assertion Markup Language) Token from the Security Token Service it is possible to exchange this token for an OAuth Access Token and then access a RESTful service that is under the OAuth2 Assertion Profile.

OAuth2: This is very popular with the Representational State Transfer (REST) architecture. There are various grant types that we can talk about under OAuth2. In OAuth2, an end user is able to grant some of his access rights to a third party so that they can access his resources on his behalf for a limited time period. He is able to revoke the grants whenever he deems it to be necessary.

Identity federation

Identity federation is when a client is able to assert their identity and some of their attributes between two systems. One system would assert their identity and attributes and the other system would trust it. The following are some of the standards that are used in Identity Federation:

Open ID: This is a decentralized protocol that is very widely used for community and collaboration aspects such as Stack Overflow. It is popular because there doesn’t need to be a pre-arrangement between the relying party and the identity provider so the relying party would dynamically discover the identity provider and do the authentication.

SAML2 Web SSO: This is also a single sign on protocol, but it is different from OpenID because there is a registration process that needs to be done. WS-Federation: This is a browser based single sign-on profile. WS-Federation builds on WS-Trust.

Assertion Profiles for OAuth2: There are two popular assertion profiles. One is the SAML2 Assertion Profile and the other is the JWT (Java Web Token) Assertion Profile. Many enterprises have currently implemented SAML2 based authentication systems, so they are heavily reliant on SAML. These enterprises can access APIs that are secured with OAuth2 by using the SAML grant type where they exchange the SAML Token with an OAuth Access Token.

OpenIDConnect: This can perform both authentication as well as resource access because it is built on top of OAuth, so it inherits all the features of OAuth for API access in addition to its ability to execute authentication; the only difference being SAML2 uses SAML tokens and OpenIDConnect uses JWT Tokens.

Identity and attribute federation

There is a trusted identity provider and a relying party involved. The client’s accounts exist at the identity provider end so how does the relying party actually create or manage a session of the user account? There are a few ways in which the identity should be mapped.

• Account mapping
• Account linking
• Transient pseudonym
• Persistent pseudonym
• Out-of-band

There could be variances in the ways the identity provider and the relying party identify attributes. Similarly, the roles in the trusted identity provider would differ to those in the relying party. Those roles and attributes need to be mapped and the authorization should take place using the mapped roles and attributes. WSO2 supports these patterns in their Identity Server.

WSO2 Identity Server

WSO2 Identity Server has the ‘Jaggery’ user interface for end users. Apart from the Management Console, we also have an end user view to manage profiles to recover accounts and to manage authorized apps.

The log in and consent pages in our UI can be seen in the image shown in Figure 3. These pages can be completely customized because they run on a separate context as a separate web application. These web applications can even be dropped into a separate application server if required.

Figure 3

The diagram depicted in Figure 4 highlights one commonly used deployment pattern with WSO2 Identity Server.

Figure 4

In this deployment pattern there is a DeMilitarized Zone (DMZ) and a Green Zone. An enterprise that is concerned about the security of its internal users should have this symmetric set up.

The WSO2 Identity Server also follows this deployment pattern as illustrated in Figure 5.

Figure 5

Here, there is also a Yellow Zone that contains the shared Directory of internal and external users who are granted access.

Summary

Enterprise IT Systems are constantly changing; their perimeters are expanding and their policies keep changing. Therefore, in such a rapidly evolving world, security solutions need to be forward thinking and innovative. They need to be configurable in order to keep pace and adapt to rapid changes. With the use of WSO2 Identity Server, this can be achieved because it caters to security requirements at hand as well as looking toward the future. It has a very customizable user interface and can be easily implemented in order to ensure maximum security for your system.