Product Decisions This Supports
- Enterprise authentication roadmap. LDAP/AD login is a recurring enterprise procurement gate. This bundle supports the decision of whether to offer directory-based sign-in for on-prem or regulated customers, and what the integration surface looks like (user provider bound to a directory, credentials validated against the directory rather than a local password table).
- Build vs. buy vs. borrow for auth. It represents the "borrow" option: an Apache-2.0 reference implementation that shows what a Symfony-native LDAP user provider costs in code. That is genuinely useful input to a build/buy comparison against a hosted IdP (Entra ID, Okta, Keycloak) or a maintained library.
- Framework-alignment check — flag this first. Despite the brief, this is a Symfony 6.4 bundle, not a Laravel package. If the product runs on Laravel, this package does not support any decision directly; it at best informs requirements for a Laravel equivalent (e.g., LdapRecord-Laravel) or argues for delegating to an OIDC/SAML IdP instead of speaking LDAP.
- Scope decisions on identity. Whether LDAP is the only directory protocol we support, or one connector behind an abstraction. A single-provider bundle nudges toward the former; that is a product decision worth making explicitly rather than inheriting.
- Not supported: pricing, packaging, or go-to-market decisions. With 2 stars, 0 dependents, and a 0.04 score, there is no adoption signal to justify treating this as an ecosystem bet.
When to Consider This Package
Consider it when:
- The stack is genuinely Symfony 6.4 and the requirement is narrow: authenticate users against a corporate AD/OpenLDAP directory and map directory entries to app users.
- The deployment is internal or single-tenant enterprise, where the directory is stable, the user population is known, and login is not a growth lever.
- You have Symfony engineers who can read and fork the bundle. At this maturity level, adoption means vendoring, not depending.
- You want a time-boxed spike to estimate the build cost of LDAP auth before committing to a hosted IdP.
Look elsewhere when:
- You are on Laravel. Hard incompatibility — Symfony bundle architecture (DI container config, security bundle wiring) does not port. Use a Laravel-native LDAP package or an IdP.
- You need SAML/OIDC, MFA, SCIM provisioning, or multi-tenant directory support. LDAP-only is the wrong abstraction for those; go to an IdP and treat LDAP as one upstream connector.
- You need a security response commitment. Zero dependents and minimal activity means no downstream triage, no CVE history to reason about, and a bus factor that is effectively one. Auth code is exactly where you cannot absorb that risk silently.
- You need group-to-role mapping, connection pooling, failover across domain controllers, or multi-directory routing. Expect to build these yourself; budget accordingly.
- A supported alternative exists in-stack. Symfony's own LDAP component plus the security bundle covers much of this without a third-party dependency.
Adoption preconditions if pursued: a named internal owner, a pinned commit or fork, a documented upgrade path off Symfony 6.4, and a tested fallback to local auth or an IdP if the bundle is abandoned.
How to Pitch It (Stakeholders)
To executives (one line): LDAP login is a checkbox enterprise buyers ask for; this package is a free, permissively licensed reference implementation that tells us what that checkbox costs — it is an input to the build/buy decision, not a dependency we would ship on.
The honest read: maturity is very low — 2 stars, no downstream dependents, and the package targets Symfony 6.4 rather than our stated Laravel/PHP framing. That makes it unsuitable as a production dependency but valuable as a scoped evaluation artifact: a few days of engineering to answer "do we build directory auth, buy an IdP, or defer the requirement?"
To engineering: Apache-2.0, so forking is clean. Treat it as a design reference for the user-provider pattern and a spike target. Do not add it to the dependency manifest without an owner, a fork strategy, and a plan for the Symfony 6.4 end-of-life horizon.
Recommended ask: approve a time-boxed spike (≤5 engineer-days) that (1) confirms whether the enterprise LDAP requirement is real and how often it appears in deals, (2) produces a build/buy recommendation weighted toward a hosted IdP for anything beyond single-directory internal auth, and (3) if we proceed, specifies a Laravel-native or IdP-based implementation rather than this bundle.