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.
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 IBM® 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 IBM® 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 IBM® Domino® LDAP directory, you would specify mail in the User key field.