Monday, March 14, 2016

User Store Count with WSO2 Identity Server 5.2.0

This post is to provide details on one of the new functionalities introduced with WSO2 Identity Server 5.2.0, to be released soon. This feature comes with a service to count the number of users based on user names patterns and claims and also to count the number of roles matching a role name pattern in user store. By default this supports JDBC user store implementations only and provides freedom to extend the functionality to LDAP user stores or any other type as well.

How to Use?

A new property is introduced in user store manager configuration named 'CountRetrieverClass', where we can configure the class name that carries the count implementation for particular user store domain.

Using Service

The functionality is exposed via a service named 'UserStoreCountService' which provides relevant operations as below.

Separate operations are provided to get the counts of a particular user store or the whole user store chain for following functionalities.
  • Count users matching a filter for user name
  • Count roles matching a filter for role name
  • Count users matching a filter for a claim value
  • Count users matching filters for a set of claim values (eg: count of users whose email address ends with '' and mobile number starts with '033')


In order to extend the functionality, this interface '' should be implemented by the class, packaged into an OSGI bundle and dropped into the dropins folder within WSO2 Identity Server.

Thursday, February 25, 2016

Account Deactivation with WSO2 Identity Server - 5.2.0

This is about a new feature addition that can be expected to be out with WSO2 Identity Server 5.2.0 version, which has been added to the current master branch for WSO2 IS at

This feature is to cater for account disability requirements in addition to account locking. Account disabling function is provided through a user claim as similar to account locking functionality. While account locking is a temporarily blocking of user login due to a defined policy like consecutive unsuccessful login, account disabling will cater for disabling user account which is much more long term.

How to try?
  • Enable 'org.wso2.carbon.identity.mgt.IdentityMgtEventListener' in <IS_HOME>/repository/conf/identity/identity.xml file under Event Listeners.
  <EventListener type="org.wso2.carbon.user.core.listener.UserOperationEventListener" name="org.wso2.carbon.identity.mgt.IdentityMgtEventListener"
                       orderId="50" enable="true"/>
  • in <IS_HOME>/repository/conf/identity/ file configure below properties.

After the configurations are done, restart the server to have them effective.
Under claim manaement of WSO2 Identity Server, edit the claim ""to be supported by default. How to do this is described at

Now the required configurations are done. We can disable, enable user accounts through user profile.

Monday, January 04, 2016

OAuth - Extension Points Part 2 - WSO2 Identity Server

OAuth2 is widely used in the enterprise today for authorization aspects of APIs. This is the second post on the extension points available in WSO2 Identity Server after WSO2 Identity Server - Extension Points - Part 1 - SAML

All the implementation using following extension point needs to be configured at <IS_HOME>/repository/conf/identity/identity.xml file under the element OAuth.

  • Custom OAuth grant handler


When we need to support an OAuth flow that is different from standard grant types. Validates the grant, scopes, and access delegation.



  • Client Auth Handler


When the client credential authentication needs to be customized. By default we validate the client id and secret.



  • OAuth Callback Handler

An extension point provided to verify whether the authenticated user is the rightful owner of the resource. There can be multiple active OAuthCallbackHandler implementations at a given time. There are registered through the identity.xml. In run-time, each and every authorization callback handler is invoked to see whether it can handle the given callback. Then the callback with the highest priority will be chosen. After handling the callback, it can set whether the given callback is authorized or not.



Abstract Class / Default Implementation:


  • Token Persistence Processor

Implementations are used to process keys and secrets just before storing them in the database. E.g. to encrypt tokens before storing them in the database. Implementations of this interface can be configured through the identity.xml.



Abstract Class / Default Implementation:

  • org.wso2.carbon.identity.oauth.tokenprocessor.EncryptionDecryptionPersistenceProcessor
  • org.wso2.carbon.identity.oauth.tokenprocessor.PlainTextPersistenceProcessor

  • User Info Access Token Validator

Validates the access token and returns the token info. Default behavior is validating the access token with WSO2 IS token validation OSGI service(Scope is also checked to have openid scope). If this needs to be modified this can be used.



Default Implementation:


  • User Info Claim Retriever

Default behavior is creating claim URI and claim value pairs according to the claim mappings received. Any modifications to this default behavior can be done here.



Default Implementation:


  • User Info Request Validator

Default behavior is validating the schema and authorization header according to the specification( Any further additional validations or modification to this validation on user info request can be done using this extension.



Default Implementation:


  • User Info Response Builder

Creates the UserInfoResponse. By default the response can be a JSON or a JWT. When a different format is required this extension can be used to support it.



Default Implementations:


  • Authorization Context Token Generator

Generates the token relevant to the authorization context. By default JWT token generation is supported with the following properties encoded to each authenticated API request:

  • subscriber, applicationName, apiContext, version, tier, and endUserName
  • Additional properties can be encoded by engaging the below extension.
  • The JWT header and body are base64 encoded separately and concatenated with a dot.
  • Finally the token is signed using SHA256 with RSA algorithm.

Any deviations can be made via this extension and configured in identity.xml


Default Implementation:


  • Claims Retriever

The default implementation class of this ClaimsRetriever reads user claim values from the default carbon user store. The user claims are encoded to the token in the natural order of the claimURIs by the previous token generator. To engage this class, its fully qualified class name should be mentioned under identity.xml -> OAuth -> TokenGeneration -> ClaimsRetrieverImplClass

Any deviation can be done using this extension.


  • Response Type Handler

This is intended to validate access delegation and oauth scope validation. Then issue codes or tokens. In this flow needs to be customized this extension can be used.


  • OAuth2 Token Validator

This when a token is sent back for validation purposes to validate on scopes, validity of access token and access delegation.