In the previous article we looked at identities. How many do you have and how do you prove that you are who you say you are. We will now look deeper into the WSO2 Identity Server. The WSO2 Identity Server is part of the WSO2 middleware stack, the 100% open source middleware platform. Also part of the family is WSO2 API Manager and WSO2 Enterprise Service Bus.
Why use WSO2 IS after all?
Mobile, social and cloud computing are three big trends that are changing the way we do business, enabling new business models, partnership and opportunities.
It has, however, also put a renewed emphasis on security. People accessing your systems are no longer just coming from within your organization and its offices. They are coming from home, the airport or even a holiday resort.
They are partners, clients and employees who want and need access. You are willing to offer access to them, as long as it is secure and easy to maintain. Furthermore, the applications they want access to might be in the cloud and not within your reliable IT environment.
We also want to move maintenance of identities, authentication and authorization out of individual applications. With that we mean is that we want to use the WSO2 Identity Server API for integrating identity management to any application.
That is where WSO2 IS comes in. The WSO2 Identity server is designed with these realities in mind: an extended enterprise with wider system boundaries and larger numbers of users who might come from all corners of the globe. It is an Enterprise Identity Bus able to manage identities over systems and networks, both locally and in the cloud. We call this federated identity management.
The process flow
Let us take a look at the process flow of WSO2 IS. There are nine different steps, as you can see in the video:
1. The service provider sends an authentication request to the identity server.
2. The inbound authentication components forwards to message to the authentication framework after the processing it.
3. The authentication framework sends it to the local authenticator component and/or the federated authenticator component.
4. If federated authenticators are use the request is sent to the external applications.
5. The local authenticators and federated authenticators sent a response back to the authentication framework.
6. If there are any provisioning requests the response is sent to provisioning framework.
7. The user store is updated based on the provisioning request.
8. The response is sent back to the inbound authentication component.
9. And finally the response is sent back to the service provider.
Change is permanent
Change in this day and age is constant in business processes (and beyond) and is supported by the WSO2 system being able to tweak the policies in order to accommodate the changes. This also applies to organizational policies.
Redundant storage and duplication of users should be avoided in order to have a central repository and enjoy economies of scale. WSO2 comes with a built in user store or you can use your own LDAP or AD.
Over the years we have seen information silos in security, unable to work with other systems or exchange information between them. When we realized that was not the way forward we built direct connections which did not scale but did bridge between systems.
The Identity Server enables you to create, maintain and terminate user accounts along with user identities across multiple systems including cloud applications. When there are multiple applications that require authentication, users should be able to log in at one place and still have seamless access to all the other applications. Let WSO2 Identity Server take care of transformation of protocols and tokens.
Furthermore Identity Server lets you add Identity providers like Facebook or Google to your applications as a way to log in.
Making System and User Identity Management easy
What is important is that the Identity Server supports multifactor authentication via XMPP for OpenID and Single Sign On via OpenID, SAML2 and Kerberos.
The benefit of SSO is not limited to on premise systems but can bridge to the cloud. It can integrate out of the box with Google Apps and Salesforce.com.
Support for Policies and XACML
This acronym stands for extensible access control markup language and describes policies for access. There are three levels in XACML that are of interest that is the Policy Administration Point (PAP) which manages the policies that are in place.
The Policy Decision Point or PDP is where access requests are evaluated against the policies. The Policy Enforcement Point lies between the user and the application and which takes care of asking whether the user is indeed authorized to perform this action.
There is more to this whole system (as you can also see from figure 4) but for the scope of this document we do not discuss this concept any further other than to say that it’s possible to have very fine-grained policies for access based on the user’s profile for instance only give access to people whose email address comes from within the company’s domain or only between specific times.
The difference between service providers and identity providers
 |
