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.
Understanding sessions in the WSO2 Identity Server
When you log in to the Web application using WSO2 Identity Server, a single sign-on (SSO) session is created by the Identity Server for the user of the application. Also, as the user logs in to the Web application, there is session created in the Web application itself for the user. These are two separate sessions and they are not synchronized with each other.
For an example, if the Web application has a session timeout of 20 minutes and the WSO2 IS SSO session timeout is 5 minutes, the application users will not see the login page up to 20 minutes. That is because WSO2 IS is not invalidating the session by force on the Web application.
If the Web application session timeout is 5 minutes and the WSO2 IS SSO session timeout is 20 minutes, the users will not see the login page up to 20 minutes. This is because even when the Web application container session timeout after 5 minutes, the session was kept alive since WSO2 IS SSO session is still alive. The user will not be redirected to the login screen of the SP until the WSO2 IS SSO session is invalidated.
WSO2 Identity Server creates separate SSO session for SSO login and it is different from the session that is created when you log in to the Identity Server management console.
When end user logs in through the WSO2 Identity Server for the service provider application (using SAML2 SSO, OpenID Connect, Passive STS, etc.), the Identity Server creates a SSO session for end users and a cookie that is related to the created SSO session is set to the user’s browser.
This cookie can be seen as commonauthId. It is set to the user’s browser with the hostname of WSO2 Identity Server instance and the value of the commonauthId cookie is the SSO session identifier. When SSO session is created in the WSO2 Identity Server, the session is put into the session cache and persisted to the database. To persist it in to the database, you must enable the session persistence.
The following configuration found in the <IS_HOME>/repository/conf/identity/identity.xml file, under the the Server and JDBCPersistenceManager elements is used to enable session persistence.
<SessionDataPersist>
<Enable>true</Enable>
<Temporary>false</Temporary>
<PoolSize>100</PoolSize>
<SessionDataCleanUp>
<Enable>true</Enable>
<CleanUpTimeout>20160</CleanUpTimeout>
<CleanUpPeriod>1140</CleanUpPeriod>
</SessionDataCleanUp>
<OperationDataCleanUp>
<Enable>true</Enable>
<CleanUpPeriod>720</CleanUpPeriod>
</OperationDataCleanUp>
</SessionDataPersist>
The following table describes the elements of the configurations mentioned above.
| Configuration element | Description |
|---|---|
Enable | This enables the persistence of session data. Therefore, this must be configured to |
| Temporary | Setting this to |
| PoolSize | To improve performance, OAuth2 access tokens are persisted asynchronously in the database using a thread pool. This value refers to the number of threads in that thread pool. |
SessionDataCleanUp | This section of the configuration is related to the cleaning up of session data. |
Enable | Selecting true here enables the cleanup task and ensures that it starts running. |
CleanUpTimeOut | This is the timeout value (in minutes) of the session data that is removed by the cleanup task. The default value is 2 weeks. |
CleanUpPeriod | This is the time period (in minutes) that the cleanup task would run. The default value is 1 day. |
| OperationDataCleanUp | This section of the configuration is related to the cleaning up of operation data. |
Note: To work with Single Sign-On you must have session persistence enabled.
- See Single Sign-On for more information.