Certificate authentication for SafeLinx Clients

For mobile access services, you can configure a connection profile to use a certificate-based authentication profile. When a SafeLinx Client user attempts to log in through a connection that is governed by a certificate-based authentication profile, the SafeLinx Server requests an X.509 certificate. Only Rivest-Shamir-Adleman (RSA) certificates are supported.

The SafeLinx Server always verifies the digital signature on the certificates that it receives, and you can configure the authentication profile to verify other information, as well. If verification of any configured information fails, the client receives an error message, and the user cannot log in. A certificate-based authentication profile can verify the following certificate information:
Validity period
All certificates have an issue date and expiration date. SafeLinx Server verifies that the current system time is within the valid range. All times are compared in the GMT time zone.
Certificate issuer and revocation status
You can verify the trust relationship with the user through the certificate authority (CA) certificates that are stored in a key database. You can also check the revocation status of certificates against certificate revocation lists (CRLs). Set up a process for delivering CRLs from their CA to the SafeLinx Server on a periodic basis.
Note: The removeFromCRL reason code in the delta CRL entry extensions is not supported. To remove a certificate from a CRL, issue a new base and delta CRL that do not contain the unrevoked certificate.
Subject attributes

The certificate that is passed from the SafeLinx Client to the SafeLinx Server during authentication contains attributes in its subject key. You can verify that the subject key attributes match attributes in the user records in the local SafeLinx Server user database or on a directory server in your enterprise. The login is processed only after the attributes are validated.

Specify the option Verify user account attributes if you want the SafeLinx Server to query the local SafeLinx Server user database for attributes that it extracts from the certificate subject key. If you choose this option, you can specify the attributes to compare.

Specify the option Verify using directory server if you want the SafeLinx Server to query an external LDAP server for the DN from the certificate subject key.

If you use an external directory for validation, you can specify a text string to use in the LDAP search filter. This filter string locates a user DN from the subject attribute in the certificate. The subject attribute is substituted into this filter string wherever %s occurs. For more information about the format for LDAP search filters, see RFC 2254, The String Representation of LDAP Search Filters.

You can also configure the certificate-based authentication profiles to check whether the user record that matches the subject key is a member of an allowed group. Users who do not belong to one of the allowed groups are unable to authenticate. To validate group membership, you must provide the following information:

Allowed groups
A semicolon-delimited list of allowed group distinguished names (DN). When the user record is a member of one or more of the groups that are specified, then authentication passes.
Membership attribute
A semicolon-delimited list of search attributes. The attributes you specify depend on the value you select for Group membership evaluation mode.
Group membership evaluation mode
Specifies how the SafeLinx Server determines if a user is a member of a group. You can choose one of the following options:
  • Group to user

    Select this option to search the allowed groups to determine whether they contain the specific user as a member.

  • User to group

    Select this option to search the user attributes to determine whether the user is a member of the allowed groups. The search attribute is directly retrieved from the subject distinguished name (DN).

    If you use the User to group option, you can also specify whether a recursive search is completed. Recursive searches check whether users belong to groups that are contained within other groups. Through a recursive search, the SafeLinx Server can determine all the groups that the user belongs to, including the parents of nested groups.

    Some LDAP implementations search recursively by default. For example, Microsoft Active Directory server supports User to group search capability through the memberOf attribute. However, this attribute lists the groups that a parent group contains only. It does not provide the recursive list of nested predecessors. If you use the User to group evaluation option, be sure to select Search nested groups if your server implementation does not support implicit recursive search.

Examples:
  • If you use Microsoft Active Directory DSS with a flat group structure, you might use the following settings to determine if users belong to an allowed group:
    Allowed groups
    cn=SafeLinx Server Users,dc=hcl,dc=com
    Membership attribute
    memberOf
    Group membership evaluation mode
    User to group
    Search nested group
    Disabled

    For a certificate subject key with the DN cn=Cathy Johnson,cn=Users,dc=hcl,dc=com the preceding settings would produce a single search with the following characteristics:

    Base:
    cn=Cathy Johnson,cn=Users,dc=hcl,dc=com
    Scope:
    One level
    Attributes to retrieve:
    memberOf

    The search results might be: (cn=Development,dc=hcl,dc=com, cn=SafeLinx Server Users,dc=hcl,dc=com).

    The allowed group DN is in this list, therefore authentication proceeds.

  • If you use an OpenLDAP directory, you might use the following settings to search the allowed groups to determine if a specific user is a member:
    Allowed groups
    cn=SafeLinx Server Users,dc=hcl,dc=com
    Membership attribute
    uniqueMember
    Group membership evaluation mode
    Group to user

    For a certificate subject key with the DN uid=cathy,dc=hcl,dc=com the preceding settings would produce a single search with the following characteristics:

    Base:
    dc=hcl,dc=com (from directory server definition object)
    Filter:
    (uniqueMember=uid=cathy,dc=hcl,dc=com)
    Scope:
    subtree
    Attributes to retrieve:
    dn

    The search results might be: cn=SafeLinx Server Users,dc=hcl,dc=com. This result matches one of the allowed groups, therefore, authentication proceeds.

If a connection profile requires primary authentication through password-based key exchange, and secondary authentication through X.509 client certificates, the SafeLinx Client displays two connect windows. One window prompts for the SafeLinx Server system authentication, and the other prompts for the certificate. After SafeLinx Client users log in using the Connect window, they must enter the certificate and password in the second window. In environments where security policies allow users to save credentials between sessions, users might be prompted for the certificate only, or receive no authentication prompt.