This page presents different possible scenarios that differ in the way on how the session timeout are configured and sessions refreshed. The purpose is to try to explain the intricacies of multi-level timeouts.

Using SAML SP and not refreshing SSO session

The most typical case is to have the SSO session get a timeout before the application session. This is quite typical as the application session usually has a sliding window, i.e., when user's web browser sends requests to the application the application session refreshes.

Figure 1 shows a situation where user first logs in and is taken to Ubisecure SSO for authentication. At this point the SSO session is created. Application session gets created when user is taken to the application after successful login. Application session is refreshed with every request to the application thereafter. When the SSO session timeout is reached, the SSO session is removed, but the application session continues. When user decides to logout from the application re-authentication happens, because there is not any valid SSO session.


Figure 1: Scenario where SSO session gets a timeout before application session

If we change the scenario so that user would not access the application after logging in, the application session would end before the SSO session. This would results in a situation where re-authentication wouldn't be required when user would access the application again. This scenario is depicted in Figure 2.


Figure 2. Scenario where Application session gets a timeout before SSO session

Using SAML SP and refreshing SSO session

The only difference in this scenario compared to the first one is that now we use some of the SSO session refresh mechanisms in the end-user application. Figure 3 shows a situation, where user first logs in and is taken to Ubisecure SSO for authentication. At this point the SSO session is created. Application session gets created when user is taken to the application after successful login. Application session is refreshed with every request to the application thereafter.

At some point close to the SSO session timeout, the application uses some of the SSO session refresh mechanisms. For example, the could be a JavaScript timer that executes a JavaScript callback that requests the 1x1 pixel size image from Ubisecure SSO thus refreshing the SSO session. User has decided not to use the application for a period of time longer than the application session timeout and this results in the SAML SP redirecting the browser to Ubisecure SSO for re-authentication. Ubisecure SSO notices that there is an existing SSO session for the user and redirects browser back to the application without requiring the user to re-authenticate. At this point, the application creates a new session for the user.


Figure 3. Scenario where SSO session is refreshed from the application

Using Web Server Filter and not refreshing SSO session

In this scenario a web server filter is used in front of the application. Web server filters have their own SSO session timeout and don't know anything about the application session whereas SAML SP doesn't have any session timeout and it knows about the application session. Because the web server filter acts as a proxy to the application, every request to the application goes through it. This will result in every request refreshing the web application SSO session (see Figure 4).


Figure 4. Scenario where web server filter is used and SSO session is not refreshed

If we change the scenario so that user doesn't access the application after logging in until the application session ends, we will get a situation where no re-authentication is needed (see Figure 5). The reason is that web application session has also ended, but the Ubisecure SSO session hasn't.


Figure 5. Scenario where web server filter session expired first

When the web application session timeout is longer than application session, we might end up in a situation depicted in Figure 6. User has been using the application for so long that the SSO session has expired as it is not automatically refreshed. When there is a pause longer than the application session timeout, but shorter than the web application session timeout, we are in a situation where web application calls the application where there is no user session. Web application doesn't know anything about the application session and calls the application normally because its own session is still valid. Application would most probably just create a new session for the user. This might be problematic from the application's point of view.

Luckily, there are ways to solve the problem of expiring application session as we saw in chapter Preventing SSO and Application Session Expiration in Session expiration.


Figure 6. Scenario where web server filter session is longer than application session

Using Web Server Filter and refreshing SSO session

This scenario is otherwise similar to the scenario in previous chapter, but the SSO session is now refreshed from the application. This refreshing will result in the SSO session lasting longer than the application and web application sessions and thus when web application session ends, no re-authentication is needed from the user to continue using the application (see Figure 7).


Figure 7. Scenario where web server filter is used and SSO session refreshed

Browser not supported