Pumukit Cas Bundle Laravel Package

Product Decisions This Supports

• Authentication roadmap for higher-ed / institutional customers. PuMuKIT is an open-source video portal aimed at universities; CAS is the default SSO protocol for many campus IT departments. This bundle is the artifact that answers "can we ship a campus-deployable video product with single sign-on?" — a gating requirement for most university RFPs.
• Build vs. buy vs. borrow for auth. This is a thin integration bundle, not an auth platform. Its real product value is as a requirements checklist: it enumerates the seams any CAS integration must cover (client configuration, user provisioning on first login, attribute/role mapping, logout propagation). Use it to scope an internal build rather than to adopt as a dependency.
• Feature prioritization: SSO vs. SAML vs. OIDC. If you're serving universities, CAS alone is legacy-adjacent — most institutions are consolidating on SAML or OIDC via Shibboleth/Okta/Entra. This package supports the decision to skip CAS-first and prioritize standards-based federation instead.
• Platform-fit decisions. Despite the Laravel/PHP framing, this targets Symfony-based PuMuKIT, not Laravel. It is useful evidence that the video-platform ecosystem's auth needs are real, but not a reusable component for a Laravel codebase.
• Buy/partner signals. A single-maintainer (Teltek), 1-star, zero-dependent bundle for a niche CMS indicates the integration layer is not a differentiator — outsource or standardize it rather than owning bespoke code.

When to Consider This Package

Consider it only when all of the following hold:

• You are already running a PuMuKIT instance (Symfony), on a version compatible with this bundle's constraints, and CAS is the mandated campus IdP.
• You need a reference implementation or a fork starting point, not a supported dependency — you are prepared to own and patch it indefinitely.
• Your deployment is a single-tenant, on-premise university portal with an IT team that operates the CAS server.

Look elsewhere when:

• You are on Laravel (or any non-PuMuKIT Symfony app) — there is no code to reuse, only a pattern.
• You need SAML, OIDC, social login, MFA, SCIM provisioning, or multi-tenant identity — none of that is in scope here.
• You require vendor support, CVE response, or a maintenance SLA — 1 star, 0 dependents, and a single publisher mean you are the maintainer on day one.
• You are building a commercial SaaS; adopt a maintained identity layer (Keycloak, Auth0/Okta, Symfony's own CAS/security bundles) instead.

How to Pitch It (Stakeholders)

For executives: We evaluated this as a possible shortcut to campus single sign-on. Recommendation: do not adopt it as a dependency. It is a small, single-maintainer add-on for a niche open-source video CMS, with effectively no community (1 star, 0 downstream users). Auth is security-critical and low-differentiation — the wrong place to save a few weeks. Its value is as a specification for what an SSO integration must handle, which lets us scope the work precisely and then implement it on a maintained foundation.

For engineering: Treat the bundle as documentation of the integration surface — CAS client wiring, just-in-time user provisioning, attribute-to-role mapping, and single-logout — not as code to vendor in. It is Symfony/PuMuKIT-specific, so a Laravel equivalent is a native guard plus a standards-compliant IdP client; estimate one to two sprints to build and test against a campus CAS/SAML endpoint. Flag the ecosystem mismatch early so it isn't mistaken for a drop-in Laravel package.

Risk summary: No support path, no security-response process, no upgrade guarantee. The only durable thing we take from it is the requirement list.