Handling resource access after a 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:

The authentication scheme used is a basic authentication.

When a user has been idle for some time, the idle timeout configured in the protecting realm configuration ends the session. Accessing the resource they will face a Basic challenge.

If the user cancels the credentials challenge box, then edits the URL browser, they gain access again without authenticating.

 

 

Environment

Applies to the SiteMinder Policy Server any version

Cause

When authenticating with HTTP Basic, the client is challenged the first time only because the Authorization header isn't being sent from the client again. Once it has been sent and the server sends something other than a 401, the client caches those credentials and re-sends them with every request.

Resolution

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.