Certificate-only authentication for HTTP access services

With HCL SafeLinx, you can enable certificate-only authentication for the HTTP access service. Under certificate-only authentication, the HTTP access service verifies a user's identity automatically by validating the client's X.509 certificate against the keystore. Users are not required to supply passwords.

Typically, administrators configure the HTTP access service to require clients to provide a user name and password to authenticate. However, user name and password authentication is potentially vulnerable due to lost, stolen, or otherwise compromised passwords. To reduce the risk of compromised credentials, you can require clients to authenticate by using a digital certificate. After you enable certificate authentication, you can disable password authentication. For information about disabling password authentication, see Configuring certificate-only authentication for HTTP access.
Note: Although you can disable user name and password authentication for SafeLinx, applications might still require users to enter credentials.

Under certificate-only authentication, the HTTP access service verifies a user's identity automatically by validating the client's X.509 certificate against the keystore. The certificate can be either a user certificate or a device certificate. If the HTTP access service cannot validate the certificate against the keystore, access is denied. If the certificate validation is successful, the HTTP service extracts the value of an attribute, such as the common name (CN) from the certificate subject. It then searches the LDAP directory for the attribute value to locate the corresponding user record. The service then retrieves the distinguished name (DN) from the user record and uses it to generate an LTPA or LTPA2 token for single sign-on. The service can also retrieve information from the user record about a user's group membership.

For example, suppose that the HTTP access service is configured to extract the EMAIL attribute from the certificate. When John Doe attempts to log in from the HCL Connections mobile application, the mobile application is challenged to present John's user certificate. If the certificate is valid, the service extracts the value of the emailAddress attribute from the certificate subject and then searches the LDAP directory for that value. So for a certificate that includes the attribute emailAddress=johndoe@renovations.com, the LDAP search might find a user record for DN: cn=John Doe,dc=renovations,dc=com.

The HTTP access service then generates an LTPA token that is based on John's credentials for use in single sign-on. If you configure single sign-on (SSO) between SafeLinx and another application, the token is included in requests to that application during the current session.

For example, if you configure SSO between SafeLinx and HCL Connections, after a Connections Mobile user authenticates with SafeLinx, the resulting LTPA token authorizes access to Connections.

Because each LDAP implementation uses different attributes to store the same information, you must ensure that the certificate attribute maps to a valid LDAP attribute. Authentication fails if the LDAP directory cannot return a value for the attribute that it extracts from the certificate. You specify the mapping in the User key field in the LDAP authentication profile. For example, if you specified EMAIL as the certificate attribute, and you use an HCL Domino® LDAP directory, you would specify mail in the User key field.