Ldaporm Bundle Laravel Package

Technical Evaluation

Architecture fit: mismatched on two axes — framework and runtime. The package is a Symfony 2 bundle (EOL since November 2018, PHP 5.x–7.0 target), not a Laravel package. The value it demonstrates — mapping LDAP directory entries to PHP objects behind a Doctrine-style entity manager and fluent query builder — is a sound pattern, but the shipped artifact is bound to Symfony's bundle/DI/annotation machinery and cannot be dropped into a Laravel container. Treat this as a design reference, not a dependency candidate. The framework-alignment decision it forces (directory layer framework-agnostic vs. container-coupled) is the real deliverable of this evaluation, and it is expensive to reverse later.

Integration feasibility: low without a fork; the fork is not worth it. There is no service provider, no publishable config, no facade, and no Eloquent/Query Builder bridge. A Laravel bridge would require porting container wiring, replacing Doctrine annotations (deprecated since Annotations 1.13, superseded by PHP 8 attributes) with attributes or array config, and isolating Symfony event-dispatcher coupling — i.e., a re-implementation. With 10 stars and 0 dependents, we would be the first production consumer with no community-tested path to copy.

Technical risk register.

Key questions to close before any build/buy/borrow decision.

1. What is the actual license, and is there an inherited license from a parent project? (Hard gate — legal owns this.)
2. Exact composer.json PHP and symfony/* constraints — confirms the runtime gap rather than assuming it.
3. Does the LDAP client layer wrap ext-ldap directly or delegate to symfony/ldap? The latter might be separately salvageable.
4. Is the repository archived or receiving commits in the last 24 months? (Determines whether "borrow" is even viable.)
5. Are LDAP filters escaped, and are paged results implemented with cookie handling? Unescaped filters are an injection finding, not a nit.

Recommendation to the product org: score 0.26 is the correct signal. Close the adopt-as-dependency path; retain the package as a written rationale and a pattern reference. Budget for a maintained substitute or a thin internal adapter behind a stable interface.

Integration Approach

Stack fit: substitute, don't port. For Laravel the pragmatic equivalent is directorytree/ldaprecord + directorytree/ldaprecord-laravel — Eloquent-like models over LDAP, a real service provider, publishable config, PHP 8 attributes, and active maintenance. It satisfies the same conceptual need (directory entries as models with finders and relationships) on a supported runtime. For a Symfony application, use the native Symfony Ldap component. Neither is a like-for-like port of Gorg; both are lower-total-cost replacements.

Migration path (where LDAP modeling already exists in our codebase).

1. Freeze the concept, not the code. Catalogue the domain model: object classes mapped, attributes consumed, relationships (group membership, manager chains, OU hierarchy), and every finder actually called. This artifact is the durable output of the evaluation.
2. Re-express as model definitions. Each former annotation becomes a PHP 8 attribute or config/array entry in LdapRecord.
3. Re-point behind our own interface. Define DirectoryRepository (findByDn, search, bind) and route all callers through it, so the backend is swappable and this decision never has to be relitigated at the call-site level.
4. Lift narrowly, if at all. If one capability is genuinely unique (a specific hydration behavior), isolate that single class and re-run license review on it in isolation. Do not port the bundle.

Compatibility: zero for Laravel 10+. Confirmed blockers, in order of hardness: PHP version floor, Symfony 2 component constraints, annotation metadata driver, absence of a Laravel provider. There is no "install and alias" path; any framing of this as a quick integration should be corrected in the plan of record.

Sequencing (four-week gate structure).

• Week 1 — Legal and source audit (hard gate). License resolution, composer.json inspection, LDAP wrapper and filter-escaping review. No engineering spend before this closes.
• Week 2 — Spike. Prototype the two or three hardest directory queries in LdapRecord against a staging directory. Exit criteria: paged result handling, group membership resolution, TLS bind all pass.
• Week 3 — Decision gate. Spike passes → close Gorg, adopt LdapRecord, document rationale. Spike fails on one capability → scope a narrow fork of that capability only.
• Week 4+ — Build. Repository interface, models, integration tests against a containerized OpenLDAP/AD instance, instrumentation per the failure modes below.

Operational Impact

Maintenance. Adopting this package means owning it outright. One maintainer, 10 stars, zero dependents: no PHP 8.3/8.4 compatibility work, no CVE response, no fixes as LDAP tooling evolves. Every future PHP or framework upgrade becomes our patch — a recurring headcount line, not a one-time integration cost. Against LdapRecord, that burden is amortized across a user base.

Support. No commercial support, no reliable issue triage, no meaningful documentation site. The practical cost is source archaeology: engineers must read the code to learn hydration semantics because no spec exists. Budget two to three days per engineer before the first meaningful change, and require a named owner for "who patches this in 18 months" before any adoption decision — an unowned dependency handling credentials is an audit finding waiting to happen.

Scaling. ext-ldap has no connection pooling; every request performs a fresh bind. That constraint is inherited by any PHP LDAP package, so the ORM's overhead sits on top of an already latency-bound operation. Watch specifically for: per-request bind storms under load, ldap_search result-size limits silently truncating (the classic 1000-entry Active Directory default), paged-results cookie handling under concurrent workers, and PHP-FPM worker exhaustion when directory latency exceeds request lifecycle expectations.

Failure modes to instrument from day one. These are the ones that produce silent correctness bugs rather than clean errors:

• Bind failure — bad credentials, unreachable directory, and TLS negotiation failure surface identically without explicit handling.
• Paged result truncation — returns partial data that looks complete; assert expected counts rather than trusting row totals.
• Filter escaping — unescaped user input in LDAP filters is an injection vector; verify, don't assume.
• Referral loops — AD referrals chased indefinitely by naive clients.
• Timeout asymmetry — LDAP timeouts do not align with max_execution_time; a hung directory can take down the worker pool.
• TLS/StartTLS misconfiguration — fails open in some client configurations; enforce certificate validation explicitly.

Ramp-up. Assume two to three weeks to productivity for a mid-level engineer, dominated by directory schema knowledge — object classes, attribute semantics, DN construction, AD vs. OpenLDAP divergence — not by package familiarity. That knowledge transfers cleanly to LdapRecord or the Symfony component; the Gorg-specific knowledge does not, and should not be budgeted as an asset.

Roadmap bottom line. The license alone disqualifies the package pending legal resolution, and the Symfony 2 runtime makes integration cost exceed a rewrite. Recommend closing the evaluation with a written rationale, recording the framework-agnostic directory-layer decision as the durable output, and substituting directorytree/ldaprecord-laravel — reserving a narrow fork only for a capability a spike proves unique and necessary.