Ldap Bundle Laravel Package

Technical Evaluation

Architecture fit — poor, and the framing needs correcting first. opensky/ldap-bundle is a Symfony 2 bundle, not a Laravel package. It ships a Bundle subclass registered in AppKernel, YAML config under an open_sky_ldap root key, a DI extension, compiler-pass-style wiring, and an authentication provider plugged into Symfony's security.firewalls chain. None of that has a Laravel analogue. There is no service provider, no facade, no publishable config, no auto-discovery entry. Adopting it in a Laravel codebase means either (a) pulling the whole Symfony 2 security/kernel surface in as a dependency to satisfy its type hints, or (b) forking and gutting it down to its LdapManager/LdapClient classes — a few hundred lines of ldap_* wrapper code you would be rewriting anyway. The bundle wrapper is the only thing it contributes, and the wrapper is the part that doesn't fit.

Integration feasibility — low. The package's hard dependency is symfony/symfony ~2.x and, critically, Symfony\Component\Security\Core\Authentication\Provider\UserAuthenticationProvider plus the security.context service. security.context was deprecated in 2.6 and removed in Symfony 3.0; the authentication provider interface was reworked in 3.x and replaced outright by the new authenticator system in 5.3. The code also targets PHP 5.3+ and predates PHP 7 scalar/return type changes, so PHP 8.x is out of reach without edits. In practice: not installable on any currently supported PHP or framework version without forking. The 55 stars and zero dependents are consistent with an abandoned project, not a niche one.

Technical risk — high, concentrated in the auth path. This is authentication code, so failure is user-visible and security-relevant. Specific concerns: unmaintained LDAP filter construction is a classic injection surface if attribute values reach the filter unescaped; bind credentials live in config files with no secret-management hook; TLS/STARTTLS enforcement is not a first-class concern in a bundle of this vintage; and there is no test suite signal or CI to lean on. There is also no upgrade path — the upstream author is not going to accept a PHP 8 port, and the Symfony ecosystem's answer to this problem (the native symfony/ldap component, shipped since 5.1, with a first-class ldap user provider since 5.2) supersedes it entirely.

Key questions before any commitment:

• Is the actual requirement "authenticate against AD/LDAP" or "migrate this legacy Symfony 2.8 service"? These have opposite answers.
• Which Laravel version and PHP version must we support, and is ext-ldap present in the runtime image and in CI?
• What directory is on the other side — OpenLDAP, AD, Entra ID DS — and do we need group→role mapping, nested groups, or paged results?
• Is MFA/SSO on the roadmap? If so, LDAP bind is the wrong endpoint and SAML/OIDC should be evaluated now rather than layered on later.
• Who owns the bind service account, and how are its credentials rotated today?

Integration Approach

Stack fit — no direct fit; treat this as a reference implementation, not a dependency. For a Laravel target, the realistic options in order of preference: (1) directorytree/ldaprecord-laravel, which provides a Laravel-native guard, config publishing, and an actively maintained LDAP client; (2) adldap2/adldap2-laravel if AD-specific group handling is the dominant need; (3) write a thin custom user provider over ext-ldap — roughly 150–250 lines — if the directory semantics are unusual. Option 3 is essentially what forking this bundle would produce, minus the dead Symfony scaffolding. For a Symfony target, use symfony/ldap and the native ldap user provider; the bundle is redundant.

Migration path. There is no in-place upgrade from opensky/ldap-bundle to anything — the config schema does not translate, the provider interface does not translate, and the user object handoff differs. Plan it as a cutover, not a migration: extract the behavioral contract from the existing bundle config (host/port, base DN, search filter, attribute→field mapping, group→role mapping), express that contract in the new library's config, run both against a staging directory in parallel, and diff the resolved user/role set for a sample of real accounts before flipping.

Compatibility. Assume the bundle itself is incompatible with everything currently supported and do not spend a spike proving it. The compatibility question that actually matters is ext-ldap availability in the base image, TLS trust store configuration, and whether the LDAP server enforces LDAPS-only — that last one determines whether you need a certificate bundle baked into the image, which is an infrastructure ticket, not an application one.

Sequencing.

1. Confirm the identity backend and whether SSO is on the 12-month roadmap. If SSO is likely, stop and scope OIDC/SAML instead — an LDAP integration you retire in a year is pure waste.
2. Spike a replacement library against a staging directory (2–3 days), covering bind, search, group resolution, and error handling.
3. Wire a single non-critical internal app or an admin route first; do not start with customer-facing auth.
4. Define the user provisioning side-effect (just-in-time user creation vs pre-provisioned) before go-live, since this is where LDAP integrations usually fail in production.
5. Decommission the old path, including the bind credentials and any firewall rules.

Operational Impact

Maintenance. The package is a maintenance liability with no upside: unmaintained upstream, no supported-version install, no path to PHP 8. If adopted or forked, your team owns it permanently. Budget for that explicitly — a forked LDAP auth adapter is a recurring 2–4 days/quarter of dependency-drift work, plus the security review burden of owning auth code. The 55-star/zero-dependent profile means no community to absorb CVEs or framework breakage.

Support. No vendor, no active issue triage, no security disclosure channel. Internal supportability is also weak: the failure diagnostics are Symfony 2-era exception messages, and the code will be unfamiliar to anyone who joined after Symfony 2.8. Onboarding cost is real — an engineer debugging this is learning a dead framework's security internals, not transferable skills.

Scaling. Two axes. Connection handling: the bundle binds per authentication request with no pooling, which is fine at tens of logins/minute and painful against a directory that rate-limits or locks accounts on bind storms. Directory-side: unindexed search filters or missing paged-results support will time out on large AD trees, and the resulting failures surface as generic auth errors. Neither is a hard blocker at typical internal-app volumes, but both need explicit load characterization before a broad rollout.

Failure modes. Directory unreachable → all logins fail with no graceful degradation unless you design one (cache the last-known role set, allow a break-glass local admin). Bind account password expiry → total auth outage on a date nobody tracked; this needs a rotation calendar entry, not a hope. Filter escaping bugs → silent auth bypass or false denials, hard to detect without targeted tests. Attribute mapping drift (directory admins rename or move OUs) → users lose roles without any application error. Group nesting changes → privilege creep or sudden lockouts. All of these are detectable with a synthetic login probe against staging run on a schedule; none are detectable from application logs alone.

Ramp-up. Low for the LDAP concepts, high for this specific artifact. An engineer familiar with directory auth can read the bundle's core in a few hours and conclude what this assessment concludes. The genuine ramp-up cost sits with the directory itself — schema, group nesting, referral behavior, lockout policy — and that cost is identical regardless of which library you choose. That is the strongest argument for picking a maintained library: you pay the directory learning curve once either way, but only one option leaves you with code someone else maintains.