Product Decisions This Supports
- Framework-fit triage (unchanged by v4.0.0). This is a Symfony bundle (
fr3d/ldap-bundle), not a Laravel package. v4.0.0 raises the floor to PHP >= 7.1 / Symfony >= 3.4 — that is a Symfony security-stack release, and it moves the package no closer to Laravel. Decision: remove from the Laravel candidate list; keep only as a reference implementation if we inherit a Symfony codebase.
- Enterprise-directory authentication as a roadmap item. Continued releases on a package with effectively no dependent ecosystem still confirm recurring demand for "log in with our Active Directory." That supports scoping AD/LDAP as an enterprise-tier capability, not a one-off customer hack.
- Build vs. buy for LDAP. The bundle encodes the standard architecture we'd otherwise design: LDAP as authentication provider, local user table as profile/permission store, sync on login. Reuse the pattern (identity sync, group→role mapping, deprovisioning), not the code.
- Buy vs. build the identity layer itself. For cloud-first customers, Entra ID / Okta / WorkOS / Auth0 buys SSO, SCIM provisioning, and MFA without us owning directory protocol edge cases. For on-prem/air-gapped customers, a maintained Laravel-native library (LdapRecord-Laravel, Adldap2) is the build path. This package is evidence for either decision but is not itself an option.
- Maintenance-risk policy (reinforced, not overturned). v4.0.0 is a dependency-floor bump, not a modernization: PHP 7.1 (EOL Dec 2019) and Symfony 3.4 (EOL Nov 2018) are themselves out of support, there are no new features, no Laravel/HTTP-client/identity-broker work, and the release ships a breaking change to the form validator. A one-off catch-up release after years of silence is the classic false signal of life in an archived project. Decision: keep the written rule that no auth-path dependency ships without an active maintainer and a release within ~12 months — and add that a release must clear currently supported runtime floors to count.
- Scoring hygiene. "Opportunity 10.46" is a demand signal, not an adoption signal. Automated scores must be paired with maintenance metadata (archived flag, last release, runtime floors, dependents) before anything reaches a build/buy review.
When to Consider This Package
Consider it only if all of the following hold:
- The application is Symfony 3.4-era and already uses FOSUserBundle — v4.0.0 is explicitly a Symfony 3.4 compatibility release, so it does not help newer Symfony either.
- The bundle is already installed and working — we are in maintenance mode on a legacy system, not starting new work.
- We are prepared to treat v4.0.0 as a breaking upgrade (form validator now binds to Symfony 3.4 classes), i.e. we have a regression test for the login form before bumping.
- There is no budget or mandate to migrate the auth path, and we accept that we own the code (fork it) because upstream is archived.
Look elsewhere — and by default, assume we should — when:
- The stack is Laravel. Still no Laravel integration; forcing a Symfony security bundle into Laravel is a rewrite disguised as an integration.
- We need security patching. The 4.x bump lands on EOL runtimes (PHP 7.1, Symfony 3.4); every future LDAP/CVE or PHP-version bump remains our problem.
- We need modern directory features: TLS/LDAPS hardening, paged results, nested group resolution, SCIM provisioning, MFA, or Entra ID as the directory. v4.0.0 adds none of these.
- Multiple customers need different directories. That is an identity-broker problem, not a single-bundle problem.
- The evaluation is for new greenfield work. Prefer maintained libraries or a managed identity provider; reserve this package for reading its integration pattern.
How to Pitch It (Stakeholders)
Recommendation: do not adopt. New release does not change this. fr3d/ldap-bundle v4.0.0 is a Symfony-only LDAP authentication bundle whose only change is raising dependency floors to PHP 7.1 / Symfony 3.4 — both end-of-life — plus a breaking change to form validation. No new features, no Laravel support, no modern directory capabilities, no evidence of ongoing maintainership. The package remains archived-adjacent and unsuitable for our stack.
For executives: Directory login is a real enterprise checkbox and worth roadmap space — but this package is not the vehicle. Authentication is the one dependency where "unmaintained" means unpatchable, and a login incident is a company-level event. A late dependency bump onto already-retired runtimes is the cheapest possible signal of life, and it does not reduce our risk.
For engineering: Treat v4.0.0 as a compatibility patch for legacy Symfony 3.4 + FOSUserBundle deployments only. It is breaking for the form validator, so any inherited system must regression-test the login form before bumping, and should assume it can never move past Symfony 3.4 without a rewrite. The valuable artifact remains the design: authenticate against LDAP, persist a local user record, sync group membership to roles on login, handle deprovisioning explicitly. If we pursue this, we do it with a maintained Laravel-native library or a managed identity provider, and we budget for the real work — directory schema variance, LDAP test instances in CI, and on-call coverage for auth failures.
Ask: Approve a short (1–2 week) spike to choose between a maintained library and an identity SaaS, gated on enterprise customer commitments. Treat the archived bundle as documentation of the pattern, and amend the dependency policy so that a release counts as "maintained" only if it targets runtime versions that are still supported.