|---|
| Figure 1 Policies and XACML |
A service provider is an entity or an organization like the right that offers web services. Facebook is an example of a service provider as is Google and other well-known companies. An identity provider is an organization that issues identity information and authenticate users using for instance security tokens like SAML. Many service providers are also identity providers when they offer log in functionality.
In layman terms, an identity provider offers registration and log-in with for instance name or user id and password in order to give access to their services or services from other organizations.
Although there is a difference, in most cases service provision and identity provision go hand in hand. Many sites have the option to log in and get access to more or personalized information or do transactions like shopping online.
But it can also be that they rely on a third party or offer a third-party as a trusted identification party for logging on to their services. In that case the service provider would give you the possibility to use Facebook to log into their services or register with in many cases your own user id and password that they will store. In the end there is clear really little difference between the two policies from the end user point of view. When you look at what’s happening behind the scenes it’s quite different. The WSO2 identity server can handle both situations. An identity provider doesn’t necessarily also have to be service provider.
In addition to using role-based access control (RBAC) convention, fine-grained policy based access control, and SSO bridging to make identity and entitlement management effortless, the all-new version of Identity Server now includes features such as identity token transformation and mediation for seamless integration between internal identities and cloud apps such as Salesforce, Google Apps, and Microsoft Office 365; new user and group provisioning capabilities; and multi-option and multi-step authentication to provide flexibility in selecting authentication options and enable robust multi-factor authentication.
End User Self Service
There is also an end user application were the user can change the password add or change recovery questions and manage applications. This end-user application can be fully customized as far as layout and graphics are concerned and can even be run on a different server from the identity server application. In addition to that, you can change the steps for approval of login and recovery by integrating the WSO2 Business Process Server (WSO2 BPS).
Identity provisioning
With Cloud computing / Software as a Service being used more and more we need to maintain user identities also in other places then the corporate LDAP, for instance with a number of cloud providers. SCIM (system for cross-domain identity management) helps you to propagate identities across multiple providers regardless of their protocols or APIs.
Getting started
 |
|---|
| Figure 2 Configuring the WSO2 Identity Server in eight |
| steps (WSO2 Identity Server Documentation). |
Downloading and installing WSO2 is quite straight forward. We like to point to previous articles like Getting Started with WSO2: The basics for more information. After downloading and installing the identity server is of course time to configure Identity Server.
This is done in eight simple steps as described in the documentation on the WSO2 website for identity server. For your convenience we show the steps in figure 5 but refer you to the documentation online for more information.
Acronyms
XACML eXtensible Access Control Markup Language
The standard defines a declarative access control policy language implemented in XML and a processing model describing how to evaluate access requests according to the rules defined in policies.
XMPP
eXtensible Messaging and Presence Protocol
SSO
Single Sign On (implemented using OpenID)
SAML (2)
Security Assertion Markup Language
Kerberos
Kerberos is an authentication protocol which can be used to secure communications in web services.
SCIM
System for cross-domain identity management
PEP
Policy Enforcement Points
PDP
Policy Decision Point
SPML
Service Provisioning Markup Language (SPML) is an XML-based framework developed by OASIS for exchanging user, resource and service provisioning information between cooperating organizations.
Glossary of the terms
Role-based access control (RBAC)
Sometimes these acronyms are actually as simple as they are so sound role-based access control (RBAC) is one of them. Your access to systems and functions is controlled based on the role that you have.
A related acronym is ABAC, Attribute Based Access Control) which offers a more fine grained level of access control. Both RBAC and ABAC are supported by WSO2 Identity Server.
Single sign-on and Single sign-out
Single sign-on or SSO for short is not only something you hear about a lot but is also very handy. Google uses it for instance. When you login to Google for instance on the website you automatically logging to all other Google services. You sign in once and Google will make sure that you’re signed in to all of the services. This is actually not something that only Google uses, a lot of enterprises also use this. SSO is something that is greatly appreciated by your users since it saves a lot of hassle.
Enterprise Identity Bus
When we started to develop programs was quite common to tie users to a specific application, in other words develop everything to authenticate and authorize users for each application. You would have a database of users and their entitlements that you would use or develop and maintain.
Nowadays, it actually makes no or little sense to store users or entitlement at an application level. We prefer to store it at a higher level in the enterprise for instance at the level of the Enterprise Identity Bus. We can work with users and groups, apply policies to them and revoke entitlements to all applications in one go, in order to be agile as an organization.
Like the enterprise service bus, the WS02 Identity Server is an example of something we call the enterprise identity bus, this is the same concept, a service that is available to all applications or components to share a single repository of identity and entitlement. Although the actual authentication might be done by a third party like Facebook. Google or Microsoft.
The difference between service providers and identity providers
A service provider is an entity or an organization like the right that offers web services. Facebook is an example of a service provider as is Google and other well-known companies. An identity provider is an organization that issues identity information and authenticate users using for instance security tokens like SAML. Many service providers are also identity providers when they offer log in functionality.
In layman terms, an identity provider offers registration and log-in with for instance name or user id and password in order to give access to their services or services from other organizations.
