Pumukit Ldap Bundle Laravel Package

Product Decisions This Supports

• Feature scoping: directory-driven onboarding and metadata autofill. If our users already live in an enterprise LDAP/AD directory, this bundle's core capability — connect to LDAP and pull identity attributes to prefill metadata — maps directly to "auto-populate user profiles, roles, and author/contributor records instead of asking people to retype what IT already knows."
• Roadmap input: SSO and enterprise readiness. Enterprise deals increasingly ask "does it integrate with our directory?" This repo is a concrete reference for what that integration looks like in a Pumukit-style video platform (Symfony bundle, LDAP bind + attribute retrieval). Useful as a scoping artifact even if we don't adopt the code.
• Build vs. buy vs. fork. The package is a thin, single-star, zero-dependent Symfony bundle tightly coupled to Pumukit. The PM decision is not "adopt vs. don't" but "borrow the pattern vs. depend on the code." For a Laravel codebase, the realistic buy-in is a maintained LDAP library (LdapRecord, Adldap2) plus a small in-house mapping layer — this repo tells us the mapping layer is small.
• Integration risk register. 1 star, 0 dependents, effectively no community = no upstream fixes, no security patch cadence, no support. That's a decision input for any roadmap item that would create a hard dependency.
• Use cases it validates: corporate/university video portals where identity, department, and role data must flow from AD into the platform; contributor metadata prefill for media publishing; reducing admin data entry and account provisioning friction.

When to Consider This Package

Consider it if:

• You are running (or forking) Pumukit, on Symfony, and need LDAP-backed metadata fill inside that ecosystem specifically.
• You want a reference implementation of the LDAP connect → attribute lookup → metadata map flow to copy into your own codebase.
• Your LDAP schema is simple and stable (standard AD attributes: mail, displayName, department, telephoneNumber) and you can own the code as a vendored/patched dependency.

Look elsewhere if:

• You are on Laravel. This is a Symfony bundle for a specific platform; adapting it costs more than writing the equivalent against LdapRecord/Adldap2.
• You need maintained, supported, security-patched software. One star, zero dependents, and no visible release/CI signals mean you will be the maintainer.
• You need SSO/authentication, not just attribute retrieval — this is a metadata-fill helper, not an identity provider. Pair it with (or replace it by) a real auth integration (SAML/OIDC/LDAP bind via a maintained library).
• You need multi-directory, schema-flexible, or high-volume sync — a purpose-built sync service or established library will be more robust.
• Anything customer-facing on an SLA. Do not put an unmaintained bundle on a revenue-critical path.

How to Pitch It (Stakeholders)

For executives (one paragraph): We evaluated an open-source connector that lets our platform read user data — names, emails, departments, roles — directly from a company's LDAP/Active Directory, so customers don't re-enter data the IT department already owns. The capability is valuable and repeatedly requested by enterprise buyers as part of "directory integration." However, the specific package is effectively a single-organization utility: one star, no downstream users, tied to a different framework (Symfony/Pumukit) than our Laravel stack, and unmaintained. It is a useful design reference, not a dependency. Recommendation: build a small in-house connector on a maintained LDAP library, using this package as a scoping template — low effort, low risk, no orphaned dependency.

For engineering: This bundle is a thin Symfony service that binds to LDAP and returns attributes for metadata prefill. Do not add it as a dependency — the framework mismatch (Symfony bundle vs. Laravel), zero dependents, and lone-star status mean we'd own every line. Instead: spike an equivalent with LdapRecord (~1–2 days), define a clean attribute-mapping config (AD field → our user/contributor metadata), cache results, and handle bind failures gracefully. Treat directory sync as an optional, config-driven module, never a hard auth requirement.

Ask: Approve a small discovery spike (design + prototype) rather than an adoption decision; revisit adoption only if a maintained, framework-appropriate package emerges.