Layer7 Privileged Access Management

Tech Tip - CA Privileged Access Manager: Use CA Single Sign-On as Identity Authentication to CA PAM

By wonsa03 posted 04-12-2017 01:47 AM

  

CA Privileged Access Manager Tech Tip by Kelly Wong, Principal Support Engineer for 12th April 2017

The scope of the document is to provide the necessary steps to configure the federation partnership to achieve SSO (Single-Sign-On) between CA Single Sign-On 12.52 SP1, acting as the Identity Provider (IDP), and CA PAM 2.8 acting as the Service Provider (SP) with CA Directory as user store.

 

  1. CA PAM: Config >> 3rd Party >> Add LDAP Domain

  2. CA Single Sign-On: Infrastructure >> Directory >> User Directories
    Create the same user directory in CA Single Sign-On
  3. CA PAM: Config >> Security >> Xsuite SAML RP Configuration
    Define SAML RP entity details – Entity ID, Fully Qualified Hostname and Certificate Key Pair
    (default: gkcert.crt – Block Algorithm: tripledes, Key Algorithm: rsa-oaep)
  4. CA Single Sign-On: Federation >> Partnership Federation >> Entities
    Create local SAML2 IdP entity for CA Single Sign-On

    Create remote SAML2 SP entity (with the same Entity ID defined in Step 3) for CA PAM
    Assertion Consumer Service URL: https://<PAM FQDN>/samlsp/module.php/saml/sp/saml2-acs.php/xsuite-default-sp
  5. CA Single Sign-On: Federation >> Partnership Federation >> Partnership
    Create ‘SAML2 IDP -> SP’ partnership with the entities created in Step 4 and activate the partnership





    [Details setting up SAML 2 partnership, please refer to Getting Started with a Simple Partnership]
  6. CA PAM: Config >> Security >> Xsuite SAML RP Configuration
    ‘Add An Identity Provider’ with the details you defined in Step 5 and save the configuration
  7. CA PAM: Users >> Manage Groups >> Import LDAP Group
    Import selected LDAP user group (with ‘SAML’ Authentication Type) that includes the users authorized to federate

    [‘SAML’ authentication type option only appears when you have SAML Identity Provider defined in CA PAM]
  8. CA PAM: Config >> Security
    Login to CA PAM using FQDN and run a test

    Successful outcome:

  9. Once tested successful, authorized users can federate to CA PAM via 'Single Sign-On' authentication

 

Troubleshooting

 

Error:

State information lost

 

Resolution:

Login to CA PAM using FQDN and it is the same is associated with the Remote Assertion Consumer Service URL defined in CA Single Sign-On

[VIP FQDN is used on both if cluster is turned on]

 

 

Error:

AuthnRequest with AuthnContexts is not supported

 

Resolution:

Check the “Ignore RequestedAuthnContext” option in Federation Partnership to disregard the <RequestAuthnContext> element in the AuthnRequest message it receives from CA PAM

OR
clear the Authentication Contexts selection from CA PAM: Config >> Security


OR

create and use Authentication Context Template that matches the Authentication Context URI from CA PAM --

CA PAM -- urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified

 

 

Error:

Failed to decrypt XML element

Xsuite As SAML RP Log (Verbose):

Resolution:

Ensure CA PAM and CA Single Sign-On are sharing the same certificate to encrypt and decrypt. Also, the certificate specifications are correctly defined in CA Single Sign-On

 

 

Error:

Session: ‘xsuite-default-sp’ not valid because it is expired

Xsuite As SAML RP Log (Verbose):

 

Resolution:

Ensure that CA PAM and CA Single Sign-On server time are synchronized because there’s a validity duration on the assertion

 

2 comments
25 views

Permalink

Comments

04-29-2019 12:55 AM

This article is really helpful.

 

Please note that this article was based on 1 PAM server running in stand-alone mode.

If you have a Clustered PAM, you will need to ensure the following.

 

At the PAM side.

Each NODE need to be configured to use its local URL for ACS(Assertion Consumer Service URL).

For example, this SAML configuration is local configuration and is not replicated among other PAM nodes.

I have pam323t1.test.lab and pam323t2.test.lab and they are clustered with pam323.test.lab FQHN(VIP).

 

Following is a screenshot of my pam323t1.test.lab RP Configuration. Note the "Entity ID" is "https://pam323.test.lab" which does not change regardless of which PAM node you are configuring.

The FQHN need to be specified to use the local hostname "pam323t1.test.lab" and not "pam323.test.lab".

Following is for my pam323t2.test.lab node.

 

You can then navigate to "RP Configuration - Configured Remote SAML IdP" tab and download the metadata and import it to the IdP side.

But that is not the end of story.

What you have configured above is that, when PAM node is making the AuthnRequest(Resource Partner initiated Federation) message, it would include its own local URL as the ACS URL.

 

Following demonstrates the pam323t2 generating the AuthnRequest and it shows "AssertionConsumerServiceURL" points to "https://pam323t2.test.lab/samlsp/module.php/saml/sp/saml2-acs.php/xsuite-default-sp".

 

However, you will also need to make some modification at the IdP side to accept this ACS URL.

Following is a SAMPLE from "CA SSO" where "Accept ACS URL in the AuthnRequest" is set to YES and this is required in the Clustered PAM environment.

 

On top of that, you will need to register the PAM's each node ACS URLs as below.

 

Now, what is going to happen is.... 

PAM Node2(pam323t2) generates AuthenRequest with its own local ACS URL and send it to IdP.

IDP will check if the ACS URL in the AuthnRequest is listed in the "Remote Assertion Consumer Service URLs" and if it does then it will use that URL to POST the SAMLResponse.

 

When RP(ResourcePartner) receives this SAMLResponse, it needs to verify if the local URL that received the SAMLResponse matches the "Destination" URL as shown below. If it does not match then the SAMLResponse is not processed.

Following log is from "Configuration - Diagnostics - Diagnostic Logs - Download - CA PAM as SAML RP"

 

If the above verification goes through then the user is authenticated.

04-12-2017 12:06 PM