Ldap Bundle Laravel Package

Technical Evaluation

What it is. FR3DLdapBundle is a Symfony bundle, not a Laravel package. It wires an LDAP directory into Symfony's security.firewalls chain by supplying an authentication provider and a user provider that maps LDAP attributes (DN, mail, cn, memberOf, etc.) onto a Doctrine-backed user entity, and delegates persistence/registration to a "user manager" such as FOSUserBundle. The design assumption is that the directory is the credential authority and the local RDBMS is the profile/authorization store, reconciled on each login.

What v4.0.0 changes. The release raises the dependency floor to PHP >=7.1 and Symfony >=3.4 and ships one breaking change: the form validator now targets Symfony 3.4 classes. There are no new capabilities — no PHP 8 support, no Symfony 5/6/7 targeting, no Laravel anything, no security process. Notably, the release notes describe 7.1 and 3.4 as "current supported versions," both of which have been end-of-life for years. That framing is itself the most informative signal in the release.

Architecture fit.

• If the target application is Laravel: fit remains poor and unchanged. There is no service provider, no Auth::viaRequest guard, no Eloquent binding. The package is only valuable as a design artifact — re-implement its attribute-mapping and user-reconciliation logic against LdapRecord-Laravel or Adldap2-Laravel.
• If the target is a legacy Symfony app: the viable window narrows to Symfony 3.4 exactly. Version 4.0.0 drops 2.3–3.3 support, so any app below 3.4 must now pin to the previous (now unmaintained) bundle major. For 3.4, the bundle is a legitimate stopgap; native LdapUserProvider only stabilizes from Symfony 4.4.
• If the target is Symfony 4.4+/5+/6+/7: fit remains poor — use the framework's built-in form_login_ldap / LdapUserProvider or ldaptools/ldaptools-bundle.

Integration feasibility. The core mechanics are unchanged: bind-as-user (or bind-then-search-then-rebind), DN lookup from a filter, attribute hydration, group/role mapping from memberOf. The expensive work is still the directory integration contract — base DN, bind account, AD vs. OpenLDAP schema differences, group nesting depth, TLS/CA posture. Effort is unchanged: 3–5 engineering days + 2–3 days for group→role mapping and edge cases on a Laravel build-from-reference path; 1–2 days to wire in-place, now contingent specifically on Symfony 3.4 (or a careful 4.x spike).

Technical risk. Still high, and the release removes one of the previous safety nets:

1. Archived status persists. A single release does not constitute upstream triage, a security response process, or CVE handling. One tagged release after years of silence is a data point, not a maintenance commitment.
2. New: permissive constraints defeat Composer's guardrail. >=3.4 and >=7.1 are open-ended. Previously, Composer would often refuse to resolve the bundle into a modern tree, failing loudly at install time. Now it will happily install into a Symfony 6/7 / PHP 8.3 application and fail at runtime, in the authentication path — the worst possible failure location. Treat the constraints as advisory and never rely on resolution success as a compatibility signal.
3. Breaking change in the auth path. The form-validator change to Symfony 3.4 classes means any existing internal fork or pinned deployment must be re-tested, not just re-tagged; a validator regression manifests as login failures, not as a cosmetic error.
4. Zero dependents / ~119 stars. Unchanged ecosystem validation. Nobody else is running this in public; debugging remains first-principles.
5. Auth-path blast radius. Unchanged. A defect here is a full outage or an authentication bypass, and it is a standing audit finding as archived auth code.

Key questions. Largely unchanged, with two additions:

• What framework and major version is the consuming app on? (If Symfony <3.4, v4.0.0 is unusable — you inherit an abandoned branch on day one.)
• Is the directory AD or OpenLDAP/389-DS, and what is the group model (flat vs. nested vs. AD token groups)?
• Is local user persistence required, or is the directory the sole source of truth?
• What is the tolerance for owning a forked, archived auth dependency — does a security review gate block it outright?
• Is SSO/SAML/OIDC already funded? If so, this is throwaway work.
• New: Does the consuming app resolve this via an open-ended constraint? If yes, what prevents it from being pulled into a future major-upgrade PR by an unrelated composer update?

Integration Approach

Stack fit. Unchanged in substance. Treat this as a pattern source, not a dependency, unless the consuming app is a Symfony 3.4 legacy system that must stay put. Laravel → LdapRecord-Laravel (or Adldap2-Laravel); Symfony 4.4+ → native LdapUserProvider; Symfony 3.4 → the bundle is a defensible stopgap. From FR3DLdapBundle, port three ideas regardless: (1) a configurable DN-lookup filter, (2) an attribute→model map, (3) a "provision on first successful bind, sync on subsequent binds" reconciliation step.

Compatibility checklist — now with a harder edge, because install success no longer implies compatibility:

