Symantec Access Management

Can anyone please tell me what is the difference between SM_USERSESSIONSPEC and SM_SERVERSESSIONSPEC. When I observe these header values, when the user is getting authenticated at our application(which is protected by SiteMinder), the values of these 2 headers matches, whereas if the user accessing our application, after logged into another application which is protected by SiteMinder, then these 2 header values are different. We have the HTTP header response attribute defined with the vaue of SM_USERSSSIONSPEC as part of OnAuthAccept rule in our application. We are trying to explore the options of how do we force the users to login into our application, even though they logged into other application protected by SiteMinder. We did look at setting higher level of protection, AuthZone, etc. Since I am observing the pattern in these header values, would like to understand more about these header values.

Any help you provide is much appreciated.

In addition to setting a higher protection level OR different SSO Zone - you can explore re-authenticate at same level within a single zone using the "Sensitive Tasks" Feature of CA SSO. 

How to Require Re-authentication for Sensitive Resources - CA Single Sign-On - 12.52 SP1 - CA Technologies Documentation 

As for the original request of differences.... here is the definitions and subsequent thoughts....

SM_USERSESSIONSPEC : The user’s session specification.

SM_USERSESSIONID : The session ID of a user who has already been authenticated. This is the session ID that will be assigned to the user upon successful authentication.

SM_SERVERSESSIONSPEC : Indicates the ticket that contains user session information. Only the Policy Server knows how to decode this information.

It is possible that the everytime the policy server validates the Users Session, this value is re-encrypted. Therefore it makes sense you see a different value for "SM_SERVERSESSIONSPEC" when a WebAgent does a IsValidate() call with Policy Server. In CA SSO world every time a request is validated against a different "Realm" a re-validation occurs. Therefore when requests switch between one WebAgent to another WebAgent OR even in a Single WebAgent - if the a different "Realm" is invoked a re-validation occurs of the existing SMSession.

From a Design and Implementation standpoint, My view is that we should not be using HEADERs for the explicit login requirement. We have three option's, OOB to beginwith. Evaluate and choose from them based on strategic alignment of our goals.

• Step-up Authentication using different Protection Levels.
• Sensitive Tasks using same Protection Levels and same zone.
• SSO Zones feature.

Hope this helps!

Hubert

Hi Hubert

Thank you for your response. It really helps. Based on your response, in my case the 2 different applications have 2 different web agents, and have different realm names. Since the user is authenticated at other application and then coming to my application, the session token(SM_SERVERSESSIONISPEC) is not getting validated(SM_SERVERSESSIONSPEC gets revalidated/re-encrypted only when authentication happens) because it is still valid. But what is the value of SM_USERSESSIONSPEC in this case. If the SM_SERVERSESSIONSPEC value is not chaned, then why the SM_USERSESSIONSPEC value is different. I am still not clear on this one. Could you plese throw some light here.

Thanks for your response in advance.

Thanks

Senthil

Hi Senthil,

Have a read this through this first to understand how the flow of SMSESSION cookie creation/validation :

Tech Tip - CA Single Sign-On: Web Agent :: SMSESSION Cookie 

For your reference,

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.

Now, for your use case, when the user is authenticated in app1 (agent 1) and then SMSESSION cookie submitted to app2(agent 2) , the agent 2 doesn't have the SM_SERVERSESSIONISPEC in its local User Session Cache, so it does need to send the request to Policy server for validation as per step 6 above.

All the interaction between web agent and Policy server happens via SM_SERVERSESSIONISPEC.

The HTTP header SM_USERSESSIONSPEC is not always available, so I would suggest not to have any logic based on this header.

https://docops.ca.com/ca-single-sign-on/12-52-sp1/en/configuring/policy-server-configuration/responses-and-response-groups/ca-siteminder-generated-user-attributes

Cheers,

Ujwol Shrestha

Ujwol's Single Sign-On Blog 

Thank you Shrestha for goving more information about the SM_SERVERSESSIONSPEC. I do have the custom header which gives the value of SM_USERSESSIONSPEC as part of OnAuthAccept rule. I just observed the values on these headers(SM_USERSESSIONSPEC, SM_SERVERSESSIONSPEC), so thought of looking at this as an option. I am getting the custom header(SM_USERSESSIONSPEC) consistently though. We are looking at the OOB solutions provided by SiteMinder. Thanks again to you and Hubert.