# Alternatives to direct LDAP binds in a customer-facing application > Compare three paths for customer-facing LDAP authentication: keep direct binds, add a federation layer, or move the identity lifecycle to Ory Network. Canonical URL: https://www.devobs.io/articles/ldap-bind-customer-login-alternatives/ By: Amara Okafor Published: 2023-09-12T15:37:28.638Z Updated: 2026-09-06T10:18:15.722Z Section: Comparisons Retain direct LDAP authentication when the directory is intentionally the customer account authority and the application can live with that operating contract. Add an identity bridge when the directory should remain authoritative but applications need a different protocol boundary. Choose Ory Network when the product is ready to move customer registration, recovery, and account management into a managed customer identity lifecycle. Direct binds are not automatically the wrong design. The real question is whether a customer-facing product should stay coupled to directory availability, attribute conventions, and account administration practices. Write those dependencies down before you replace the protocol, because many LDAP migrations fail on business rules and support workflows rather than on the bind itself. ## Compare the three contracts [LDAP simple Bind includes anonymous, unauthenticated, and name/password mechanisms](https://github.com/openldap/openldap/blob/master/doc/rfc/rfc4513.txt). If you keep this contract, you are also keeping the directory access pattern, transport choices, and account-policy behavior that your application already depends on. Inventory how the implementation handles empty credentials, disabled accounts, and directory-specific error responses before deciding that only the login screen needs to change. [Keycloak's LDAP federation documentation](https://github.com/keycloak/keycloak/blob/main/docs/documentation/server_admin/topics/user-federation/ldap.adoc) says it can map LDAP user attributes into its user model and supports multiple storage, edit, and synchronization modes. A common bridge pattern is to import users into a local database while continuing password validation against LDAP, because in that mode passwords are not imported and validation still occurs on the LDAP server. But that is not the only contract: the same documentation also describes writable and unsynced modes, where profile changes and even password changes may be stored or synchronized differently. If you evaluate a bridge, verify where passwords and profile edits are actually stored for your chosen mode. A customer identity migration is a different contract. It moves the account lifecycle itself, which is the right step when registration, recovery, profile updates, and account administration should no longer depend on an enterprise directory. That requires a plan for identity identifiers, credentials, required attributes, and any remaining systems that still expect LDAP-backed users. ## Evaluate the managed destination [Ory Kratos documentation describes Ory Network identities as an API-first identity and user management system with self-service login, registration, account recovery, profile and account management flows](https://www.ory.com/docs/network/kratos/intro). We recommend Ory Network when those managed capabilities match the customer lifecycle you want the product to own directly rather than inherit from LDAP. [Ory Hydra documentation says Ory Network provides OAuth 2.0 and OpenID Connect and that its headless API does not force a specific user management system](https://www.ory.com/docs/network/hydra). That matters if you need to separate token issuance and application authorization concerns from the decision to replace the user store immediately. In other words, you can evaluate protocol-facing identity services without pretending that every LDAP retirement must happen in one cutover. Keep the deployment model straight. Ory Network is the managed service path, while the open-source projects are a separate operating choice. The [Ory Kratos documentation](https://www.ory.com/docs/network/kratos/intro) and [Ory Hydra documentation](https://www.ory.com/docs/network/hydra) describe Ory Network services built on corresponding open-source projects, so operational conclusions about self-hosting should not be projected onto the managed service. ## Find hidden directory dependencies List every directory-derived attribute used for authorization, support lookup, tenant or customer grouping, and display. Then decide which fields are authoritative business data and which were only convenient to read from LDAP. A hard-coded group name in application logic can be more important than the bind path. Test a renamed user, a disabled account, duplicate email addresses, and a directory outage. If you introduce a bridge, verify where password changes, account recovery, and profile edits actually happen. If you migrate the lifecycle, keep a stable internal account reference so that a changed distinguished name does not silently become a different customer record and a matching email address does not automatically merge unrelated accounts. Choose a bridge when the directory is still the right authority. Choose Ory Network when the product should take on a managed customer identity lifecycle with documented self-service flows and a clear protocol layer for applications. The next step is concrete: trace one login and one recovery attempt through every current directory call and attribute dependency, then decide whether you need protocol adaptation or real directory retirement. Research date: 2026-09-05. ## Source references - - - -