Authentication Session Persistence

This topic is regarding sessions in the WSO2 Identity Server (IS) and the process of enabling session persistence for these sessions. This is particularly useful when the remember me option is selected when logging into either the service provider or the WSO2 Identity Server.

In WSO2 Identity Server has multiple local caching usages in different layers to improve the product performance. But most of the caches are ready to persist in the database if it is required.

There are three types of data objects that are persisted in the database.

1. Session Data

Once the user gets authenticated over WSO2 Identity Server, it will create a Session data object which stores the authenticated user and other authentication flow details. This will store in the database to share across the cluster nodes.

2. Operational Data

This is covered the same session data as in above but the outdated records. Ex: Once user gets authenticated, there will be a record for login status to that session id. Then again that user gets log out from the system, we are not removing the above record from the table and instead of that, we add a new record to the same session id with status called log out. So the valid record is the last one and all the other records under that session id will be outdated. Those outdated records belong to the Operational Data.

3. Temporary Data

In authentication flow, there are much temporary data objects that will keep for a few seconds only. We keep these in the cache. But to make consistent the cluster environment without having the local cache, we store that also in the same database table that we stored the session data as in above.

When we consider the data persistence which belongs to the critical path and high concurrency situation, we had to further improve the following key aspects as well.

Data Clean-Up

Since the above data are collected over the authentication flow, it will grow the database with that data very frequently. So we had to manage few tasks to clean the data in the database for some given conditions.

Task Pool

We are storing data within a critical path which is controlling the authentication. So we have introduced a pooling mechanism to put the data persistence tasks into that pool and continue the critical path without blocking it.

Data clean-up in a clustered environment

Even in a clustered environment, it is not recommended to enable Hazelcast distributed caching for identity data. Therefore, it is recommended to rely on the local cache in this case as well. In a clustered environment, it is recommended to disable the pool by setting the PoolSize property to 0. Else, data inconsistencies can occur where one node gets delayed and does not update the database before the other node accesses the same data from the database. 

The following configuration found in the file <IS_HOME>/repository/conf/identity/identity.xml, under the Server and JDBCPersistenceManager elements, is used to enable session persistence. 

<SessionDataPersist>
    <Enable>true</Enable>
    <Temporary>true</Temporary>
    <PoolSize>0</PoolSize>
    <SessionDataCleanUp>
        <Enable>true</Enable>
        <CleanUpTimeout>20160</CleanUpTimeout>
        <CleanUpPeriod>1140</CleanUpPeriod>
        <!--Instead of deleting all the records at once, we are deleting the records in chunks to prevent the -->
        <!--possible deadlock and lock scenarios. The following property defines the chunk size.-->
        <DeleteChunkSize>50000</DeleteChunkSize>
    </SessionDataCleanUp>
    <OperationDataCleanUp>
        <Enable>true</Enable>
    </OperationDataCleanUp>
    <TempDataCleanup>
        <!-- Enabling separated cleanup for temporary authentication context data -->
        <Enable>true</Enable>
        <!-- When Poolsize > 0, temporary data which have no usage after the authentication flow will be deleted immediately
                 When Poolsize = 0, data will be deleted only by the scheduled cleanup task-->
        <PoolSize>20</PoolSize>
        <!-- All temporary authentication context data older than CleanUpTimeout value are considered as expired
                and would be deleted during cleanup task -->
        <CleanUpTimeout>40</CleanUpTimeout>
    </TempDataCleanup>
</SessionDataPersist>

The following table describes the elements of the configurations mentioned above.

Why do we need to have a proper delete chunk size?

In the world of World Wide Web, Sessions are the simplest way to store data for individual users against a unique session ID. These can be used to persist state information between page requests. When we consider all the requests and responses that comes to a page per day, that is really a large amount. Due to this reason, the session data storing in the “IDN_AUTH_SESSION_STORE” table in the WSO2CARBON_DB of WSO2 IS is really high. This table fills up quickly if your system receives too many loads of requests.

After a certain period of time, these session data is not really necessary. In order to stop the exponential table growth, we run a Session Clean Up Tasks in predefined time intervals via a script. If this storing session data is huge, the data that need to be deleted also will come in bulk.

The session clean up task also takes a certain amount of time and consumes a certain amount of resources. Therefore, we always need to improve the performance of session clean up tasks. For this DeleteChunkSize property has introduced in WSO2 Identity Server. This will also help to reduce dead-locks happening during the session clean up task. With the use of DeleteChunkSize value, the deletion happens batch wisely. “DeleteChunkSize” of data is deleted at one time.

But if you didn’t select a correct number for the DeleteChunkSize, you will end up with less performance. Therefore selecting a suitable chunk size for your database is a must.

This chuck size may differ due to various factors of your environment

• The size of a row of the table. Calculate this by adding bytes needed for each column, and some control information per record.
• The underlying physical storage. e.g Normal SATA spinning Disk, SSD, SCSI, Amazon S3/EBS etc.
• The type of the database engine (e.g. MySql, MSSql, Oracle). Each one has a different data organization mechanism in physical storage.
• OS where the DB server runs.

Therefore, it is hard to select a DeleteChunkSize without considering all the above factors.