Creating PKI Certificate Authentication Realms

If you are using a public key infrastructure (PKI) to create and manage digital certificates for login security, you can configure Deployment Automation to use your organization's PKI certificates for user authentication. When this authentication is configured properly, user authentication happens automatically based on a PKI certificate installed in the user's Web browser.

Important: You cannot use SSO and PKI Certificate authentication realms in the same implementation; they are incompatible. If you want to use Smart Cards with SSO, you should configure this in SBM. See the SBM documentation for details.

Multiple PKI Certificate authentication realms can be set up to support multiple CA certificates.

When you create a PKI Certificate authentication realm in Deployment Automation, you must provide information about your PKI Certificate installation as described in the following table.

For additional configuration requirements, see PKI Certificate Authentication Configuration.

PKI Certificate Authentication Realm Properties table

Field Description
Authorization Realm Select Internal Security; PKI Certificate authentication realm always uses Internal Security for authorization
CA Certificate File Specify the path, including the file, where you have stored the issuer's certificate information. For example:

D:\auth\ca.crt

Username Attribute Select either Subject or Alternative Subject and then select from the available attributes. This attribute should map to the value in your certificate that your certificate implementation uses for username. See PKI Certificate Parsing.
Email Attribute Select either Subject or Alternative Subject and then select from the available attributes. This attribute should map to the value in your certificate that your certificate implementation uses for email ID. See PKI Certificate Parsing.
Full Name Attribute Select either Subject or Alternative Subject and then select from the available attributes. This attribute should map to the value in your certificate that your certificate implementation uses for full name. See PKI Certificate Parsing.
Verify Revocation Select this if you want to check to see if the user certificate has been revoked since it was last authenticated through the PKI certificate.
Revocation Strategy If Verify Revocation is selected, select the revocation strategy you want to use. Options are as follows:
  • Strict: (Default) This strategy sets the certificate revocation status to true if any exception happens during verification process. For example, if an OCSP service URL is inaccessible or a downloaded CRL cannot be read or parsed, the certificate is considered revoked.
  • Mild: This strategy ignores exceptions described for strict verification and continues verification using the next verification point. If all verification points are ignored or revocation status is false for all of them then the resulting revocation status is false.
Revocation Source Type If Verify Revocation is selected, select the revocation source type you want to use. Options are as follows:
  • Internal: Select this to verify using a certificate revocation list that you have identified to the Deployment Automation server. See Configuring Internal Revocation Verification. This verifies the revocation status against OCSP URLs and CRL lists that are specified in the certificate file you have identified in the server configuration.

    The following CRL distribution point URL formats are supported:

    http(s)

    For example:

    http://serverName:8080/crl.pem, https://serverName:8443/crl.der

    ldap

    For example:

    "ldap://ldapserverName:389/ou=Users, dc=sda,dc=com?certificateRevocationList;binary"

  • External: (Default) Select this to verify using the certificate revocation list in the location that you specify in the CRL Distribution Point field.

    The following CRL distribution point URL formats are supported:

    http(s)

    For example:

    http://serverName:8080/crl.pem, https://serverName:8443/crl.der

    ldap

    For example:

    "ldap://ldapserverName:389/ou=Users dc=sda,dc=com?certificateRevocationList;binary"

    file

    "file:///D:/StrongAuth/crl.der"

  • Both: Select this to verify using both internal and external certificate revocation lists.
OCSP Server URL If Revocation Source Type is set to External or Both and you want to use an Online Certificate Service Provider (OCSP) to verify certificate revocation, enter the URL that points to the service. For example:

http://ServerName:9999

Note: The Deployment Automation server and OCSP server must use the same time and time zone. Otherwise, depending on your selection for Revocation Strategy, the following will occur:
  • If Strict, the login will fail
  • If Mild, verification using OCSP will be skipped
CRL Distribution Point If Revocation Source Type is set to External or Both and you want to point to a certificate revocation list file, specify the URL that points to your file. For example:

http://ServerName:8080/crl.file

Use Revocation Cache If Verify Revocation is selected, you can select this option to cache the results from the last revocation verification to avoid performance degradation for each login to the server. The following are cached for the number of hours specified in the Revocation Cache Expiration Period.
  • Revocation status: The last certification revocation status is stored in the cache and are used without additional verification for subsequent requests that have this certificate in their attributes.
  • Certificate Revocation Lists (CRL): Keeps downloaded lists in memory and stores them locally in a Deployment Automation profile (<sda_profile>/var/cache/pki). Multiple simultaneous downloads of CRL lists from single endpoint is not allowed; if there is already an active download of a CRL list, all other requests are postponed until the download is completed.

Both caches are cleared when the authentication realm is updated.

Revocation Cache Expiration Period If Use Revocation Cache is selected, specify the time period in hours after which to refresh the cache. The default is 24 hours.