Why does another CA PAM Client not do SSO even SAML Authentication has been used before
Article ID: 132285
Updated On:
Products
CA Privileged Access Manager - Cloakware Password Authority (PA)
CA Privileged Access Manager (PAM)
Issue/Introduction
We have integrated CA PAM with CA SSO / SPS - while CA PAM is configured as RP and CA SSO as IdP.
CA SSO Authentication is using Kerberos with fallback to Form.
If the login to CA PAM happens in a kerberised Web Browser (by a Windows domain user) all works nicely - the user is automatically authenticated to CA PAM and can open the UI without being challenged.
However, if the CA PAM Client is used instead the user gets redirected on Form Authentication.
What is the reason for this different behaviour of CA PAM's SAML-Authentication in the Web Browser and the PAM Client?
CA SSO Authentication is using Kerberos with fallback to Form.
If the login to CA PAM happens in a kerberised Web Browser (by a Windows domain user) all works nicely - the user is automatically authenticated to CA PAM and can open the UI without being challenged.
However, if the CA PAM Client is used instead the user gets redirected on Form Authentication.
What is the reason for this different behaviour of CA PAM's SAML-Authentication in the Web Browser and the PAM Client?
Environment
Release:
Component: CAPAMX
Component: CAPAMX
Resolution
Reason for this is that the CA PAM Client is not kerberised and not retrieving Windows NTLM credentials.
Moreover, several instances of the PAM Client do not share a real SSO feature.
Upon opening another instance of the PAM Client one needs to redo the SAML-Auth in your case - i.e. unlike the button name may imply, there is no SSO in this case.
Also, when PAM is configured to do SAML-Auth, in a PAM Client clicking the "Single Sign-On" button - it is always performing a Form based Authentication where the login dialogue shown comes from the IdP.
This is because the PAM Client does not support SSO methods like retrieving the user's NTLM credentials - or Kerberos tickets.
Note, each instance of the PAM Client basically runs in its own runtime enviornment which does not use any shared memory or cookies from other instances of the PAM Client.
You might verify this by confirming a new folder gets generated in
<CA PAM Client>\temp\jxbrowser-chromium-<version>\capam_client_<Runtime_ID>
for each PAM Client instance launched.
Each instance use its own Cookie store (instance-specific SQLite DB file).
Due to this there is no common authentication token generated by the SAML-Auth by the PAM Client which could be reused in another instance of the Client.
However, in a Web Browser you might observe the following cookies being generated upon SAML-Auth:
- host to connect to (RP) puts (JSESSIONID) when PAM UI login URL loads
- once you trigger the login process it also puts (PHPSESSID)
- in case you trigger SAML-login the IDP puts its own cookies: (_idp_authn_lc_key, JSESSIONID and XSUITE_IDP_AUTHN) when the IDP is another PAM instance (in case of SPS the names of these cookies may vary)
- once the SAML-login is complete the IDP puts also (PHPSESSID) and (_idp_session) (in case IDP is another PAM)
- finally RP generates (XsuiteSAMLAuthToken and jsid)
Since each browser instane share the same cookie store:
- (XsuiteSAMLAuthToken) can be reused in case another instance of PAM-UI is launched (of the same browser vendor) and grants access to the RP without having to re-authenticate (using the SAML-login)
Also in case a Web Browser is used, CA SSO/SPS as IDP will retrieve the user's context for SSO if another Website protected by CA SSO/SPS had been visited (whatever authentication mechanism was used (IWA, SAML, Form, ...)) and can basically share this token for another SAML enabled instance of the browser to PAM.
Bottom Line:
CA PAM Client's "Single Sign-On" feature is always performing a Form based Authentication where the login dialogue shown comes from the IdP.
It does not share any token being generated by any SAML application or any other instance of the PAM Client.
Hence any instance of the PAM Client needs to redo the full form based authentication upon clicking the "Single Sign-On" button.
Moreover, several instances of the PAM Client do not share a real SSO feature.
Upon opening another instance of the PAM Client one needs to redo the SAML-Auth in your case - i.e. unlike the button name may imply, there is no SSO in this case.
Also, when PAM is configured to do SAML-Auth, in a PAM Client clicking the "Single Sign-On" button - it is always performing a Form based Authentication where the login dialogue shown comes from the IdP.
This is because the PAM Client does not support SSO methods like retrieving the user's NTLM credentials - or Kerberos tickets.
Note, each instance of the PAM Client basically runs in its own runtime enviornment which does not use any shared memory or cookies from other instances of the PAM Client.
You might verify this by confirming a new folder gets generated in
<CA PAM Client>\temp\jxbrowser-chromium-<version>\capam_client_<Runtime_ID>
for each PAM Client instance launched.
Each instance use its own Cookie store (instance-specific SQLite DB file).
Due to this there is no common authentication token generated by the SAML-Auth by the PAM Client which could be reused in another instance of the Client.
However, in a Web Browser you might observe the following cookies being generated upon SAML-Auth:
- host to connect to (RP) puts (JSESSIONID) when PAM UI login URL loads
- once you trigger the login process it also puts (PHPSESSID)
- in case you trigger SAML-login the IDP puts its own cookies: (_idp_authn_lc_key, JSESSIONID and XSUITE_IDP_AUTHN) when the IDP is another PAM instance (in case of SPS the names of these cookies may vary)
- once the SAML-login is complete the IDP puts also (PHPSESSID) and (_idp_session) (in case IDP is another PAM)
- finally RP generates (XsuiteSAMLAuthToken and jsid)
Since each browser instane share the same cookie store:
- (XsuiteSAMLAuthToken) can be reused in case another instance of PAM-UI is launched (of the same browser vendor) and grants access to the RP without having to re-authenticate (using the SAML-login)
Also in case a Web Browser is used, CA SSO/SPS as IDP will retrieve the user's context for SSO if another Website protected by CA SSO/SPS had been visited (whatever authentication mechanism was used (IWA, SAML, Form, ...)) and can basically share this token for another SAML enabled instance of the browser to PAM.
Bottom Line:
CA PAM Client's "Single Sign-On" feature is always performing a Form based Authentication where the login dialogue shown comes from the IdP.
It does not share any token being generated by any SAML application or any other instance of the PAM Client.
Hence any instance of the PAM Client needs to redo the full form based authentication upon clicking the "Single Sign-On" button.
Feedback
Yes
No
Powered by
