Ldaprecord Bundle Laravel Package

Product Decisions This Supports

• Enterprise authentication roadmap: Still informs whether to add LDAP/Active Directory login, directory-backed user lookup, or group-based authorization to a Symfony-based PHP product — but the viable baseline is now Symfony 6.1+/PHP 8.1+.
• Build vs. buy/integrate: The v4.0.0 release (LdapRecord v3, modern Symfony/PHP floors) keeps this a credible thin integration layer rather than something we must own outright — provided we can absorb a breaking namespace change.
• Ecosystem scope: Confirms the bundle tracks upstream LdapRecord majors outside Laravel. Relevant if the portfolio spans Laravel and Symfony services and we want a consistent directory-access library across both.
• Delivery risk / maintenance signal: Materially improved versus the prior read — an actively versioned release with a documented changelog and contributor PR supersedes the "last release May 2023" abandonment concern. Adoption breadth (stars/dependents) is still thin, so risk shifts from abandonment to small-maintainer concentration.
• Upgrade cost as a decision input: The namespace move from Iter8\Bundle\LdapRecordBundle\Iter8LdapRecordBundle to Iter8\LdapRecordBundle\Iter8LdapRecordBundle is a breaking change requiring config/service rewiring and any local overrides to be touched. That is real, bounded work — worth sizing before committing.
• Use-case prioritization: Unchanged — fits contained directory-authentication needs better than full identity-platform requirements such as SAML/OIDC, SCIM provisioning, MFA, or access governance.

When to Consider This Package

• Consider it when the application is Symfony 6.1+ on PHP 8.1+, already standardizes on LdapRecord v3, and needs basic bundle wiring for configuration and services.
• Consider it more favorably than before for greenfield Symfony work, since the dependency floors now match currently supported Symfony/PHP versions rather than pinning us to end-of-life runtimes.
• Consider it for a time-boxed proof of concept where MIT licensing, simple integration, and direct vendor/fork control are acceptable — the v4 release reduces, but does not eliminate, the case for a fork contingency.
• Upgrading an existing v3 integration? Treat v4.0.0 as a planned migration, not a patch: budget for the namespace rename, LdapRecord v2→v3 API changes, and a regression pass against target directories.
• Look elsewhere for Laravel applications, where the first-party LdapRecord Laravel integration is the more natural choice.
• Look elsewhere if you need broad adoption, commercial support, SLA-backed security response, or proven production references at scale — a single-maintainer, low-star package remains the profile here.
• Avoid making it a core dependency for complex identity requirements — SSO, federation, provisioning, MFA, or compliance-heavy IAM — without a clear plan to own compatibility and maintenance.

How to Pitch It (Stakeholders)

Executive summary: This is a small MIT-licensed Symfony bundle that connects Symfony applications to LdapRecord for enterprise LDAP/AD authentication. The new v4.0.0 release is a positive maintenance signal — it upgrades to LdapRecord v3 and raises the baseline to Symfony 6.1 and PHP 8.1 — but it is a breaking release (bundle namespace change) and the project is still a low-adoption, single-maintainer dependency. Treat it as a tactical integration with a known upgrade path, not a strategic identity platform.

For engineering: v4.0.0 modernizes the dependency stack and is the version to target for any new work on supported Symfony/PHP. The namespace moved to Iter8\LdapRecordBundle\Iter8LdapRecordBundle, so existing v3 installations need a deliberate migration: update bundle registration and config references, absorb LdapRecord v2→v3 changes, and re-run integration tests against target directory servers. Confirm the release's actual test coverage before relying on it.

For product: It still supports enterprise customer requirements around directory-based login and group-driven access with limited initial build effort, and the fresh release lowers the "will this be maintained?" objection. Do not position it as turnkey SSO or enterprise IAM. Position it as a contained directory-authentication enabler, now with a cleaner upgrade story and a smaller — but still present — fallback plan to fork or maintain in-house.