Ping Identity Data Governance Server Configuration Reference

SASL Authentication Options

Command-line tools that perform LDAP communication provide the ability to use either simple or SASL authentication. Simple authentication, in which the client specifies the DN and password for the user as whom to bind, is the most common type of authentication but may not be ideal in all situations. SASL (the Simple Authentication and Security Layer, as defined in RFC 4422) provides an extensible framework that clients may use to identify themselves to the server and potentially provide additional information about the interaction between the client and server.

Because SASL is an extensible framework, there are multiple mechanisms that may be used to authenticate which work in different ways and with varying levels of security. In order to specify the SASL mechanism to use when authenticating, the 'mech' SASL option must always be provided with a value equal to the name of the desired SASL mechanism. The set of additional options available for use varies based on the mechanism that has been selected. The supported SASL mechanisms and options available for use with them are provided below.

The ANONYMOUS SASL Mechanism

The ANONYMOUS mechanism does not actually perform any authentication, and therefore clients that use it should generally be treated in the same way as clients which have not performed any kind of authentication. However, it does allow clients to provide a trace string, which can be used to help identify the purpose of the associated connection or the application that is using it.

The SASL options available for use with the ANONYMOUS mechanism include:

• trace
  Text string that may be written to the Data Governance Server error log as trace information for the bind.
  
  

The CRAM-MD5 SASL Mechanism

The CRAM-MD5 mechanism provides a way to perform password-based authentication in a manner that protects the password so that it is not transmitted over the network in the clear, even if the client is not using a secure connection (although it requires that the server be able to determine the clear-text representation of the user's password).

The SASL options available for use with the CRAM-MD5 mechanism include:

• authid
  Authentication ID for the bind.
  
  

The DIGEST-MD5 SASL Mechanism

The DIGEST-MD5 mechanism provides a way to perform password-based authentication in a manner that protects the password so that it is not transmitted over the network in the clear, even if the client is not using a secure connection (although it requires that the server be able to determine the clear-text representation of the user's password). The DIGEST-MD5 mechanism operates in a manner that is similar to the CRAM-MD5 mechanism, except that DIGEST-MD5 is more secure and offers the ability to request an alternate authorization identity.

The SASL options available for use with the DIGEST-MD5 mechanism include:

• authid
  Authentication ID for the bind.
  
  
• realm
  Realm into which the authentication is to be performed.
  
  
• qop
  Quality of protection to use for the bind.
  
  
• digest-uri
  Digest URI to use for the bind.
  
  
• authzid
  Authorization ID to use for the bind.
  
  

The EXTERNAL SASL Mechanism

The EXTERNAL mechanism allows the client to authenticate using credentials supplied outside of the LDAP protocol but are still available to the server. In most cases, these credentials are in the form of an X.509 certificate that the client provides to the server during the process of SSL or StartTLS negotiation.

The SASL options available for use with the EXTERNAL mechanism include:

The GSSAPI SASL Mechanism

The GSSAPI mechanism allows the client to authenticate using Kerberos V. If the client already has an existing Kerberos session, then no further credentials may need to be provided. Otherwise, a new session may be established and used to authenticate to the server.

The SASL options available for use with the GSSAPI mechanism include:

• authid
  Authentication ID for the bind.
  
  
• authzid
  Authorization ID to use for the bind.
  
  
• configfile
  Specifies the path to a JAAS config file that should be used for GSSAPI authentication. By default a JAAS config file will be automatically generated.
  
  
• debug
  Indicates whether to enable debugging for GSSAPI authentication processing.
  
  
• kdc
  KDC to use for the Kerberos authentication.
  
  
• protocol
  The name of the protocol to use in the GSSAPI service principal. If this is not specified, then a default protocol of "ldap" will be used.
  
  
• realm
  Realm into which the authentication is to be performed.
  
  
• renewtgt
  Indicates whether to attempt to renew the user's ticket-granting ticket if GSSAPI authentication uses an existing Kerberos session. By default, no attempt will be made to renew the TGT.
  
  
• requirecache
  Indicates whether to require an existing Kerberos session obtained from a ticket cache rather than using supplied authentication credentials. By default, if no existing session is available, then the supplied credentials will be used to create a new session.
  
  
• ticketcache
  Specifies the path to an alternate Kerberos ticket cache to use for GSSAPI authentication. If this is not provided, then the default ticket cache location will be used.
  
  
• useticketcache
  Indicates whether to attempt to use a ticket cache to leverage an existing Kerberos session if the client has already authenticated with the KDC. By default, a ticket cache will be used if it is available.
  
  

The PLAIN SASL Mechanism

The PLAIN mechanism allows the client to authenticate using an identifier and password. It is similar to simple authentication, except that it is possible to identify the target user with either a username or DN, and it is also possible to request an alternate authorization identity.

The SASL options available for use with the PLAIN mechanism include:

• authid
  Authentication ID for the bind.
  
  
• authzid
  Authorization ID to use for the bind.
  
  

The UNBOUNDID-DELIVERED-OTP SASL Mechanism

The UNBOUNDID-DELIVERED-OTP mechanism allows the client to perform multifactor authentication by combining a static password with a one-time password delivered to the user through some out-of-band mechanism.

The SASL options available for use with the UNBOUNDID-DELIVERED-OTP mechanism include:

• authid
  Authentication ID for the bind.
  
  
• authzid
  Authorization ID to use for the bind.
  
  
• otp
  The one-time password.
  
  

The UNBOUNDID-TOTP SASL Mechanism

The UNBOUNDID-TOTP mechanism allows the client to perform multifactor authentication by combining a static password with a time-based one-time password.

The SASL options available for use with the UNBOUNDID-TOTP mechanism include:

• authid
  Authentication ID for the bind.
  
  
• authzid
  Authorization ID to use for the bind.
  
  
• totppassword
  The time-based one-time password.
  
  
• promptforstaticpassword
  Indicates that the tool should interactively prompt the user for a static password. The value should be either 'true' or 'false'.
  
  

The UNBOUNDID-YUBIKEY-OTP SASL Mechanism

The UNBOUNDID-YUBIKEY-OTP mechanism allows the client to perform multifactor authentication by combining a static password with a one-time password generated by a YubiKey device.

The SASL options available for use with the UNBOUNDID-YUBIKEY-OTP mechanism include:

• authid
  Authentication ID for the bind.
  
  
• authzid
  Authorization ID to use for the bind.
  
  
• otp
  The one-time password.
  
  
• promptforstaticpassword
  Indicates that the tool should interactively prompt the user for a static password. The value should be either 'true' or 'false'.