PingDirectory

Using alternate authorization identities

Under certain conditions, a client that is authenticated as one user can request that the server process operations under the authority of a different user.

The most common ways to accomplish this include:

  • The client can use the proxied authorization request control. The server supports two variants of this control:

    • A version that is described in draft-weltman-ldapv3-proxy-04, in which the target user is identified by a distinguished name (DN).

    • A version that is described in RFC 4370, in which the target user is identified by an authorization ID that can include either a username (prefixed by u:) or a DN (prefixed by dn:).

  • The client can include an intermediate client request control that contains a value in the clientIdentity field. This value should be an authorization ID that starts with either u: or dn:.

  • Some SASL mechanisms allow the user to request an alternate authorization identity that will automatically be used for all subsequent operations requested on that connection. This includes the DIGEST-MD5, GSSAPI, OAUTHBEARER, PLAIN, UNBOUNDID-DELIVERED-OTP, UNBOUNDID-TOTP, and UNBOUNDID-YUBIKEY-OTP mechanisms.

This is a very powerful mechanism, and it allows applications to efficiently support multiple concurrent users over a common set of pooled connections. These pooled connections can be authenticated with an account that is specific to that application, and then each time that application needs to perform an operation on behalf of one of its end users, it can include the proxied authorization or intermediate client control in the request.

However, there are also obvious security concerns associated with this ability. If any user could impersonate any other user, then access controls would be irrelevant. PingDirectory server offers several forms of protection to ensure that alternate authorization identities can be used safely. These include:

  • Only clients who have the proxied-auth privilege are permitted to use an alternate authorization identity. This privilege is not granted to any user by default (even root users).

  • The use of the proxied authorization and intermediate client controls can be restricted by access control.

  • Operational attributes in user entries can be used to restrict the use of alternate authorization identities. See Restricting access through operational attributes in user entries for more information about these operational attributes.

  • Only accounts with a usable password policy state can be used as alternate authorization identities. For example, if an account is administratively disabled, locked because of too many failed authentication attempts, has an expired password, or has any other state that would prevent them from authenticating to the server, then the server does not allow operations to be processed under the authority of that user.