Session timeout in Basic Authentication

Products

• CA Single Sign On Secure Proxy Server (SiteMinder)
• CA Single Sign On SOA Security Manager (SiteMinder)
• CA Single Sign-On

Issue/Introduction

Description:

When a user has been idle for some time then the idle timeout configured in the protecting realm configuration ends the session.

If the user cancels the credentials challenge box and edits the URL browser, he gains access again without authenticating.

The authentication scheme used is a basic authentication.

What is happening there? How can we fix this issue?

Solution:

When the user cancels the challenge box to enter his credentials and modify the URL, the Web browser is then sending the credentials itself.

There is no way to forbid this to happen with a basic authentication.

If you want to avoid this problem, you will have to use Form based authentication.

Some more details on what is happening:

When you use a basic authentication, and you hit a protected page, the Web Agent sets a cookie to your browser called SMCHALLENGE=YES at the same time when it prompts you. Then, when you post your credentials, SiteMinder will expect to see this cookie played by the browser along with the credentials.

• If RequireCookies=YES, and your browser doesn't play the cookie, you will get the 403 "missing cookie" error.
  
  
• If you set RequireCookies=NO, SiteMinder doesn't care if it sees the SMCHALLENGE cookie from the browser. The only time customers set it to NO is if they have some kind of non-browser device that is submitting Basic credentials to bypass SiteMinder security, and that device is not capable of storing/playing cookies. In that case, the device must replay the Basic credentials with each request, which re-authenticates the user each time, eliminating the need for an SMSESSION cookie. If your browser is accepting cookies, then you will never notice a difference with RequireCookies=NO. That warning is there in the documentation, because if you set it to NO, and you are using a basic authentication, and some user has a browser that doesn't do cookies, then they will get to the first page after they authenticate, but when they hit the next page, they will get prompted again. Then, if the browser caches some of the pages, along with the Basic authorization header (aka Basic credentials), then the user may be able to see a page that he hit a long time ago (in the same browser session of course) without being prompted because timeouts don't work, since they are built into the SMSESSION cookie.

Environment

Release:
Component: SMPLC