CA SSO : How PS validates the SMSESSION cookie which is created by another PS?

[Dhilip kumar Mari]

Hi,

 

Assume that I have two policy servers A and B. While I am trying to access the application for the first time, Policy server A comes into picture and SMSESSION cookie is getting created. Now, if the next request goes to the Policy Server B, how does Policy Serve B validates the SMSESSION? I am aware that webagent will make validate call with SESSIONID and SESSIONSPEC, but what policy server B will do (after decrypting SESSIONSPEC)?

 

1) How does it come to know that particular SESSIONID is valid as only Policy Server A will have corresponding SESSIONID in its cache? Will it just validate the timeout details (and add in its cache if session is not timeout)?

2) Will SMSESSION has password detail of user as I could see below line in the document?
<<
Session tickets contain credentials and other information relating to a session (including user credentials). Agents embed session tickets in CA Single Sign-On cookies.
>>

3) If yes,

a) May I know which parameter of SESSIONSPEC will be used to store user credentials?
b) Will Policy server B validate the username and password by making a call to user store?

4) In case, if the authentication will be happening only once(i.e while creating a new SMSESSION), then what is the user of Authentication Cache of policy server? When will it be used?

 

Thanks,

Dhilip

[Patrick Dussault]

Hi Di1ip,

 

The Policy Server doesn't maintain in cache the SessionID. It will
keep tracks of the sessions only if you enable a Session Store. And if
you enable a Session Store, you need to enable it on both Policy
Server and make the Realm persistent.

The SMSESSION nor the SessionSpec never have the password in it. The
password is only in the User Store.

 

You have read this :

 

Key Store

 

Session ticket keys are used by the Policy Server to encrypt session
tickets. Session tickets contain credentials and other information
relating to a session (including user credentials). Agents embed
session tickets in CA Single Sign-On cookies, but cannot do not have
access to the session ticket keys, which never leave the Policy
Server.

 

https://docops.ca.com/ca-single-sign-on/12-8/en/installing/install-a-policy-server/configure-odbc-databases-as-policy-session-key-and-audit-stores

 

 

Here we should understand that the user credentials are session data
which are considered as proof of identity, but not the password.

 

Tell us if you need further precision,

 

Further reading about the session data :

CA Single Sign-On - 12.8
https://docops.ca.com/ca-single-sign-on/12-8/en/configuring/web-agent-configuration/session-protection/session-cookie-management

 

 

Best Regards,
Patrick

[Dhilip kumar Mari]

Hi Patrick,

 

Thanks for your response.

 

Could you please let me know the actions which will be performed by policy server B on receiving the validate call from web agent? When the session will be considered valid? What are the validations which will be performed?

[Ankur Taneja]

Hello Di1ip,

 

Please find below my response as per my knowledge:

 

1) How does it come to know that particular SESSIONID is valid as only Policy Server A will have corresponding SESSIONID in its cache? Will it just validate the timeout details (and add in its cache if session is not timeout)?

 

- Web Agent Places the Session Ticket inside the SMSESSION under ATTR_SESSIONSPEC, and then web agent is responsible for validating the user, manage timeout etc from cache and if value not present in cache will go the Policy server for authentication/authorization. It can go to any Policy server based on what load balancing mechanism you have out in HCO i.e. failover, roundrobin or cluster. 

 

All Policy server in an enterprise environment share the same Key store to encrypt and decrypt and hence it enable then to validate the user even if the first request went to different policy server. 

 

 

2) Will SMSESSION has password detail of user as I could see below line in the document? 
<<
Session tickets contain credentials and other information relating to a session (including user credentials). Agents embed session tickets in CA Single Sign-On cookies.
>>

 

- Password will not be stored in the SMSESSION as highlighted by Patrick above. 

3) If yes,

a) May I know which parameter of SESSIONSPEC will be used to store user credentials?

- Password will not be stored

b) Will Policy server B validate the username and password by making a call to user store?

- No, if the user has an active SMSESSION as the user context is already present in it. Yes, if SMSESSION has timed-out. 

4) In case, if the authentication will be happening only once(i.e while creating a new SMSESSION), then what is the user of Authentication Cache of policy server? When will it be used?

It actually depends, generally all sessions are Transient i.e. Non-persistent which are generated and are browser session specific. Once browser is closed the session is invalidated. As mentioned by Patrick you can enable Session Store for Persistent Sessions. 

 

Thank you

Ankur Taneja

[Dhilip kumar Mari]

Hi Ankur,

 

Thanks for your response.