Symantec Access Management

Expand all | Collapse all

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

Jump to Best Answer
  • 1.  CA SSO : How PS validates the SMSESSION cookie which is created by another PS?

    Posted 05-07-2018 02:23 AM

    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



  • 2.  Re: CA SSO : How PS validates the SMSESSION cookie which is created by another PS?

    Posted 05-07-2018 04:01 AM

    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



  • 3.  Re: CA SSO : How PS validates the SMSESSION cookie which is created by another PS?

    Posted 05-07-2018 09:24 AM

    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?



  • 4.  Re: CA SSO : How PS validates the SMSESSION cookie which is created by another PS?
    Best Answer

    Posted 05-07-2018 04:34 AM

    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



  • 5.  Re: CA SSO : How PS validates the SMSESSION cookie which is created by another PS?

    Posted 05-07-2018 09:24 AM

    Hi Ankur,

     

    Thanks for your response.