User Core concepts in WSO2 Identity Server.

In my previous blog posts. I have mainly discussed on WSO2 Identity Server as a powerful XACML engine with PDP, PAP and PIP components. In this blog post also i am going to talk about WSO2 Identity Server, But not about XACML ? …..  WSO2 Identity Server is not just a XACML engine. It has many features. One of the powerful feature of it; is user management functionality. It can be connected with any type of user store and then user store functions can be exposed as web service APIs. XACML implementation of WSO2 Identity Server uses those user management API for various purposes. All these user management functionalities are inherited from WSO2 Carbon platform. Therefore this blog post is applied with any WSO2 Carbon products.

I hope it would be great, if we can understand some core concept behind the user management functionalities in WSO2 Carbon. All user kernel functions can be found at the “org.wso2.carbon.user.core” OSGI component. you can find the SVN of 3.2.X release from here.

Lets start by identifying the concept called “Realm”.    following diagram would probably help you.


User Realm

A realm is generally a collection of users with attributes, which may or may not be assigned to roles or groups. Basically we can say that the realm represents a user store. However WSO2 user realm consists of following four aspects,

  • Use store management
  • Authorization Management
  • Claim management
  • Profile configuration management

In WSO2 user kernel contains a java interface called “UserRealm” which is the realm of WSO2 Carbon servers. It is a collection of interfaces of above mentioned aspects. There is a default implementation of this , i.e called “DefaultRealm“.

Realm Service

This provides methods to manipulate realms. It exposes realms as an OSGI service in Carbon servers. Therefore other bundles (or classes) in same OSGI environment, can used and manipulate them.   Carbon user kernel contains a java interface called “RealmService”  to expose it.

Realm Repository

This is the repository for realm and repository can be any source. It would depend on how you are implementing the interfaces associate with the user realm. By default,  repository is a JDBC database or  LDAP  based user store +  JDBC database. (As i discuss below, default authorization manager and default claim managers are depends on the JDBC database)

Realm Configuration

This is a XML file which is called as “user-mgt.xml”,  typically this can be found at <CARBON_HOME>/repository/conf directory. This defines all configurations, that is related to the user realm and that is used to initialize it.

Aspect of  User realm

We got an idea about user realm,  now lets  go through the each aspect of  user realm

User Store Manager

This is component  that manages underline user store.  User store can contain users , user attributes and roles (or groups).  It  can be a JDBC (table or set of tables), LDAP or AD.   “UserStoreManager” is the java interface which  represents the user store manager. There can be different user store manager implementations to connect with different user stores. But only one user store manager implementation can be configured with single user realm (single WSO2 Carbon instance).  User store manager can be operated both read/write mode and read only mode. If read-only mode, you can only connect with an existing user store. WSO2 Carbon has been shipped with following default user store manager implementations in 3.2.X release.

  • JDBCUserStoreManager (Both read/write)
  • LDAPUserStoreManager (Read only)
  • ApacheDSUserStoreManager (Both read/write)

In trunk there are AD DS and AD LDS implementations (Both read/write) that would be released with Carbon 4.0.0.  Also any user store manager implementation can be written by implementing “UserStoreManager” or extending “AbstractUserStoreManager” or  else extending any default implementation that is mentioned above.


This uses a schema which is specific to WSO2 Carbon. Four tables which are associated with JDBCUserStoreManager , are mentioned below. You can find the full schema of these four tables from the db scripts file which can be found at <CARBON_HOME>/dbscripts directory.  Please note; these db script file contains some other table schemas that are used for user management and registry functions

UM_USER : where user names , passwords and etc .. are stored

UM_ROLE  : where role names are stored

UM_USER_ROLE  : where user role mappings are stored

UM_USER_ATTRIBUTE  :  where user attributes are stored. There can be any attribute id and a value for that attribute id which would be associated with a user’s profile.

If your organization contains an existing JDBC user store and you want to plug it with WSO2 Carbon, we can not assume that existing user store also has a schema which is compatible with WSO2 Carbon schema. Therefore you need to extend the “JDBCUserStoreManager” and write a new implementation for your use store according to the your schema.

If you like to use any other schema, rather than the default WSO2 Carbon user store schema, you can do it also. But you need to do the same thing as above; writing a new implementation with use of “JDBCUserStoreManager”. I will discuss on writing a custom JDBC user store in my next blog posts.

Also one of the question that is commonly raised with user store managers is “Can we connect to multiple LDAPs or different user stores with WSO2 Carbon? ”    Answer is “Yes , You need to implement new user store manager for this.” Lets discuss on writing multiple user store manager implementation in my future blog post.

Authorization Manager

Any resources related with WSO2 Carbon platform can be protected with role based access control (RBAC).

“JDBCAuthorizationManager” is the default implementation which is shipped. This uses a WSO2 Carbon specific permission model which uses the authorization data that is stored in tables in JDBC database.

You can write any implementation and plug it with WSO2 Carbon (XACML based authorization manager would be a good option ? ).

Claim Manager

Responsible for adding/deleting claims and mapping claims from one namespace to another.

“DefaultClaimManager” is the default implementation which is store claim data in tables of JDBC database.

Please refer this blog post for more information on claim management.
I think, this blog post may help you to get some clear high level idea on user kernel of WSO2 Identity Server (or WSO2 Carbon)….