Ldap User Provider Bundle Laravel Package

Technical Evaluation

Architecture fit — poor. Despite both being PHP, wiser/ldap-user-provider-bundle is a Symfony bundle, not a Laravel package. It targets Symfony 6.4's Security component (Symfony\Component\Security\Core\User\UserProviderInterface), Symfony's DependencyInjection container, its Bundle registration lifecycle, and the security.yaml user-provider wiring. Laravel has no bundle system, no Symfony Security component, and no security.yaml. Laravel's authentication contract is Illuminate\Contracts\Auth\UserProvider (with retrieveById, retrieveByCredentials, validateCredentials, updateRememberToken). The two interfaces are structurally similar but semantically and method-signature incompatible. "Integration" here means porting logic, not installing a dependency.

Integration feasibility — low. Laravel does ship several Symfony components transitively (HttpFoundation, Console, Finder, EventDispatcher, Routing, Translation, etc.), but it does not ship symfony/security-bundle, symfony/security-core, or symfony/http-kernel's bundle kernel. Pulling those in to satisfy a single LDAP user provider would drag the Symfony security subsystem into a Laravel app that already has a mature, opinionated auth layer — a net-negative architectural trade. The only reusable artifact is the internal LDAP query/filter/mapping logic (binding, search filter construction, DN resolution, attribute-to-user hydration), which is typically 200–400 lines and can be lifted into a custom Laravel UserProvider or guard in a day or two.

Technical risk — high, concentrated in three areas:

1. Interface/contract mismatch. Symfony UserInterface vs. Laravel Authenticatable; Symfony PasswordAuthenticatedUserInterface vs. Laravel's getAuthPassword()/hasher pipeline. Any adapter layer becomes bespoke glue that the upstream project will never validate.
2. Low signal / abandonment risk. 2 stars, 0 dependents, score 0.04. Effectively unmaintained relative to ecosystem expectations. There is no community to absorb PHP 8.x or Symfony/Laravel version bumps; you would own the fork.
3. LDAP itself is the real risk surface, independent of this package: connection pooling, TLS/StartTLS enforcement, bind-account credential rotation, paged results, referral handling, and directory-specific schema variance (AD vs. OpenLDAP vs. 389 DS). The bundle does not meaningfully de-risk any of that.

Key questions before any decision:

• Which directory? Active Directory (nested groups, sAMAccountName, paged searches, LDAP signing requirements) vs. OpenLDAP/FreeIPA materially changes the filter and attribute mapping.
• Is this authentication (bind-as-user credential validation) or authorization/attribute sync (bind-as-service, read attributes, map to Eloquent user)? These are different implementations and different failure profiles.
• What is the authoritative source of user records — LDAP only, or LDAP + local users table with linkage? This determines whether you need a provider, a guard, or a sync job.
• Are group-based roles required, and must they be evaluated per-request or cached?
• Is multi-tenancy / multiple directories in scope? The bundle's config model assumes a single provider.

Recommendation: Do not adopt as a dependency. Treat it as a reference implementation to read, and build a ~1–2 day Laravel-native provider against LdapRecord-Laravel (actively maintained, first-class Laravel integration, AD/OpenLDAP support, Eloquent-style models and query builder) or a thin ldap_* / Symfony\Component\Ldap-backed custom provider.

Integration Approach

Stack fit. Target a native Laravel auth integration:

Migration path from the bundle. The bundle's value is concentrated in its filter construction and user hydration. Extract, don't depend:

1. Read the provider's loadUserByUsername / refreshUser implementations and the search-filter builder.
2. Re-express the filter logic as an LdapRecord model scope (Model::where('samaccountname', '=', $username)->first() or a raw ldap_search filter for OpenLDAP).
3. Re-express attribute mapping as an Eloquent $fillable/accessor translation, not Symfony UserInterface hydration.
4. Discard the Symfony service definitions, Configuration tree, and event subscribers entirely — Laravel's container resolves the provider by binding, and events map to native Laravel events.