• PHP version (bundle floor is 7.1; assume 8.x is unverified, not supported, despite the open constraint).
• Symfony major — must be 3.4 for the bundle to be a genuine candidate; 4.x is a spike; 5+ is a no.
• Doctrine ORM/DBAL version — the hydration path touches Doctrine.
• ext-ldap present in the target image (not universal; Alpine/scratch and some managed runtimes omit it).
• New: verify the app cannot resolve the bundle incidentally. If it is present in the tree, pin it exactly and pin the transitive symfony/* ranges so a future upgrade PR cannot silently drag archived auth code into a modern framework.

Migration path. Sequence as a strangler, not a cutover:

1. Directory connectivity spike (1 day). ldapsearch from the target runtime's network namespace; verify bind account, base DN, TLS/CA trust, and the exact attributes for one real user. No application code before this passes.
2. Auth provider behind a feature flag (2–3 days). LDAP as an additional guard alongside existing local auth. Do not remove password auth.
3. Provisioning/sync (1–2 days). First-login provisioning; map directory groups to roles via an explicit allowlist — never auto-grant from arbitrary memberOf values.
4. Pilot cohort (1 week). Named pilot group, legacy path live for everyone else.
5. Default-on, then decommission local passwords after a full business cycle including a password rotation and a joiner/leaver event.

Upgrade sequencing for existing consumers (new). Do not combine the v4.0.0 bump with anything else. The release's only functional change is a breaking validator change in the login path, so:

• Rebase the internal fork onto v4.0.0 only if the app is on Symfony 3.4; otherwise stay pinned and record the divergence.
• If the app is on Symfony <3.4, v4.0.0 is unavailable — the fork must be declared frozen at the previous major, with the Symfony upgrade now a prerequisite rather than a follow-on.
• Sequence ahead of any Symfony major upgrade, not after: upgrading and integrating archived auth in one window doubles the failure surface.
• Decide the SSO direction before step 2. If SAML/OIDC is funded within two quarters, skip LDAP bind entirely.

Operational Impact

Maintenance. Still the dominant cost, and still yours. One release after a multi-year gap does not constitute a cadence; the stated floors (PHP 7.1, Symfony 3.4) are both long EOL, so there is no evidence of PHP 8.4/8.5 readiness or Symfony 6/7 support. Budget an internal fork with a named owner, a divergence log, and a hard review at every PHP/Symfony bump. The v4.0.0 breaking validator change is the first concrete rebase cost — small in lines, but it lands in the login path and therefore requires real regression testing rather than a version bump.

Support. No vendor, no SLA, no security contact. The release notes are a two-line summary with typos and no migration guidance for a breaking change in an authentication path — that is a reasonable proxy for process maturity. Expect to solve AD/LDAP edge cases yourself: referral chasing, paged results, nested group expansion, memberOf on AD vs. memberUid/groupOfNames on OpenLDAP, kerberos-less bind restrictions, account-lockout semantics. Keep the fork in an org-controlled namespace with CI and a SECURITY.md.

Scaling.

• Auth-path latency is directory-bound, not code-bound: typically 2–3 LDAP operations per login (service bind, search, user bind). Budget 50–150 ms directory latency; cache DN lookups and attribute sync with a short TTL to keep p95 login under ~400 ms.
• The real hazard is directory availability as a hard login dependency. Mitigate with multiple LDAP URLs/failover, a session-resume path that does not re-query LDAP per request, and a documented break-glass local admin.
• Bind-account rate limits and connection pooling matter at volume; the bundle does not manage connections for you.

Failure modes.

• Directory down / network partition → login outage; 2–3 s timeout, retry-with-failover, error path distinct from "bad password" (never leak directory state into the login error).
• Bind-account credential expiry or lockout → silent total auth failure; synthetic login probe, rotation via secrets manager.
• TLS/CA rotation → sudden Can't contact LDAP server; pin the CA bundle, alert on handshake failures.
• Schema drift (attribute renamed, OU moved) → login succeeds but profile/role sync degrades silently; assert on required attributes and log loudly.
• Stale local records → treat "user no longer in directory" as a deprovisioning signal, not just a no-op.
• Nested/missing group mapping → privilege escalation if auto-mapped; explicit allowlist, fail closed to least privilege.
• ext-ldap absence after a base-image change → deploy-time breakage; pin and test in the image build.
• New: silent resolution into a modern framework major. Because the constraints are open-ended, a routine composer update on an upgraded app can pull archived auth code into a Symfony 6/7 / PHP 8 runtime where it fails at login. Add a tree check for this package to the framework-upgrade runbook and CI.

Ramp-up. 1–2 weeks for a mid-level engineer to become productive with LDAP semantics and the fork absent directory experience; 3–5 days with AD/OpenLDAP background. Add half a day of directory-owner time for base DNs, service-account policy, and group taxonomy — still the longest-lead external dependency; request it on day one.

Bottom line. The prior verdict was replace, don't adopt, and v4.0.0 does not overturn it — it refines it. The release is a maintenance signal, not a capability signal: it raises the floor to two long-EOL versions, ships one breaking validator change in the login path, and adds nothing for the Laravel target. Its one genuinely new consequence is negative: open-ended >=3.4 / >=7.1 constraints mean Composer will no longer fail loudly on a modern tree, so the package can enter a Symfony 6/7 application and fail at runtime instead of at install. For a Laravel target: still no-go as a dependency, useful only as a reference; build on LdapRecord. For Symfony 3.4: acceptable as a pinned internal fork with an explicit exit ticket tied to the next framework upgrade — and v4.0.0 is the baseline for that fork. For Symfony <3.4 or 4.4+: not a candidate. In all cases, gate the decision on the SSO roadmap; if SAML/OIDC lands within two quarters, this work is disposable and should not be started.