Ldap Laravel Package

Product Decisions This Supports

• Build vs. buy for directory integration. This package is the "buy" side of LDAP: it wraps PHP's native ldap extension behind a typed, object-oriented client (Adapter, Entry, Query, Collection) instead of raw ldap_* function calls scattered across the codebase. The decision it supports is "do we hand-roll bind/search/paginate logic, or adopt a maintained client and spend our engineering time on the product surface?" For most teams the latter wins because LDAP edge cases (paged results, referrals, TLS negotiation, attribute casing, binary attributes) are where custom implementations quietly accumulate bugs.
• Enterprise authentication roadmap. Enables the recurring enterprise ask — "can we log in with our Active Directory / corporate credentials?" — via bind-based authentication and group-to-role mapping. This is usually a sales-unblocking feature for mid-market and enterprise deals, not a core product differentiator. Treat it as a checkbox that closes deals and reduces churn in procurement reviews.
• SSO and identity federation positioning. Because the component supports SASL bind, TLS, and whoami, it can underpin an SSO story without forcing a full SAML/OIDC identity-provider migration. That gives the roadmap a cheap intermediate step: "LDAP/AD auth in Q3, OIDC in Q4–Q1" rather than one large, risky identity project.
• Multi-tenant / per-customer directory configuration. The Adapter is instantiable with arbitrary connection config, so a SaaS product can hold one directory configuration per tenant and construct a client per request. This directly supports the "each customer brings their own directory" enterprise tier.
• Compliance and audit surface. Centralized identity in the customer's directory means fewer local credentials to store, rotate, and audit. Supports SOC 2 / ISO 27001 narratives around access provisioning and deprovisioning — and means offboarding happens in the customer's IAM, not in your admin panel.
• Hybrid / on-prem-to-cloud bridging. For customers running on-prem AD who are moving workloads to your cloud product, LDAP bind is often the only network path their security team will approve before a full IdP rollout.
• Platform commitment signal. Symfony's release discipline (maintained parallel lines at 5.4, 6.4, 7.x, 8.x, with LTS branches and backported bugfixes) is the evidence that this dependency won't be orphaned mid-contract. That matters when the feature is contractual.

When to Consider This Package

Adopt when:

• A paying customer or a defined segment requires AD/OpenLDAP credential authentication, and you are on a PHP/Laravel stack with Composer already in place.
• You want a low-level, unopinionated client and intend to own the Laravel-side integration yourself: a custom UserProvider, a guard, a group-to-role mapping layer, connection caching. This package gives you the protocol work and deliberately stays out of your domain model.
• You need SASL bind, TLS/StartTLS, paged searches, or whoami — those are the features that separate this from a 40-line ldap_bind wrapper.
• You are already in the Symfony ecosystem (or use Symfony components elsewhere) and want one consistent HTTP-less client style.
• Your infrastructure can guarantee the php-ldap extension is compiled in — i.e., you control the container image or have confirmed it with your host. This is a hard dependency and a real adoption blocker on shared hosting and some managed PHP platforms.
• You need a long support runway: pick an LTS line (6.4 or 7.4) deliberately rather than latest-major, and pin it.

Look elsewhere when:

• You want batteries-included Laravel AD authentication — user provider, group sync, model mapping, password sync, testing fakes out of the box. Wrapping this package means writing and maintaining that layer yourself; a Laravel-native directory package (e.g. LdapRecord) carries that cost for you. Choose this package only if you want that layer to be yours.
• Your identity requirement is really OIDC/SAML/SCIM rather than LDAP. Don't let LDAP stand in for a modern IdP migration; it's a bridge, not a destination.
• You need directory write-back, provisioning automation, or sync at scale — that's SCIM territory, and a read/bind-focused client will strain.
• php-ldap cannot be installed. Non-negotiable.
• You need real-time directory event streams. This is a client; there is no change-notification story here.
• Your security review forbids binding with a service account for searches, or your customer's directory is behind a network path you can't reach from your runtime.

Risk notes the PM should carry forward, honestly:

• The 135 stars / 0 listed dependents figures are artifacts of this being a read-only subtree split of symfony/symfony, not a signal of low adoption. Judge maturity by the release train, backport cadence, and the fact that Symfony Security's LDAP providers are built on it. Do not present star count to stakeholders as a quality metric either way.
• Issues and PRs live in the main symfony/symfony monorepo, not this repository. Route support expectations accordingly; your team files against Symfony, and fixes ship on Symfony's schedule, not yours.
• Major-version migrations include behavior changes, not just deprecations — e.g. AbstractQuery::sizeLimit was removed in 8.0, and Symfony 8 requires PHP ≥ 8.4. Budget for a pinning and upgrade policy up front.
• You own everything above the protocol: error UX when the directory is unreachable, timeouts, retry behavior, credential caching, and the fallback path when a customer's LDAP is down at login time. That's the majority of the actual work.

How to Pitch It (Stakeholders)

For executives — one paragraph:

Corporate buyers keep asking for Active Directory login, and today we either say no or build it from scratch each time. This package lets us connect to a customer's existing directory using a maintained Symfony component rather than custom protocol code — the same one Symfony's own security layer relies on. It's MIT-licensed, has shipped continuously across four maintained release lines with backported bugfixes, and carries no licensing cost. The trade-off is honest: it's an LDAP client, so our team still builds the Laravel-side login, user mapping, and group-to-role layer. Expect that as the bulk of the effort — but it's work we own and can reuse for every subsequent enterprise customer, versus per-deal custom integration. This is a sales-unblocking capability with a modest, bounded build cost, not a platform bet.

For engineering — the framing they'll want:

• Adopt as a protocol-layer dependency, not a feature. It replaces raw ldap_* calls and gives you typed Adapter/Entry/Query objects, paged queries, SASL bind, TLS, and whoami.
• It has no Laravel integration. We own: a UserProvider and guard, group→role mapping, per-tenant adapter construction, connection/serialization lifecycle (note the resettable-adapter support added in recent patches), and error handling for directory unavailability.
• Hard dependency on the php-ldap extension — verify in our base image first; this is step zero.
• Pin to an LTS line (6.4 or 7.4) rather than tracking latest-major; 8.x requires PHP ≥ 8.4 and dropped sizeLimit, and majors have historically carried breaking changes.
• Test strategy matters more than usual: no live directory in CI. Plan for a fake/stub at the adapter boundary plus one integration environment against a containerized OpenLDAP.
• Upstream is the symfony/symfony monorepo — file issues there, and don't expect a fast lane for our specific needs.