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 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.
...
|
|---|
| 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 agent application SSO session (see Figure 4).
...
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 agent 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 agent 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 agent application session timeout, we are in a situation where web agent application calls the application where there is no user session. Web agent 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 Session Expiration#Preventing 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 Using Web Server Filter and Not Refreshing SSO Sessionprevious 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 agent application sessions and thus when web agent application session ends, no re-authentication is needed from the user to continue using the application (see Figure 7).
...