WSO2 Identity Server : A flexible, extensible and robust platform for Identity Management

WSO2 Identity Server provides a flexible, extensible and robust platform for Identity Management. This blog post looks inside WSO2 Identity Server to identify different plug points available for Authentication, Authorization and Provisioning.

WSO2 Identity Server supports following standards/frameworks for authentication, authorization and provisioning.

1. SOAP based authentication API
2. Authenticators
3. OpenID 2.0 for decentralized Single Sign On
4. SAML2 Web Single Sign On
5. OAuth 2.0
6. Security Token Service based on WS-Trust
7. Role based access control and user management API exposed over SOAP
8. Fine-grained access control with XACML
9. Identity provisioning with SCIM

1. SOAP based authentication API

WSO2 Identity Server can be deployed over an Active Directory, LDAP [ApacheDS, OpenLDAP, Novell eDirectory, Oracle DS.. etc..] or a JDBC based user store. It's a matter of configuration change and once done end users/systems can use the SOAP based authentication API to authenticate against the underlying user store.


















Identity Server by default ships with the embedded ApacheDS - but in a real production setup we would recommend you to go for more production ready LDAP - like OpenLDAP - due to some scalability issues we uncovered in embedded ApacheDS.

The connection to the underlying user store is made through an instance of org.wso2.carbon.user.core.UserStoreManager. Based on your requirement you can either implement the above interface or extend org.wso2.carbon.user.core.common.AbstractUserStoreManager.
















2. Authenticators

By default authentication to the WSO2 Identity Server Management console is via username/password. Although this is what we have by default, we never limit the user to use username/password based authentication. It can be based on certificates or any other propitiatory token types - only thing you need to do is to write your custom authenticator.

There are two type of Authenticators - Front-end Authenticators and Back-end Authenticators. Front-end Authenticators deal with the user inputs and figure out what exactly it needs to have to authenticate a user. For example, WebSEAL authenticator reads basic auth header and iv-user header from the HTTP request and calls it Back-end counter-part to do the actual validation.

Back-end Authenticator exposes it's functionality out side via a SOAP based service and it can internally get connected to a UserStoreManager.

Management console also can have multiple Authenticators configured with it. Based on the applicability and the priority one Authenticator will be picked during the run-time.




















3. OpenID 2.0 for decentralized Single Sign On

WSO2 Identity Server supports following OpenID specifications.
  • OpenID Authentication 1.1
  • OpenID Authentication 2.0
  • OpenID Attribute eXchange
  • OpenID Simple Registration
  • OpenID Provider Authentication Policy Extension
OpenID support is built on top of OpenID4Java - and integrated with the underlying user store seamlessly. Once you deploy WSO2 Identity Server over any existing user store, all the users in the user store will get an OpenID automatically.

If you want to use one user store for OpenID authentication and another for the Identity Server management, that is also possible from the Identity Server 4.0.0 on wards.

 WSO2 Identity Server supports both dumb and smart modes and if you would like you can disable the dumb mode. Disabling dumb mode is needed to reduce the load on OpenID Provider and to force relying parties to use smart mode. Identity Server uses JCache based Infiinispan cache to replicate Associations among different nodes in a cluster.

4. SAML2 Web Single Sign On

WSO2 Identity Server supports SAML2 Web Single Sign On.

OpenID and SAML2 are both based on the same concept of federated identity. Following are some of the difference between them.
  • SAML2 supports single sign-out - but OpenID does not.
  •  SAML2 service providers are coupled with the SAML2 Identity Providers, but OpenID relying parties are not coupled with OpenID Providers.
  • OpenID has a discovery protocol which dynamically discovers the corresponding OpenID Provider, once an OpenID is given.
  • With SAML2, the user is coupled to the SAML2 IdP - your SAML2 identifier is only valid for the SAML2 IdP who issued it. But with OpenID, you own your identifier and you can map it to any OpenID Provider you wish.
  • SAML2 has different bindings while the only binding OpenID has is HTTP 






















5. OAuth 2.0

WSO2 Identity Server supports OAuth 2.0 Core draft 27. We believe there will not any drastic changes between draft v27 and the final version of the specification and keeping an eye on where it's heading to.

Identity Server uses Apache Amber as the underlying OAuth 2.0 implementation.
  • Supports all four grant types listed in the specification, namely Authorization Code grant, Implicit grant, Resource Owner Password grant and Client Credentials grant.
  •  Supports Refreshing access tokens with Refresh tokens
  •  Supports the "Bearer" token profile.
  • Support for distributed token caching using WSO2 Carbon Caching Framework.
  • Support for different methods of securing access tokens before persisting. An extension point is also available for implementing the custom token securing methods.
  •  Extensible callback mechanism to link the authorization server with the resource server.
  •  Supports a range of different relational databases to serve as the token store.
6. Security Token Service based on WS-Trust

WSO2 Identity Server supports Security Token Service based WS-Trust 1.3/14. This is based Apache Rampart.





















STS is seamlessly integrated with the underlying user store and to issue tokens users can be authenticated against it.

User attributes are by default fetched from the underlying user store - but provides extensions points where users can write their own attribute callback handlers. Once those callback handlers are registered with the STS - attributes can be fetched from any user store out side the default underlying user store.

STS can be secured with any of the following security scenarios.
  • UsernameToken
  • Signature
  • Kerberos
  • WS-Trust [Here the STS can act as a Resource STS]
7. Role based access control and user management API exposed over SOAP

WSO2 Identity Server can be deployed over an Active Directory, LDAP [ApacheDS, OpenLDAP, Novell eDirectory, Oracle DS.. etc..] or a JDBC based user store. It's a matter of configuration change and once done end users/systems can use the SOAP based API to manage users [add/remove/modify] and check user authorizations against the underlying user store.
















8. Fine-grained access control with XACML

WSO2 Identity Server supports XACML 2.0 and 3.0. All the policies will be stored in XACML 3.0 but yet capable of evaluating requests either from 2.0 and 3.0.

XACML PDP is exposed via following three interfaces.
  • SOAP based API
  • Thrift based API
  • WS-XACML
Identity Server can act as both a XACML PDP and a XACML PAP. These components are decoupled from each other.

By default all XACML policies are stored inside the Registry - but the users can have their own policy store, by extending PolicyStore API.
















9. Identity provisioning with SCIM

The SCIM support in WSO2 Identity Server is based on WSO2 Charon - and open source Java implementation of SCIM 1.0 released under Apache 2.0 license.

WSO2  Identity Server can act as either a SCIM provide or a consumer. Based on a configuration WSO2 IS can provision users to other systems that do have SCIM support.