What is LDAP (Lightweight Directory Access Protocol)?
Lightweight Directory Access Protocol (LDAP) is an Internet protocol for clients to access directory services that follow X.500 data and service models. It represents directory data as hierarchical entries that use distinguished names and typed attributes. It defines operations such as bind, search, compare, add, modify, and delete. LDAP is not a directory product, an identity provider, or an authorization model.
Why it matters
LDAP gives different clients and directory servers a standard way to find and manage identity and resource data. Many identity systems use a directory as one data source even when applications use a separate federation protocol for sign-in.
How it works
- The client connects to the directory service, establishes TLS or another required security layer, and uses Bind to set the LDAP session authentication state.
- The client sends a search, compare, add, modify, delete, or other LDAP operation with distinguished names, filters, and attributes.
- The server applies its access controls, performs the permitted operation, and returns a result or error for the request.
Example
An identity service searches an LDAP directory for a user's current group entries, then maps those groups into claims for a separate OIDC sign-in flow.
Pomerium boundary
Pomerium's documented custom identity-provider integration uses OAuth 2.0 and OpenID Connect. An organization that keeps identities in LDAP can use an OIDC-compatible IdP that reads that directory and supplies verified claims to Pomerium. Pomerium Enterprise can also synchronize directory data from its listed supported identity providers for policy use.
Limits and non-claims
- LDAP is a directory access protocol and does not define a complete IAM lifecycle or federated application sign-in flow.
- Simple credentials and directory data need a protected channel and suitable authentication because LDAP does not make every connection confidential by default.
- An attribute in a directory is not an authorization decision; the directory server and consuming application still need correct access policy and current data.
Evaluation checklist
- Which bind identity, TLS policy, search base, attributes, and directory access controls apply?
- Does the application separate directory authentication from its own resource authorization?
- Can anonymous bind, filter injection, stale replication, broad search, or clear transport expose data?
