Configuring certificate-only authentication for HTTP access services

You can configure the HTTP access service to accept client X.509 certificates in place of name and password credentials to authenticate mobile users.

To configure certificate-only authentication, the following resources must be available:

You can create new resources to use in this context or modify existing resources as needed.

Name and password credentials can be intercepted during transmission, exposing your network to unauthorized access. To provide users of mobile applications such as IBM® Connections and Sametime® with secure access to application servers, configure certificate-only authentication.

Complete the following steps to enable certificate-only authentication.

  1. From the properties pages of the LDAP-bind authentication profile, click the LTPA/SSO tab, click Enable LTPA, and specify the LTPA settings for your network.
  2. To complete the LTPA configuration, share cryptographic keys with application servers for which you want to configure SSO, for example an IBM Connections server. The keys are used to generate the LTPA tokens that serve as a user's credentials across other servers in the realm. You can generate and export keys from SafeLinx and import them to application servers. Or you can generate and export keys from an application server and import them to SafeLinx.
    • Generate keys from SafeLinx. From the properties pages of the LDAP-bind authentication profile, click the LTPA/SSO tab, click Generate new keys, type and confirm a password, and then click Apply. The password must be 6 - 32 characters long.
      Remember: Be sure to record the password for future reference! You must enter the password when you import keys to an application server.

      The generated keys are stored internally by SafeLinx. You can now export them to a key file and then import them on application servers for which you want to configure SSO.

      When you export a key file, specify a full path for the name of the key file. If you do not specify a full path, the key file is exported to a default location. On Windows, the key file is exported to the \ProgramFiles\HCL\SafeLinxServer\logs directory, and on Linux™ or UNIX™, to the root (/) directory.

      Note: If you run SafeLinx Administrator from a remote computer, rather than from the SafeLinx Server, when you export a key file, the file is stored on the SafeLinx Server computer, not the computer that runs the SafeLinx Administrator.
    • Import keys from an application server. Export a previously generated key file from an application server for which you want to configure SSO, and then import them to SafeLinx.

      From the properties pages of the LDAP-bind authentication profile, click the LTPA/SSO tab, click Import from keyfile, specify the key file name and password, and click Apply.

    For more information about configuring LTPA on SafeLinx, see Lightweight third-party authentication support.
  3. Disable password verification for the LDAP-bind authentication profile. From the properties pages of the LDAP-bind authentication profile, click the LDAP tab, and then select Disable password verification.
  4. Create an HTTP access service and configure it to use the LDAP-bind authentication profile that you configured in the previous steps.
  5. Use the GSKit to create a CMS key database (KDB) file. For more information, see Managing certificates for HCL SafeLinx.

    The key database must include the server certificate for the HTTP access service and the root signer certificates for remote client certificates. If there is an SSL connection between the SafeLinx Server and the DSS, you must also install the root signer certificate for the directory server certificate. During the SSL handshake, the server notifies clients about the root signer CAs that it includes so that clients can provide a list of installed certificates. Typically you would restrict the signing certificates on the server to those CAs that you want clients to use, such as the signers for an internal or private CA.

  6. From the properties pages for the HTTP access service, click the Service tab, and specify values for File name of key database and File name of stash password. Use the values for the key database file that you used in Step 5.
  7. Select Use secure connection and then click Server session with client certificate validation to force applications to present a user or device certificate.
  8. In the Credential challenge type section, click Extract from client certificate and then select one of the following values in the X.509 attribute field:
    • CN
    • EMAIL
    • RFC822 NAME

    The attribute that you select must store a value that matches the value of a similar attribute in the LDAP user record.

    For example, the EMAIL attribute in an X.509 certificate stores the user's email address in the format johndoe@renovations.com. If your LDAP implementation includes an attribute that stores email addresses in the same format, then select EMAIL in this step. Then, in Step 9, specify the analogous LDAP attribute.

    When a user presents an X.509 certificate, the HTTP access service extracts the value of the preceding attribute step from the client certificate. The service then searches the LDAP directory for the attribute value to locate the user record and verify that the user is valid.

    After the user record is located, the service retrieves the Distinguished Name (DN) attribute from the record and caches it in the SafeLinx user record. By default, the SafeLinx Server also uses the DN to generate an LTPA/SSO token for the user. A different value can be used to generate the token. LTPA/SSO tokens are generated from whatever value is selected in the LTPA token user identification field on the LTPA/SSO tab of the LDAP-bind authentication profile.

  9. Specify the LDAP attribute that contains the same value as the certificate attribute that you specified in Step 8.
    1. Return to the properties pages for the LDAP-bind authentication profile and click the LDAP tab.
    2. In the User key field, type the name of the LDAP attribute that contains the same value as the certificate attribute you specified in the X.509 attribute field in Step 8.
    For example, if you specified EMAIL as the certificate attribute, you might enter mail if you use an IBM Domino LDAP directory. If you use Microsoft™ Active Directory as your LDAP directory, you might enter userPrincipalName.
    Different LDAP implementations include attributes of different names to store the same information as the certificate attribute. What's important is that the values of the two attributes match, otherwise authentication fails.