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?
The Policy Server doesn't maintain in cache the SessionID. It willkeep tracks of the sessions only if you enable a Session Store. And ifyou enable a Session Store, you need to enable it on both PolicyServer and make the Realm persistent.
The SMSESSION nor the SessionSpec never have the password in it. Thepassword is only in the User Store.
You have read this :
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.
Here we should understand that the user credentials are session datawhich 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
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?
Please find below my response as per my knowledge:
- 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.
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.
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.