LDAP Bind Response Extension for Returning DN and Attributes

Introduction In current LDAP practice, a client must perform at least two operations to authenticate and retrieve the DN of the subject:

Bind Request: The client authenticates using a DN and credentials.
Search Request: The client issues a search query to retrieve the DN and attributes of the authenticated subject.

This two-step process introduces unnecessary latency and complexity. By allowing the Bind response itself to return the DN and optionally attributes, the number of calls is reduced, improving efficiency for applications that need immediate access to identity information.

Motivation Many modern applications, including single sign-on (SSO) systems and microservices, require immediate access to user identity attributes after authentication. The current LDAP model requires a follow-up search operation, which adds latency and complexity. This extension simplifies client logic and reduces round trips.

Specification

Bind Request Control This document defines a new optional LDAP control for the Bind request:

Control OID: 1.3.6.1.4.1.xxx.yyy.zzz (to be assigned)
Criticality: OPTIONAL
Control Value: An ASN.1-encoded sequence of attribute descriptions requested by the client. If the sequence is empty or absent, the server SHALL return only the DN.

Bind Response Augmentation If the server supports this extension and the Bind operation succeeds, the Bind response SHALL include an attached response control carrying:

The Distinguished Name (DN) of the authenticated (authorization) identity.
The requested attributes, subject to applicable access control and privacy policies.
Attributes not permitted by policy SHALL be omitted; the server MAY include per-attribute error indicators within the control value.

If the Bind fails, the server SHALL NOT include this response control.

Control Value and Encoding The request and response control values are defined using ASN.1: Where AttributeDescription, LDAPDN, and PartialAttribute are as defined in RFC 4511. Servers SHOULD preserve attribute ordering requested by the client where feasible.

Examples

Current Workflow (RFC 4511 behavior) Bind Response (success) Search Request ----------------> Search Response (dn + attributes) ]]>

Proposed Workflow (with this extension) Bind Response (dn + attributes) ]]>

Attribute Selection Example Request control value: ["givenName", "mail"] Bind Response control value:

authzDN: uid=jdoe,ou=People,dc=example,dc=com: attributes: givenName: John mail: jdoe@example.com

Advantages

Reduced number of calls: Authentication and identity retrieval in a single step.
Lower latency: Fewer round trips between client and server.
Simplified client logic: No need for a follow-up search.
Clearer authorization identity handling: DN returned alongside selected attributes.

Security Considerations

Access Control: Servers MUST enforce authorization and access control policies prior to returning any attribute in the Bind response control.
Sensitive Data: Sensitive attributes (e.g., userPassword, secrets, tokens) MUST NOT be returned.
Privacy: Servers SHOULD minimize data returned by default and honor least privilege.
Integrity and Confidentiality: Use of StartTLS or LDAPS is RECOMMENDED to protect Bind credentials and returned attributes.
Auditing: Servers SHOULD log the use of this control, subject to privacy law and organizational policy.
Downgrade/Capability: Clients MUST NOT assume support; they SHOULD fall back to a search when the server does not advertise or honor the control.

IANA Considerations IANA is requested to assign a new LDAP control OID under the appropriate IANA registry. The descriptive name is: LDAP Bind Response Extension for Returning DN and Attributes The control is suitable for Standards Track registration.

Relationship to Existing RFCs This document defines an LDAP control that extends the Bind operation specified in RFC 4511 (“Lightweight Directory Access Protocol (LDAP): The Protocol”). RFC 4511 defines the Bind request and response as an authentication mechanism, with the Bind response limited to success or failure indicators. It does not provide a mechanism for returning the Distinguished Name (DN) or attributes of the authenticated subject. The closest related work is RFC 3829 (“Lightweight Directory Access Protocol (LDAP) Authorization Identity Request and Response Controls”), which introduces a control allowing a client to request the authorization identity established by the Bind. RFC 3829 enables a client to confirm the identity string (such as a DN or other identifier) but does not return arbitrary attributes of the subject entry. This document differs from RFC 3829 in that it allows the Bind response to return not only the DN but also selected attributes of the authenticated subject, subject to access control policies. Thus, this proposal complements RFC 3829 by extending the Bind operation to cover attribute retrieval, reducing the need for a subsequent search operation.

Conclusion This document proposes an LDAP Bind extension that returns the DN and optionally attributes of the authenticated subject. By collapsing authentication and identity retrieval into a single operation, the protocol reduces overhead and improves efficiency for client applications.