Wednesday, September 20, 2017

Customizing Account Locking Mechanism on a User Store base in WSO2IS-5.1.0

In WSO2IS-5.1.0, there is User Account Locking scenarios as explained in this document.

One type of account locking scenario is Account locking by failed login attempts

Be default configurations related to Account locking based on failed attempts are global to all the users in the Identity Server.(i.e. Global to all the user stores)

Configuration parameters in the <IS_HOME>/repository/conf/identity/ file.
This enables the authentication flow level which checks for the account lock and one time password features. This property must be enabled for the account lock feature to work.
This enables locking the account when authentication fails.
This indicates the number of consecutive attempts that a user can try to log in without the account getting locked. In this case, if the login fails twice, the account is locked.
The time specified here is in minutes. In this case, the account is locked for five minutes and authentication can be attempted once this time has passed.

Let's say there is a use case to maintain these configurations per user store.

Example scenario would be,
  1. There are two user stores configured with WSO@IS-5.1.0 instance.
    1. Primary user store with default name "PRIMARY"
    2. A secondary user store with name "TEST"
  2. For both user stores we need different configuration parameter values
    1. PRIMARY user Store
      • Authentication.Policy.Account.Lock.On.Failure.Max.Attempts=2
      • Authentication.Policy.Account.Lock.Time=5
    2. TEST user store
      • Authentication.Policy.Account.Lock.On.Failure.Max.Attempts=5
      • Authentication.Policy.Account.Lock.Time=3
Let's say user store specific configurations can be in the below format and added to <IS_HOME>/repository/conf/identity/
  1. <UserStore>.Authentication.Policy.Account.Lock.On.Failure.Max.Attempts=2
  1. TEST.Authentication.Policy.Account.Lock.On.Failure.Max.Attempts=5

WSO2 Identity Server doesn't support this custom configuration by default.We need to write a custom User Operations Event Listener in order to achieve this.

One approach is to extend org.wso2.carbon.identity.mgt.IdentityMgtEventListener| and override it's methods to check particular values based on the UserStore Domain.

I have written a sample user operation event listener with this approach and overridden only two methods doPreAuthenticate and doPostAuthenticate.

I have implemented a CustomIdentityMgtConfig to hold configurations and used them accordingly to retrieve user store specific configuration values.(Go through the code to get a better understanding)

Once the custom user operation event listener(org.wso2.carbon.sample.user.operation.event.listener.CustomIdentityMgtEventListener) is implemented you can enable it in the place of org.wso2.carbon.identity.mgt.IdentityMgtEventListener in $IS_HOME/repository/conf/identity/identity.xml.

Copy the built org.wso2.carbon.sample.user.operation.event.listener-1.0.0.jar to $IS_HOME/repository/components/dropins and restart the server.

To achieve full functionality we may need to override other methods as well.

Read More

Defining a Custom Default Authentication Flow for All Service Providers WSO2IS-5.3.0

You can set the default authentication sequence in the $IS_HOME/repository/conf/identity/service-providers/default.xml file.

                <!-- FederatedIdentityProviders>
                </FederatedIdentityProviders -->

Here, You can define Authentication steps for the default authentication flow. By default it is set to One step with BasicAuthenticator.

If you do NOT configure Local & Outbound Authentication Configuration section in a Service Provider and set to Default as in below image, authentication flow for the Service Provider will be the flow you define in above configuration.

Read More

Friday, March 31, 2017

WSO2GREG-5.3.0 - Enable visibility of assets in Store only for assets in particular lifecycle state

There can be use cases that some organizations only needs to make artifacts visible in the store, only when they reach a particular state of its lifecycle. This requirement can be catered via the extension[1] model of WSO2GREG.

As an example let’s take soapservice, and assume that we need to make soapservices visible in store, only when they reach "Published" state in their lifecycle.
Follow below steps for that.

Open [Home]/repository/deployment/server/jaggeryapps/store/extensions/assets/soapservice/asset.js file.

Inside asset.manager look for 'search' function, which overrides the default store behavior. [2]

Enable below line inside 'search' function.

query = buildPublishedQuery(query);
//originally commented this inorder to let anystate visible in store.

