Simple Ldap Bundle Laravel Package

Technical Evaluation

Verdict up front: not adoptable as a dependency. The package is a Symfony bundle, not a Laravel package, last released 2017-02-08, with 1 star and 0 dependents. Both framework fit and maintenance posture fail the bar for anything on the authentication path.

Architecture fit

• Wrong framework. SimpleLdapBundle is a Symfony Bundle — it relies on Symfony's kernel, dependency-injection extension, semantic config tree, and (circa 2017) the Security component's authentication provider/listener model. Laravel has no bundle registration mechanism; adoption means writing an adapter layer plus a Laravel guard/user provider on top.
• Dead upstream APIs. The Symfony security interfaces this bundle targets (AuthenticationProviderInterface, UserProviderInterface in their 2.x/3.x form) were deprecated in Symfony 4.2 and removed in 5.0. The code is structurally incompatible with any current Symfony or Laravel release.
• Authentication is a security-critical seam. Putting abandoned, unaudited code in the credential-verification path inverts the usual build-vs-buy logic — we would inherit all the risk with none of the maintenance.

Integration feasibility

• Composer resolution is expected to fail outright: the bundle will constrain php to the 5.x/7.0–7.1 era and pull symfony/* ^2.7/^3.0 transitives that conflict with Laravel 9–11 (Symfony ^6/^7). Forcing it with --ignore-platform-reqs or a fork is not acceptable for auth code.
• Effective integration cost is greater than the cost of a purpose-built LDAP guard using ext-ldap (roughly a few hundred lines: bind, search, group expansion, JIT user provisioning).
• No usable safety net: no CI, no test suite, no issue triage, no changelog discipline visible. Any defect we hit, we fix blind.

Technical risk

• Bus factor of one, with no activity for ~9 years. No CVE monitoring surface, no upgrade path for PHP 8.x.
• Unknown handling of LDAP filter escaping, TLS/StartTLS certificate verification, and credential logging — the three places this class of code most often fails.
• Opportunity cost: time spent adapting it is time not spent on a supported library.

Key questions

1. What is the actual driver — LDAP (OpenLDAP/FreeIPA) or Active Directory? Many "LDAP" requirements are really AD, with different semantics (referrals, nested groups, paged results).
2. Is the need authentication only, or also directory search, group-to-role mapping, and profile sync?
3. Which Laravel version and PHP version are the target? Is Symfony actually the target framework (i.e., was this package proposed for the wrong stack)?
4. Do security policy and SDLC rules permit unmaintained third-party code on the auth path? (Assume no.)
5. Is there budget to fork and maintain indefinitely? If not, the debate ends here.
6. Does the directory require LDAPS/StartTLS, MFA, or password-write (self-service reset)? These rule out simple bind-only bundles regardless.

Integration Approach

Stack fit

• None, as-is. This is a Symfony-2/3-era bundle in a Laravel codebase.
• The only defensible use is reference material: read the bind/search flow, then reimplement against Laravel's native extension points.

Recommended paths (in order of preference)

1. Supported library: directorytree/ldaprecord-laravel — actively maintained, Laravel-native guard/provider integration, handles AD and OpenLDAP, group mapping, and connection configuration. Verify current Laravel/PHP support against our version before committing.
2. Native implementation: custom Auth::extend guard + UserProvider over ext-ldap. Full control of TLS options, filter escaping, timeouts, and group resolution. Best when requirements are unusual (multi-domain AD, nested groups, custom attribute mapping).
3. If Symfony is genuinely the target: use the built-in symfony/ldap component with the native LDAP user provider — do not resurrect this bundle.
4. Rejected: fork-and-patch SimpleLdapBundle for Laravel. Cost exceeds replacement; permanent maintenance liability.

Migration path

• Introduce LDAP as an additional auth driver behind a feature flag, not a replacement.
• Keep DB-backed users; add ldap_dn / directory_id columns and JIT-provision on first successful bind (map attributes to local user record; never store the directory password).
• Retain a break-glass local admin account with a documented, audited procedure for directory outages.
• Dual-run local + LDAP auth for the pilot cohort; cut over per-tenant or per-group.

Compatibility checklist before any code

• Directory flavor and version; base DNs; bind account vs anonymous; LDAPS/StartTLS and CA trust chain.
• Attribute mapping (uid/sAMAccountName/mail/displayName), group source (memberOf vs group search), nesting depth.
• Network: egress from app hosts to directory on 389/636, DNS SRV, latency budget.
• Laravel version ↔ chosen library's supported matrix; lockfile impact.

Sequencing

1. Requirements workshop (directory type, authn vs authz, group mapping, MFA interaction) — 1 week.
2. Connectivity + TLS spike from a staging app host — 2–3 days.
3. Build/configure guard + user provider + group→role mapping; unit and integration tests against a containerized OpenLDAP/AD stand-in.
4. Pilot with a small cohort; instrument success/failure metrics and bind latency.
5. Production cutover with fallback path; document rollback.
6. Delete any exploratory fork of the bundle from the codebase so it cannot accrete.

Operational Impact

Maintenance

• Zero upstream maintenance since 2017. If adopted, every PHP upgrade, Symfony/Laravel bump, and security patch becomes our work — effectively an internal fork with a single-owner risk of its own.
• No dependents means no ecosystem pressure, no community patches, and no signal if it breaks in the wild.
• Contrast with a maintained library: upgrades tracked upstream, CVEs surfaced by advisory feeds, documented Laravel-version support.

Support

• Documentation is a README; no SLA, no vendor, no responsive maintainer. Internal LDAP + Symfony-wiring expertise becomes a hiring and onboarding constraint.
• Realistic support model if forced: named owner on the platform team, quarterly dependency review, and a documented exit plan.

Scaling

• LDAP bind is per-login; confirm the design does not bind per-request. Per-request binds multiply load on the directory and add tens of milliseconds to every page.
• PHP-FPM workers each hold their own connection — watch directory server connection limits and set explicit connect/read timeouts so a slow directory cannot exhaust the FPM pool.
• Large groups require paged results; nested/multi-domain AD requires referral following. These are common gaps in 2017-era bundles.

Failure modes to design for

• Directory outage → authentication unavailable. Mitigate with a break-glass local account, clear user-facing error state, and a documented degraded-mode policy (avoid any "cache credentials" scheme).
• TLS certificate expiry or trust-store drift → total login failure; add cert-expiry monitoring as a first-class alert.
• Lockout amplification: retries from app or queued jobs can trip AD lockout policy; rate-limit and never retry auth binds automatically.
• Filter injection via unescaped username input; timeouts hanging workers; bind credentials appearing in logs or exception traces.
• Silent drift: directory schema or base DN changes break login with no code change and no upstream changelog to consult.

Ramp-up

• A Laravel team needs roughly 1–2 weeks to become productive with this bundle's Symfony wiring plus LDAP semantics — most of which is thrown away if we later replace it.
• The same 1–2 weeks spent on a supported library or a native guard yields an asset the team can maintain, test, and extend.
• Ongoing: ~0.1–0.2 FTE if forked and owned internally; near-zero if a maintained library is used.

Bottom line for the decision record: reject yunai39/simple-ldap-bundle. It is the wrong framework, out of support for roughly nine years, and sits on the most security-sensitive path in the application. Fund an LDAP integration built on a maintained library or a native guard instead, and treat this package only as a historical reference for the bind/search flow.