Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Published by Scroll Versions from space IDS and version 8.2.0

...

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.

...

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.

...

This scenario is otherwise similar to the scenario in Using Web Server Filter and Not Refreshing SSO Session 4508090471, 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).

...