Compatibility. The bundle's Symfony 6.4 constraint is a hard ceiling: no Laravel version officially supports Symfony Security 6.4's auth APIs, and Laravel's own Symfony component constraints are pinned per major (Laravel 11 ships Symfony 7.x components as of ~2024/25). Installing it would produce dependency-resolution conflicts or, at best, an unused subtree. There is no "supported" combination — this is the single most decisive fact in the evaluation.

Sequencing (if pursuing LDAP auth in Laravel):

1. Spike (0.5–1 day): connect to the target directory from a Laravel command, verify bind, TLS, and a known-user lookup. Confirm schema and attribute names.
2. Decision gate: AD vs. OpenLDAP; auth-only vs. attribute sync; local-user linkage strategy.
3. Provider build (1–2 days): implement retrieveByCredentials = bind-as-user + directory search; retrieveById = local lookup or cached DN lookup; validateCredentials = successful bind. Register via Auth::provider().
4. Sync/roles (1 day): queued group-membership sync, cached with a TTL; guard against thundering herd on first login.
5. Fallback & hardening (1 day): local-break-glass admin account, bind-account rotation, timeouts/retries.
6. Deprecate the reference copy and vendor nothing upstream.

Operational Impact

Maintenance — you own it either way. With the bundle, you own a forked Symfony provider inside a Laravel app that will never receive upstream fixes relevant to your runtime; you inherit the maintenance burden and the impedance mismatch. With a native provider, you own ~150–300 lines of Laravel code plus a well-maintained dependency. The latter is strictly less work and far more legible to a Laravel-fluent team. The 2-star/0-dependent profile means there is no realistic chance of upstream responding to issues, and Apache-2.0 permits forking but offers no maintenance transfer.

Support. No vendor support, no community, no issue-response expectation. Your escalation path is the source code and your own team. Contrast with the native path, where ldaprecord has documentation, an active issue tracker, and a Laravel-shaped mental model that new hires already recognize. Budget for the LDAP directory side too — AD/OpenLDAP operational expertise is the actual scarce skill, not the PHP glue.

Scaling. Authentication traffic is bound by directory round-trip latency (typically 5–50 ms LAN, much worse cross-region) and by your directory's connection limits. Two scaling obligations:

• Connection reuse: open a bind per request is acceptable at low volume; at scale, use a pooled/keep-alive connection or an LDAP proxy. The bundle offers nothing here.
• Caching: cache resolved user/attribute records (Cache::remember, short TTL) to avoid a directory hit on every token refresh, but never cache the credential-validation bind itself. Also watch pagination — AD caps results at 1000 by default, so group enumeration must use paged results or LDAP_MATCHING_RULE_IN_CHAIN (1.2.840.113556.1.4.1941) for nested groups. Both are implementation concerns the bundle does not resolve for you.

Failure modes to design for explicitly:

• Directory unreachable → decide now: fail closed (all logins rejected, including admin) or fail open to a local break-glass account. Recommend fail-closed for users plus a single local emergency admin.
• Service-bind credential expiry → rotate via a secrets manager; alert on bind failure rate.
• Slow directory / no timeout → set hard LDAP_OPT_NETWORK_TIMEOUT and request timeouts; a hung bind will otherwise consume PHP-FPM workers and cascade into a full-app outage.
• Schema drift (attribute renamed, OU restructured) → the search filter silently returns zero users. Add a synthetic canary login check to monitoring.
• Partial sync / stale roles → group changes not reflected until cache TTL; make TTL explicit and short for privileged groups.
• TLS misconfiguration → StartTLS vs. LDAPS port confusion is the most common silent failure; enforce and verify in the spike.

Ramp-up. A Laravel team reads a native UserProvider + guard registration in an hour. The Symfony bundle requires the team to hold two mental models simultaneously (Laravel auth, Symfony Security) to debug a single login path — a persistent tax on every on-call rotation. For a package with 2 stars and zero dependents, that tax buys nothing.

Verdict: Low opportunity score (19.47) is consistent with the technical reality. Skip the dependency; mine the filter logic if useful, and ship a native Laravel provider on ldaprecord-laravel. Estimated delta: ~2–3 days of build versus indefinite ownership of an unsupported cross-framework shim.