Ldaporm Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy vs. borrow for directory integration. This package is a concrete reference point for the "borrow" option: it demonstrates an entity-manager abstraction over LDAP so application code can treat directory records as persistable objects instead of hand-written ldap_* calls and filter arrays. That directly informs how much scope an in-house directory layer would actually require.
• Identity and access-management roadmap sequencing. If SSO, corporate directory sync, group-membership resolution, or LDAP-backed user provisioning appear anywhere on the roadmap, this is a forcing function to decide now whether directory access is a first-class domain concern with its own repository interface or a thin adapter hidden behind an abstraction — a decision that is expensive to reverse later.
• Framework alignment and portability. Despite the Laravel/PHP framing in the brief, this is a Symfony 2 bundle with Symfony bundle and DI wiring. It supports a product-level call on whether the directory layer is framework-agnostic (portable across Laravel, Symfony, and CLI workers) or coupled to one framework's container — which determines whether a future framework migration touches identity code.
• Technical risk triage and dependency governance. Ten stars, zero dependents, a 0.26 health score, an unmaintained Symfony 2 runtime, and an unasserted license ("NOASSERTION") together justify a documented "do not adopt as a dependency" decision — and justify budgeting either for a maintained alternative or for a thin internal adapter with a named owner.
• Legal and procurement gating. The absent license declaration is a product-level blocker for commercial distribution or code reuse, including copy-paste. It supports mandating license review as a gate in the intake process for any third-party dependency.
• Total cost of ownership modeling. An unmaintained, EOL-framework artifact means we absorb PHP-version compatibility, security response, and LDAP protocol-change patching. That is recurring headcount, not a one-time integration line item — a useful input when comparing vendor, open-source, and internal-build options on a multi-year horizon.
• Scope containment for LDAP correctness work. Paged results, referral handling, filter escaping, and TLS/StartTLS behavior are the failure modes that make directory integrations expensive. Using this package as a checklist drives more accurate estimation and clearer acceptance criteria for whichever solution we pick.

When to Consider This Package

Consider it only when:

• You are maintaining an existing Symfony 2 application that already depends on it, and the cheapest path to stability is pinning and patching rather than replacing.
• The requirement is narrow and read-mostly: simple lookups and entity-style mapping over an internal directory, low query volume, latency-tolerant.
• Your team is prepared to vendor and fork it — pin the source, audit it, resolve the license, and explicitly own upgrades and security response.
• You want it as a design reference for modeling LDAP as a repository/entity layer, without shipping the code.

Look elsewhere when:

• You are on Laravel. This is not a Laravel package; it will not integrate with Eloquent, the Laravel container, or service providers without a rewrite. Evaluate LdapRecord first.
• You are on Symfony 5/6/7. Symfony 2 has been end-of-life since 2019; the dependency graph will not resolve cleanly and you inherit unsupported transitive packages. Use Symfony's native Ldap component.
• You need active maintenance, a security response path, or a support SLA — none of which this project evidences.
• You require license clarity for commercial use; "NOASSERTION" means legal cannot sign off without diligence.
• Your requirements include write-heavy directory operations, schema validation, large or paged result sets, or connection reuse — the ORM abstraction tends to obscure the performance characteristics you need to control explicitly.
• A managed identity provider (Entra ID, Okta, Keycloak) or SCIM provisioning already covers the use case; a bespoke LDAP ORM becomes pure overhead.

How to Pitch It (Stakeholders)

For executives: This is a small, unmaintained Symfony 2 library that lets application code treat LDAP directory records like database entities. The idea is worth borrowing; the code is not a safe production dependency — ten stars, no downstream users, no clear license, and a framework that has been unsupported for years. Recommendation: do not adopt; treat it as a design input, and fund either a maintained library or a thin internal adapter behind a stable interface. The decision to make now is architectural: keep the directory layer framework-agnostic so we are not repaying this choice in two years. The immediate gate is legal — the license must be resolved before any code, even a copied class, enters the repository.

For engineering: Read it for the entity-manager-over-LDAP pattern, not the code. If we build, we build a narrow repository interface (findByDn, search, bind) with a swappable driver and integration tests against a containerized OpenLDAP/AD instance. If we buy, LdapRecord is the candidate for Laravel and the Symfony Ldap component for Symfony. Either path must instrument bind failures, referral loops, paged-result truncation, filter escaping, timeout asymmetry, and TLS misconfiguration from day one — those are correctness risks, not performance tuning. And before adoption of anything, the "who patches this in 18 months" question needs a named owner.