Standard SASL mechanisms

The PLAIN mechanism is a password-based authentication mechanism that is described in RFC 4616 and is similar to Lightweight Directory Access Protocol (LDAP) simple authentication. However, it provides two advantages that simple authentication doesn’t:

If you want to authenticate by a username, then you should prefix that username with “u:” such as u:jdoe for a username of jdoe. The server uses an identity mapper to identify the entry that corresponds to that username. If you want to authenticate with a DN, then you should prefix the DN with dn:, such as dn:uid=jdoe, ou=People, dc=example, dc=com.

As when using LDAP simple authentication, the PLAIN mechanism provides the password to the server in the clear. It should therefore only be used over a secure connection.

CRAM-MD5 and DIGEST-MD5 are password-based authentication mechanisms that allow the client to identify themselves with either a username prefixed by u: or a DN prefixed by dn:.

The primary benefit that these mechanisms offer over the PLAIN mechanism is that they do not send the password to the server in the clear. Instead, they send an MD5 digest that combines the username, password, and some randomly generated data. The DIGEST-MD5 mechanism optionally also allows you to specify a realm and an alternate authorization identity.

While this might initially seem like an improvement over the PLAIN mechanism, there are two key reasons that these mechanisms are discouraged:

Because of these security concerns, both of these mechanisms have officially declared historic through draft-ietf-sasl-crammd5-to-historic for CRAM-MD5 and RFC 6331 for DIGEST-MD5) and should no longer be used. Although the PingDirectory server supports them, we strongly discourage their use.

The EXTERNAL SASL mechanism described in RFC 4422 authenticates a client based on information that is available for that client outside of information transmitted over LDAP. To do this, the PingDirectory server uses a certificate chain that the client presents to the server during TLS negotiation. The server uses a certificate mapper to identify the user that is authenticating. It can optionally also require the public portion of the certificate to be present in the user’s entry.

Because the EXTERNAL mechanism in the PingDirectory server can only occur over a TLS-encrypted connection, it is a secure mechanism. Although it only uses a single authentication factor, as long as the server is configured with an appropriate trust manager to properly validate the client certificate chain, it is a much stronger form of authentication than a password.

The GSSAPI SASL mechanism described in RFC 4752 allows clients to authenticate with a Kerberos KDC. The credentials, typically either a password or a key read from a keytab file, are validated by the KDC and are not exposed to the PingDirectory server. The PingDirectory server does need to have an account for the user (and an identity mapper is used to map the Kerberos principal to an entry in the server), but that account does not need to include a password if you are only going to authenticate with GSSAPI.

The Kerberos authentication process protects the credentials in transit so that they are not exposed to network observers. Further, it provides an option to protect communication on the connection that occurs after authentication with either integrity protection that digitally signs the communication to protect it from being altered in transit but does not prevent it from being observed, or confidentiality protection, that encrypts the communication so that it cannot be observed or altered. Alternatively, GSSAPI authentication can occur over a TLS-encrypted connection to protect all communication on that connection.

See the config/sample-dsconfig-scripts/enable-gssapi-authentication.dsconfig batch file for more information about configuring GSSAPI authentication in the PingDirectory server.

The OAUTHBEARER SASL mechanism described in RFC 7628 allows a client to authenticate using an OAuth 2.0 bearer token. The access token can be obtained from an OAuth authorization server, which can authenticate the client through a variety of means, such as a username and password, a two-factor mechanism that combines a static password with a one-time password, or a FIDO hardware token. The PingDirectory server uses an access token validator to ensure that the token is authentic and to map it to an entry in the server.

The token can also be associated with one or more OAuth scopes. These are associated with the user’s authentication state and can be used in conjunction with the oauthscope access control bind rule to grant or deny access control rights to the user.

As its name implies, the ANONYMOUS mechanism described in RFC 4505 only performs anonymous authentication. That is, it does not identify any account, and it does not provide any proof of identity.

The bind request can include an optional trace string in the SASL credentials, which can provide additional information about the context for the bind (for example, the application that is associated with the connection), but this should be taken with a grain of salt because without any proof of identity, there is nothing to prevent the client from lying about what it includes in the trace string.

The PingDirectory server supports the ANONYMOUS SASL mechanism although it is disabled by default because it provides very little benefit over anonymous simple authentication.