×
$helper.renderConfluenceMacro('{bmc-global-announcement:$space.key}')
 
 
  •  

 

This documentation supports the 19.02 version of Remedy Single Sign-On.

To view an earlier version, select the version from the Product version menu.
Remedy Single Sign-On 19.02 ... Administering Configuring Remedy SSO for authentication Configuring authentication

Certificate-based authentication process

Remedy Single Sign-On (Remedy SSO) supports certificate-based authentication. To use the certificate-based authentication, you must ensure that:

  • Client has a valid Public Key Certificate
  • SSL support is configured for the server
  • Client authentication is configured on the server

The following image shows the tasks that you need to perform to configure the certificate-based authentication in Remedy SSO.

CertificateBasedAuthentication

Configuring the Tomcat server to ask clients for certificates

If you are using using a load balancer and SSL termination is done on the load balancer, there is no need to configure the Tomcat server. If you are not using a load balancer, you must configure the Tomcat server that host the Remedy SSO application to ask clients for certificates. You must also configure the Tomcat server truststore with trusted CA certificates.

  1. Stop the Apache Tomcat server that is being used for Remedy SSO.
  2. Open the <TomcatInstallationDirectory>/conf/server.xml file and modify the <Connector> tag.
  3. Set the clientAuth attribute to want as specified in the following code block.
<Connector port="18443" protocol="HTTP/1.1" SSLEnabled="true"
		maxThreads="150" scheme="https" secure="true"
		clientAuth="want" sslProtocol="TLS"
		keystoreFile="conf/cert/server-keystore.jks"
		keystorePass="changeit"
		truststoreFile="conf/cert/server-truststore.jks" 
		truststorePass="changeit" />

Important

Do not set the clientAuth attribute to true, because it becomes mandatory for the client to provide a trusted certificate to the server that might break certain communication between Remedy SSO and an agent.


Configuring the certificate-based authentication  

Before you begin

  • Ensure that you have performed the Remedy SSO server configuration. For more information on server configuration, see Configuring the Remedy SSO server.
  • Configure a realm for the authentication. For more information on realm configuration, see Configuring Realms.
  • Obtain the following information:
    • The required digital certificate filed name to get the user ID from the client certificate.
    • Custom responder URI if you want to enable OCSP validation.
    • Custom CRL DP URI if you want to enable CRL validation.

To configure certificate-based authentication

  1. In the left navigation panel of the Add Realm or Edit Realm page, click Authentication .

  2. In the Authentication Type field, click CERT.

  3. (Optional) Select the Enable AR authentication for bypass check box to enable bypass URL to authenticate against AR.
    For more information about enabling BMC Remedy AR System authentication for bypass, see Enabling AR authentication for bypassing other authentication methods.

  4. Enter the following certificate-based authentication details.

    FieldDescription
    User ID

    Field that is used to get the user ID from the client certificate. If you select Custom Attribute, you must save the information and edit the realm again to provide the name or OID of the attribute.

    The maximum length for the User ID field is 80 characters. If the User ID field exceeds 80 characters after transformation, it causes a redirection loop when the user tries to access the integrated Remedy applications and the browser shows the 'Page cannot be displayed' message.

    Forwarded Certificate

    The HTTP header names to construct the certificate chain. Select this option if the client certificate chain is passed through HTTP headers and when the load balancer or reverse proxy is used in front of Tomcat servers and SSL termination is done on the load balancer or the reverse proxy.

    If you select this option, you must enter the HTTP header names in the HTTP Header Name field. Header Names is a comma separated header names following the same order as client certificate chain from the end-entity certificate to the root CA certificate.

    Forward client certificate example 
    # this option is mandatory to force apache to forward the client cert data to tomcat
  SSLOptions +ExportCertData
 
  RequestHeader set X-Client-Cert "%{SSL_CLIENT_CERT}s"
  RequestHeader set X-Client-Cert-Chain-0 "%{SSL_CLIENT_Chain_0}s"
  RequestHeader set X-Client-Cert-Chain-1 "%{SSL_CLIENT_Chain_1}s"
    Enable Validation

    Enables certificate validation. If you select this option, you can select from the following validation options:

    • Trusted Certificates
    • OSCP
    • CRL
    • OCSP/CRL Check On End-Entity Only

    Client certificate chain is validated against the configured truststore when this option is selected.

    Trusted Certificates

    Specifies whether the system uses default or custom certificates.

    If you select the Custom option, you must provide the truststore file and the truststore password. Ensure that you have already placed the truststore file on the server. For more information about importing CA certificates to truststore, see Importing CA certificates to a truststore  .

    Truststore FileName or path of the truststore file. This field is available only when you select the Custom option in the Trusted Certificates field.
    Truststore PasswordPassword for the truststore file. This field is available only when you select the Custom option in the Trusted Certificates field.
    Enable OCSP

    Enables OCSP check. If you select this option, you must enter the custom OCSP responder URI in the OCSP Responder URL field.

    If you do not provide any OCSP responder URI, the system uses the OCSP responder URL that is specified in the certificate.

    Enable CRLEnable CRL check. If you select this option, you must enter the custom CRL DP URI in the CRL DP URL field. You can provide a HTTP URI.
    OCSP/CRL Check On End-Entity OnlyEnables the OCSP and CRL validation to be carried out only for end-entity certificate.
  5. (Optional) Click Enable Chaining Mode and perform the following steps to enable authentication chaining. For more information about the authentications that you can chain with cert-based authentication, see Authentication chaining.
    1. Click Add Authentication.
    2. Select the required authentication type and enter the authentication details.
    3. Repeat Step a through Step b to add more authentications for the realm.

  6. Click Save.

Importing CA certificates to a truststore

You can import CA certificates on the following two truststores as required:

  • Truststore of the the Tomcat server or the load balancer: Used for certificate-based authentication that enables the Tomcat server or the load balancer to send an appropriate information to the client so that the client returns only the trusted certificate.

  • Truststore used by Remedy SSO for certificate validation: Used if you want Remedy SSO to perform an extra validation on the client certificate, such as OCSP or CRL check. Certificate validation including OCSP or CRL check might be supported on the Tomcat server or the load balancer. If all the necessary validations are already enabled on the Tomcat server or the load balancer, you might skip the validation at Remedy SSO level.

    Note

    If customer has intermediate certificates, they must be imported into the truststore as well.

Related topics

Transforming User ID to match Login ID

Troubleshooting authentication issues

Was this page helpful? Yes No Submitting... Thank you
Last modified by Olha Horbachuk on Aug 01, 2019
configuration administering

Comments

Log in or register to comment.

BMC Remedy AR System authentication process
Configuring Kerberos authentication
© Copyright 1991 – 2019 BMC Software, Inc.
© Copyright 1991 – 2019 BladeLogic, Inc.
Legal notices

Powered by Atlassian Confluence and Scroll Viewport

© Copyright 2005-2023 BMC Software, Inc. Use of this site signifies your acceptance of BMC’s Terms of Use . BMC, the BMC logo, and other BMC marks are assets of BMC Software, Inc. These trademarks are registered and may be registered in the U.S. and in other countries.