What does and SiteMinder Production SMSESSION Cookie contains
search cancel

What does and SiteMinder Production SMSESSION Cookie contains

book

Article ID: 378332

calendar_today

Updated On:

Products

CA Single Sign On Agents (SiteMinder) CA Single Sign On Federation (SiteMinder) CA Single Sign On Secure Proxy Server (SiteMinder) CA Single Sign On SOA Security Manager (SiteMinder) SITEMINDER

Issue/Introduction

Questions

  • How is SMSESSION cookie created?
  • What all information is contained in SMSESSION cookie?
  • If someone steals, SMSESSION cookie, will they be able to decrypt it and retrieve information out of it ?

Environment

ANY
ANY

Resolution

Answers

 

How is SMSESSION cookie created?

To understand how and who creates the SMSESSION cookie, we need to understand the user login flow. It goes something like below in the simplistic scenario:

 

  1. The Agent collects the user’s credentials.
  2. The Agent sends the Login() request to the Policy Server passing the received credentials. The Policy Server verifies the credentials and creates a Session Spec that represents the newly created user session. Policy server encrypts the Session Spec using Session Ticket Key (Persistent Key). The encrypted Session Spec is then sent back to the Agent together with the Session ID and other session related parameters (idle timeout, expiration timeout, etc.).
  3. The Agent embeds the Session ID and the Session Spec in an encrypted SMSESSION cookie that is sent back to the user’s browser. This encryption is done using Agent Keys.
  4. The Agents also saves the Session ID and the Session Spec in its User Session Cache.
  5. Any time when an authenticated user accesses the Web site, the browser submits the SMSESSION cookie together with a HTTP request.
  6. When the Agent receives the SMSESSION cookie, it decrypts the SMSESSION cookie using Agent Keys, extracts the Session ID and the Session Spec it checks them against the values stored in the User Session Cache. If the Agent cache doesn’t contain corresponding entry, the Agent uses the Validate() call to pass the Session ID and the Session Spec to the Policy Server for validation.
  7. Once Policy server receives the validation request from Web Agent, it decrypts the Session Spec using Session Ticket Key (Persistent Key) and then performs validation.
  8. If the validation succeeds, the Policy Server returns the updated Session Spec to the Agent. The Session ID is not modified in the course of validation.

 

What all information is contained in SMSESSION cookie?

SMSESSION Contains following information:

 

  • ATTR_USERDN. The user's distinguished name.
  • ATTR_SESSIONSPEC. The session specification returned from the login call.
  • ATTR_SESSIONID. The session ID returned from the login call.
  • ATTR_USERNAME. The user's name.
  • ATTR_CLIENTIP. The IP address of the machine where the user initiated a request for a protected resource.
  • ATTR_DEVICENAME. The name of the agent that is decoding the token.
  • ATTR_IDLESESSIONTIMEOUT. Maximum idle time for a session.
  • ATTR_MAXSESSIONTIMEOUT. Maximum time a session can be active.
  • ATTR_STARTSESSIONTIME. The time the session started after a successful login.
  • ATTR_LASTSESSIONTIME. The time that the Policy Sever was last accessed within the session.

 

SESSIONSPEC in turn contains following information. SESSIONSPEC can only be decrypted by Policy server.

It contains following information:

 

  • SessionVersion
  • SessionStartTime
  • SessionLastTime
  • SessionMaxTimeout
  • SessionIdleTimeout
  • SessionLevel
  • SessionId
  • SessionIp
  • SessionDn
  • SessionDirOid
  • SessionDirName
  • SessionUnivId
  • SessionType
  • SessionAnonymous
  • SessionImpersonatorName
  • SessionLoginName
  • SessionPersistent
  • SessionDrift
  • SessionImpersonatorDirName
  • SessionAuthContext