Ldaptools Bundle Laravel Package

Technical Evaluation

Architecture fit. ldaptools/ldaptools-bundle is a Symfony bundle, not a Laravel package. Its value-add is almost entirely Symfony-specific: a Bundle class, a Configuration tree for semantic config validation, compiler-pass-driven service registration, a security user provider/authenticator bridge, and a profiler data collector. None of that maps to Laravel's service container or auth guards. The actual LDAP capability lives in the sibling library ldaptools/ldaptools, which is framework-agnostic and is what a Laravel shop would consume. Conclusion: the bundle is architecturally mismatched for a Laravel target; the underlying library is a viable but unremarkable fit.

Integration feasibility. Direct install into Laravel is not viable without an adapter layer. The realistic path is to depend on ldaptools/ldaptools and write a thin LdapToolsServiceProvider that binds a singleton manager and translates config/ldap.php into the library's Configuration object. That is roughly 2–4 days of work for a developer comfortable with LDAP concepts, plus test harness time. If any internal services are Symfony-based, the bundle is the lower-effort option there.

Technical risk. The dominant risk is upstream health, not technology. 48 stars and zero dependents indicate negligible adoption and no downstream pressure to fix issues; the LdapTools family has had slow release cadence and version constraints that lag current PHP/Symfony releases. Expect a small bus factor (effectively one maintainer) and a real chance we own patches. Secondary risk: the Symfony security bridge is the fastest-moving part of the bundle, so if we ever need it, it is the most likely to be stale. LDAP itself is a stable protocol, so the core read/bind paths are low-risk.

Key questions.

• Which PHP and Symfony versions are actually supported by the current release, and does that clear our runtime baseline?
• Is ldaptools/ldaptools actively maintained, or are we adopting an effectively frozen dependency?
• Do we need write/provisioning operations (create, modify, password set) or only bind-auth and search?
• Which directory are we targeting — Active Directory, OpenLDAP, eDirectory — and do we need StartTLS/LDAPS, referrals, or paged results?
• Do we need group-to-role mapping, and is that mapping done at auth time or cached?
• Would LdapRecord-Laravel (actively maintained, Laravel-native, larger community) meet the requirement with less bespoke code?

Integration Approach

Stack fit. Weak for a pure Laravel estate, strong only where Symfony services exist. For Laravel, the recommended shape is: ldaptools/ldaptools as the LDAP engine, a first-party service provider as the seam, and a repository/gateway class that exposes authenticate(), findByUsername(), and groupsFor() to the rest of the app. Keep the library behind that seam so a swap to LdapRecord later is a one-file change.

Migration path. Two tracks. Symfony track: composer require ldaptools/ldaptools-bundle, register in bundles.php, populate config/packages/ldaptools.yaml with domain/connection definitions, then consume ldap.manager / ldap.provider services — this is a config-only integration measured in hours. Laravel track: install the library only, publish an ldap.php config mirroring the bundle's YAML schema (domains, connection type, servers, base DN, bind credentials, options), and construct the manager in a singleton binding. Reuse the bundle's documented config schema verbatim so the two tracks stay aligned if we run both.

Compatibility. Verify PHP version bounds against our runtime before anything else — this is the likeliest blocker. The library depends on PSR-3 logging and may pull PSR-6/PSR-16 caching, both of which Laravel satisfies. Watch for Symfony components leaking into the dependency graph via the bundle; installing the bundle in Laravel will drag in a subtree we do not want.

Sequencing.

1. Spike (one sprint): bind, authenticate, and search against a real directory replica; confirm TLS and schema assumptions.
2. Decide build-vs-adopt formally, with LdapRecord-Laravel benchmarked on the same spike criteria.
3. Build the adapter/provider and gateway seam behind a feature flag.
4. Port feature parity: auth, user lookup, group/role mapping, error handling.
5. Harden: TLS enforcement, connection reuse, caching of group membership, lockout-safe retry policy.
6. Cut over per-environment with the local user table retained as fallback.

Operational Impact

Maintenance. Assume we own this. Low adoption means security fixes and PHP-version compatibility patches may not arrive upstream. Budget a recurring line item for dependency review each PHP upgrade cycle, and decide early whether to vendor a fork or pin to a known-good version. Do not treat it as a strategic, long-lived dependency — the low opportunity signal reinforces that this is a utility, not a platform bet.

Support. Community-only via GitHub issues, no commercial backing, no SLA. Escalation path is internal. Document the LDAP semantics (DN formats, group nesting, filter syntax) in-repo so knowledge is not concentrated in one engineer.

Scaling. The library opens a connection per manager instance; there is no native pooling. At high auth volume this becomes a directory-server load problem, not an application problem. Mitigations: cache group/attribute lookups with a short TTL, mirror users into a local table with LDAP as the authority for credentials and periodic reconciliation, and keep connection count bounded per worker. Watch out for long-running queue workers holding stale binds.

Failure modes. Directory unavailability turns into an auth outage — decide explicitly between fail-closed (secure, user-visible outage) and fail-open-to-cache (availability, stale authorization risk). Other modes: expired or rotated TLS certificates; service-account lockout triggered by aggressive retry logic on bad credentials; DN/schema drift after a directory upgrade silently breaking filters; recursive/nested group queries returning unbounded result sets; clock skew breaking Kerberos-style flows. Each needs an explicit alert and a runbook entry.

Ramp-up. The library API is approachable, but LDAP domain knowledge — bind vs. search accounts, DN structure, filter syntax, referral behavior — is the real cost. Estimate one to two weeks for a mid-level developer to be productive, front-loaded on the spike. Allocate a second reviewer with directory-side experience, since misconfigured binds and filters fail in ways that look like application bugs.