Third-party authentication using LDAP-bind
You can configure an authentication profile to use an LDAP-bind authentication for HTTP access services or connection profiles.
HTTP access services examine the HTTP headers for a user ID and password on each request. If the user ID and password are available in the request, then the user is not challenged. Otherwise, when a client sends a request, the SafeLinx Server challenges the request and waits for the client to return its user ID and password. These credentials are used to complete the LDAP-bind.
For SafeLinx Clients, you might configure a connection profile to use LDAP-bind as a secondary authentication method. In this case, if the primary authentication occurs through a password-based key exchange algorithm, by default, a user who starts the SafeLinx Client is presented with two Connect windows. After the user submits credentials to the SafeLinx Server from the first window, a second window prompts the user to authenticate with the LDAP server. The SafeLinx Client displays the redundant authentication prompt even if the credentials that are used to authenticate with the SafeLinx Server and the LDAP server are the same.
Depending on your security requirements, users can save the Connect window values across sessions, thus presenting users with only the LDAP login window. If the credentials that are used to authenticate with the LDAP server and the SafeLinx Server are identical, you can suppress the display of the redundant Connect window. To suppress the second window, configure the LDAP authentication profile not to challenge for an ID and password. Then, the credentials that a user submits in the first Connect window are also used to authenticate with the LDAP server.
After the challenge is validated, this authentication profile completes a directory server service (DSS) lookup by using a configurable key field. After the DSS completes an LDAP-bind operation to associate the key field with a base distinguished name, the client is authenticated.
- A descriptive name
- IP address and port number of the directory service servers
- Maximum idle time that specifies how long to keep the DSS connected
- User key field, such as uid or mail, to determine which field is searched in the directory tree
- Base distinguished name (base DN) that is the root or suffix of the directory tree where the search for client authentication resources begins.
- Optionally, you can secure the connection between the DSS and the SafeLinx Server by using secure sockets layer (SSL).