WSO2 Identity Server Events

4 min readAug 1, 2019

Originally published at http://everything1know.wordpress.com on August 1, 2019.

What’s up, folks?

Today I’m going to talk about the eventing framework of the WSO2 Identity Server. There are numerous operations you can do with the WSO2 Identity Server such as user operations, and the eventing framework is designed to trigger events when each of those operations are executed.

We can write Handlers that can be subscribed to these events and do whatever the use case we need to get done.

This is just one example, and we can do a lot using the WSO2 Identity Server eventing framework. Following are the supported events.

PRE_AUTHENTICATION — Triggered before authenticating a user.
POST_AUTHENTICATION — Triggered after authenticating a user.
PRE_ADD_USER — Triggered before adding a new user to the system.
POST_ADD_USER — Triggered after adding a new user to the system.
PRE_UPDATE_CREDENTIAL — Triggered before updating user credentials.
POST_UPDATE_CREDENTIAL — Triggered after updating user credentials.
PRE_UPDATE_CREDENTIAL_BY_ADMIN — Triggered before updating user credentials by an admin.
POST_UPDATE_CREDENTIAL_BY_ADMIN — Triggered after updating user credentials by an admin.
PRE_DELETE_USER — Triggered before deleting a user from the system.
POST_DELETE_USER — Triggered after deleting a user from the system.
PRE_SET_USER_CLAIM — Triggered before setting a single user attribute.
POST_SET_USER_CLAIM — Triggered after setting a single user attribute.
PRE_SET_USER_CLAIMS — Triggered before setting a set of user attributes as a batch.
POST_SET_USER_CLAIMS — Triggered after setting a set of user attributes as a batch.
PRE_GET_USER_CLAIM — Triggered before retrieving a user attribute.
POST_GET_USER_CLAIM — Triggered after retrieving a user attribute.
PRE_GET_USER_CLAIMS — Triggered before getting a set of user attributes as a batch.
POST_GET_USER_CLAIMS — Triggered after getting a set of user attributes as a batch.
PRE_DELETE_USER_CLAIM — Triggered before deleting a user attribute.
POST_DELETE_USER_CLAIM — Triggered after deleting a user attribute.
PRE_DELETE_USER_CLAIMS — Triggered before deleting a set of user attributes as a batch.
POST_DELETE_USER_CLAIMS — Triggered after deleting a set of user attributes as a batch.
PRE_ADD_ROLE — Triggered before adding a role.
POST_ADD_ROLE — Triggered after adding a role.
PRE_DELETE_ROLE — Triggered before deleting a role.
POST_DELETE_ROLE — Triggered after deleting a role.
PRE_UPDATE_ROLE — Triggered before updating a role.
POST_UPDATE_ROLE — Triggered after updating a role.
PRE_UPDATE_USER_LIST_OF_ROLE — Triggered before updating the user list of a role.
POST_UPDATE_USER_LIST_OF_ROLE — Triggered after updating the user list of a role.
PRE_UPDATE_ROLE_LIST_OF_USER — Triggered before updating the role list of a user.
POST_UPDATE_ROLE_LIST_OF_USER — Triggered after updating the role list of a user.
UPDATE_GOVERNANCE_CONFIGURATION — Triggered when updating the governance configurations.
PRE_ADD_NEW_PASSWORD — Triggered before adding a new password.
POST_ADD_NEW_PASSWORD — Triggered after adding a new password.
PRE_SEND_RECOVERY_NOTIFICATION — Triggered before sending recovery notification.
POST_SEND_RECOVERY_NOTIFICATION — Triggered after sending recovery notification.
TRIGGER_NOTIFICATION — Triggered when a notification is triggered.
TRIGGER_SMS_NOTIFICATION — Triggered when an SMS notification is triggered.

Writing a Simple Event Handler

To write an event handler, we need to extend the AbstractEventHandler class. There are three important methods we need to override.

getName() — This should return the name of the event handler.
getPriority() — This method should return a priority value for the handler. Registered handlers will be executed based on their priority.
handleEvent(Event event) —Whatever we need to get done should go inside the handleEvent method.

Following is an example event handler code that logs an info log when executed.

Event handlers should be written as OSGi components. Therefore, we need a service component class to activate the bundle.

You can find a completed project here. Build the project using maven ( mvn clean install) and copy the JAR file to <IS_HOME>/repository/components/dropins folder.

Subscribing to Events.

Open the file <IS_HOME>/repository/conf/identity/identity-event.properties and add the following.

module.name.19=customAddUserEventHandler customAddUserEventHandler.subscription.1=POST_ADD_USER customAddUserEventHandler.subscription.2=POST_AUTHENTICATION customAddUserEventHandler.enable=true

Name returned from the getName method should be added as the module.name. At this moment there were 18 modules already registered and therefore the number 19 has been added. After that, you can subscribe to events. In this example, we’ve subscribed to POST_ADD_USER event and POST_AUTHENTICATION event.

After running the server, logs will be printed accordingly.