Let's decide which state should be allowed in store. For that in the asset.configure section of the same file[3], add below meta section.

lifecycle: {
                publishedStates: ['Production']

Now the asset.configure section should look something like below.
asset.configure = function() {
    return {
        meta: {
        lifecycle: {
                publishedStates: ['Production']
            ui: {
                icon: 'fw fw-soap',
                iconColor: 'orange'
            isDependencyShown: true,

Restart the server. Now in the store only soapservices in "published" state will be visible.

If you need to have same behavior for other asset types as well, then follow the same steps in each assets extension type, by editing [Home]/repository/deployment/server/jaggeryapps/store/extensions/assets/[ASSET-TYPE]/asset.js file.

Read More

Monday, February 27, 2017

WSO2GREG-5.2.0- Writing extension to bind clientside javascript to pages in store

In a previous post I have explained how to Write extensions to replicate more artifact metadata in Store
In this post I will explain how to bind some client-side javascript/jquery to improve the behavior of pages in Store UI.

Followed by the sample steps explained in this previous post, Let's see how to add a custom javascript file to restservice asset type's details page.

In this sample js, I am going to set active tab of the asset details page to a desired one, using a URL fragment.

as of now, when we are browsing assets in Store and viewing metadata details of an asset, the first tab is opened by default.

Let's say, I wanted to go directly to the page with the third tab 4th tab(security) opened.

To do that,
  •  In [HOME]/repository/deployment/server/jaggeryapps/store/extensions/assets/restservice/themes/store/js/ location, add a js file, select-tab.js with following content

$(function() {
var fragment = window.location.hash;

if(fragment) {
    var tabName = '#asset-content-' + fragment.replace("#", "");
    var tab = $(tabName);
    var tabContentName = '#tab-content-'+ fragment.replace("#", "");
    var tabContent = $(tabContentName);
    if(tab.length > 0 && tabContent.length > 0){
     } else {
} else {

function showDefault(){

  • Now bind this js, to resetservice asset details page by editing [HOME]/repository/deployment/server/jaggeryapps/store/extensions/assets/restservice/themes/store/helpers/asset.js
 var name;
var custom = require('/extensions/app/greg-store-defaults/themes/store/helpers/asset.js');
var that = this;
In order to inherit all variables in the default helper
for (name in custom) {
    if (custom.hasOwnProperty(name)) {
        that[name] = custom[name];
var fn = that.resources;
var resources = function(page, meta) {
    var o = fn(page, meta);
    if (!o.css) {
        o.css = [];
    //code-mirror third party library to support syntax highlighting & formatting for WSDL content.
    o.js.push('xml.js'); //codemirror file to provide 'xml' type formatting.
    o.js.push('asset-view.js');//renders the wsdl content with codemirror supported formatting.
    o.js.push('select-tab.js');//renders active tab based on url fragment
    return o;

  • Restart the server and after login to store, goto URls like "


Read More

Thursday, January 5, 2017

Configure Email Server in WSO2IS-5.3.0

         Email notification mechanism in WSO2IS-5.3.0 Identity Management components, is now handled with new notification component. Accordingly, email server configurations also changed as follows. Other than configurations in axis2.xml,

  • Open [IS_HOME]/repository/conf/output-event-adapters.xml
  • In this file give correct property values for the email server that you need to configure for this service in adapterConfig type="email"
    <adapterConfig type="email">
        <!-- Comment mail.smtp.user and mail.smtp.password properties to support connecting SMTP servers which use trust
        based authentication rather username/password authentication -->
        <property key="mail.smtp.from"></property>
        <property key="mail.smtp.user"></property>
        <property key="mail.smtp.password">xxxx</property>
        <property key=""></property>
        <property key="mail.smtp.port">587</property>
        <property key="mail.smtp.starttls.enable">true</property>
        <property key="mail.smtp.auth">true</property>
        <!-- Thread Pool Related Properties -->
        <property key="minThread">8</property>
        <property key="maxThread">100</property>
        <property key="keepAliveTimeInMillis">20000</property>
        <property key="jobQueueSize">10000</property>
Read More
Designed ByBlogger Templates