Proprietary SASL mechanisms

The UNBOUNDID-CERTIFICATE-PLUS-PASSWORD mechanism is similar to the EXTERNAL mechanism in that it allows a client to authenticate with a certificate presented during TLS negotiation. However, it adds a second authentication factor in the form of a static password. This makes it a two-factor mechanism that adds an additional layer of protection in the event that the user’s client certificate is compromised or if an attacker is somehow able to get a trusted certificate that maps to the user entry.

The UNBOUNDID-DELIVERED-OTP mechanism allows a user to authenticate with the combination of a static password and a one-time password (OTP) that is generated by the server and delivered to the user through some out-of-band mechanism. The PingDirectory server provides out-of-the-box support for delivering the one-time password through an SMS, through the Twilio service, text message, or in an email message, but you can create custom OTP delivery mechanisms using the UnboundID Server SDK.

When using the UNBOUNDID-DELIVERED-OTP mechanism, the client first uses the deliver one-time password extended request, which sends a username and static password to the server as preliminary proof of identity. The server then generates a one-time password and deliver it to the user through an appropriate means. Finally, the client includes the authentication ID, the delivered one-time password, and an optional authorization identity in an UNBOUNDID-DELIVERED-OTP bind request to complete the authentication process.

The one-time password that the server generates is only valid for a limited period of time, five minutes by default. After they are generated, these one-time passwords are stored in the user’s entry. The “Encrypt TOTP Secrets and Delivered Tokens” plugin can be used to ensure that these values are encrypted when stored in the server.

See the config/sample-dsconfig-batch-files/enable-delivered-otp-authentication.dsconfig batch file for more information about configuring the UNBOUNDID-DELIVERED-OTP SASL mechanism.

The UNBOUNDID-EXTERNALLY-PROCESSED-AUTHENTICATION mechanism is unusual in that it doesn’t actually change the authentication state of the underlying client connection. The connection must already be authenticated as a user that has either the permit-externally-processed-authentication privilege or the proxied-auth privilege, and it remains authenticated as that user regardless of the outcome of the UNBOUNDID-EXTERNALLY-PROCESSED-AUTHENTICATION bind attempt.

The real benefit of the UNBOUNDID-EXTERNALLY-PROCESSED-AUTHENTICATION mechanism is that it allows an application to authenticate a user through some external means, but still verify that authentication in the PingDirectory server. It can ensure that the user’s account is in a usable state, such as not disabled or locked, and it can also update the user’s password policy state to do things like update the user’s login history and increment the set of failed attempts and possibly lock the account in the event that the external authentication attempt failed.

The UNBOUNDID-TOTP mechanism is a two-factor authentication scheme that allows a user to identify themselves with a username or DN and verify that identity with both a static password and a time-based one-time password generated using the TOTP algorithm described in RFC 6238. The bind request can optionally include an alternate authorization identity.

Time-based one-time passwords are generated using a variety of free software, including phone apps like Google Authenticator and Authy as well as desktop software. The software used to generate TOTP passwords depends only on the current time and a secret key that is shared between the client and the server. There is no need to communicate with any other system, so it’s an especially good choice for administrative accounts because it allows them to use strong authentication that work even if the server is unable to communicate with other systems. TOTP authentication does require that the client and server both agree on what time it is, but it does allow for some leeway. By default, the server allows the TOTP generator’s clock to be at least a minute head of or a minute behind the server’s clock.

The client and server need to be using the same shared secret to generate the time-based one-time passwords. The “generate TOTP shared secret” extended operation can be used to generate a suitable secret value, store it in the user’s entry, and return it to the client to allow them to configure it for use with their authenticator app. The “revoke TOTP shared secret” extended operation can be used to revoke a secret if it is no longer needed or if you are concerned that it might have been compromised.

In some cases, the client might want to verify a time-based one-time password without using the UNBOUNDID-TOTP SALS mechanism. For example, the client can implement its own kind of “step up” authentication in which a simple password might be sufficient for some operations but additional proof of identity might be required when performing other operations. To help with this, the server offers a “validate TOTP password” extended operation that allows the client to provide the user’s DN and TOTP password to verify for that user.

The shared secret that the server uses to generate TOTP shared secrets needs to be stored in a reversible form so that the server can use it to verify the values that the client provides. The server can also store the last TOTP password that the client used to prevent it from being used more than once. The “Encrypt TOTP Secrets and Delivered Tokens” plugin can be used to ensure that these values are encrypted when stored in the server.

The UNBOUNDID-YUBIKEY-OTP mechanism is a two-factor authentication scheme that allows a user to identify themselves with a username or DN and verify their identity with the combination of a static password and a one-time password generated by a YubiKey device offered by Yubico.

The one-time password that is generated can be sent to the public validation servers that Yubico maintains or you can run your own local authentication servers. Although running your own servers requires additional effort, it eliminates a dependency on a third-party service and also allows you to use YubiKey devices that have been updated to use a different private key than was initially assigned to them.

The “register YubiKey OTP device” extended operation can be used to register a device with the server and associate it with a user account. The server also offers a corresponding “deregister Yubikey OTP device” extended operation that can remove information about the device from the user’s entry.

See the config/sample-dsconfig-batch-files/enable-yubikey-otp-authentication.dsconfig batch file for more information on this SASL mechanism.