Pumukit Ldap Bundle Laravel Package

Technical Evaluation

Architecture fit. The first and most important finding: this is not a Laravel package. PumukitLDAPBundle is a Symfony bundle, and specifically a component of the PuMuKIT video/lecture-capture platform (Teltek). It is an adapter that binds PuMuKIT's user model and metadata pipeline to an external directory — it is not a reusable LDAP library. It has no Laravel service provider, no facade, no Eloquent integration, and no meaning outside a PuMuKIT-installed Symfony kernel. Treating it as a candidate for a Laravel application is a category error; the only valid fit is "we are already running PuMuKIT."

Integration feasibility. Feasibility is entirely conditional:

• On Laravel: not feasible. The correct path is a maintained directory library (LdapRecord-Laravel, Adldap2-Laravel, or a thin ext-ldap/symfony/ldap wrapper) plus a sync job that maps directory attributes to your user/metadata schema. This bundle gives you nothing you can transplant.
• On PuMuKIT: feasible as a Composer dependency, but only after verifying the bundle's composer.json constraints against your Symfony and PHP versions. Given the 1-star / 0-dependent profile, assume the bundle targets the Symfony 3.x–4.x / PHP 7.x era and will need patching for PHP 8.

Technical risk. High, concentrated in four areas:

1. Bus factor of one-ish. Single-vendor, single-platform, single-star, zero dependents. No meaningful community to triage issues. Effectively an unmaintained internal artifact published for convenience.
2. Security-critical code path. LDAP integration touches authentication, bind credentials, and TLS. Risks include LDAP injection via unescaped filter input, cleartext or improperly validated StartTLS/LDAPS, service-account password handling in config, and over-broad search bases. A low-visibility bundle is the last place you want unaudited auth code.
3. Data/identity duplication. Pulling directory attributes into PuMuKIT's database duplicates PII, which has GDPR/lifecycle implications (retention, right-to-erasure, sync staleness) that a 1-star bundle almost certainly does not address.
4. Schema variance. AD vs. OpenLDAP vs. eDirectory differ in attribute names, paged results, referrals, and bind semantics. Expect hardcoded attribute mappings that will not survive a directory migration.

Key questions to resolve before any commitment:

• Which Symfony and PHP versions are actually supported, and is the bundle formally abandoned on Packagist?
• Does it perform authentication (bind-as-user) or only metadata enrichment (service-account read)? These have very different security postures.
• Is there any test suite, and does it cover filter escaping and TLS handling?
• How are attribute mappings configured — YAML, hardcoded, or per-directory adapters?
• What is the license, and is forking viable from a legal and practical standpoint?
• Is the goal "authenticate our users via LDAP" or "autofill profile metadata from the directory"? The bundle's description implies the latter; teams routinely assume the former.

Integration Approach

Stack fit. Confirm the stack first. If the target application is Laravel, do not integrate this package — the effort would be spent reverse-engineering a PuMuKIT-specific adapter to extract a small amount of LDAP query logic that a maintained library already provides better. If the target is PuMuKIT (existing deployment or a platform evaluation), this bundle is the sanctioned path and the question becomes version pinning and patching rather than architectural fit.

Migration path (PuMuKIT case). (1) Vendor the bundle into Composer with an explicit version pin; (2) configure LDAP connection parameters and attribute mappings in the Symfony config layer; (3) wire it into the user provider / metadata-fill flow; (4) run a directory sync against a staging directory and diff attribute coverage before touching production. Plan for a local fork from day one: assume you will own the code, not consume it.

Migration path (Laravel case). Replace, don't port. Select a maintained LDAP package, define an internal DirectoryGateway interface, and implement attribute mapping yourself. This is roughly the same amount of work as wrestling the Symfony bundle into a foreign kernel, but yields something supportable.

Compatibility. Verify PHP 8.x, current Symfony LTS, and the target directory server (AD vs. OpenLDAP) independently — a green Composer install says nothing about runtime behavior against your actual schema. Check for deprecated Symfony APIs and removed PHP functions.

Sequencing. Run a 1–2 week spike before committing: connect to a non-production directory replica, prove bind + search + attribute mapping end-to-end, measure sync time against realistic directory size, and explicitly test failure of the directory. Only after that spike should this become a roadmap item. Do not sequence it before the identity model is settled — retrofitting LDAP attribute mapping onto a finalized schema is expensive.

Operational Impact

Maintenance. Assume zero upstream maintenance. Budget for a maintained fork with a named owner, dependency-update cadence, and a security review of the bind and filter-construction paths. This is a recurring cost, not a one-off integration cost, and it is disproportionate to the feature's business value.

Support. No vendor SLA, no paid support, issues handled (or not) on GitHub. Escalation for a login-affecting outage lands on your own team. That must be accepted explicitly by whoever owns identity.

Scaling. Directory queries typically occur on login and on profile refresh, so load is proportional to authentication volume rather than application traffic. Watch for: connection-per-request without pooling, unpaged searches against large directories, missing caching of rarely-changing attributes, and search bases broad enough to scan the whole tree. The bundle is unlikely to solve any of these; plan to add caching and connection reuse around it.

Failure modes. The realistic ones: directory outage blocks login and/or metadata fill; service-account password rotation or account lockout silently breaks sync; TLS certificate expiry; schema drift after a directory upgrade; stale cached attributes presenting incorrect user data; unescaped filter input enabling injection; and silent partial syncs that leave users with incomplete profiles and no alerting. Every one of these needs monitoring — health check on bind, sync success/failure counters, and attribute-coverage alarms.

Ramp-up. The technical surface is small and learnable in days. The real ramp-up cost is contextual: PuMuKIT's bundle conventions, Symfony DI wiring, and your organization's directory schema and governance. A competent PHP engineer can read this bundle quickly; the risk is that there is no documentation to read and no community to ask.

Recommendation. Score and signals (1 star, 0 dependents, 0.105) align with what the code inspection implies: this is a platform-locked, low-visibility component, not an integration library. Adopt only if PuMuKIT is already a committed part of the stack, and then only with a fork-and-own plan and a security review. If the underlying need is LDAP-backed identity or directory-sourced metadata in a Laravel application, this package is not a candidate — select a maintained alternative and budget the attribute-mapping work separately.