Cas Guard Bundle Laravel Package

Product Decisions This Supports

• Enterprise/institutional SSO as a roadmap item. CAS (Central Authentication Service, Apereo) is the dominant SSO protocol in higher education, research institutions, healthcare, and government. If a meaningful share of your pipeline is universities, research labs, hospital systems, or public-sector buyers, "do we support CAS?" becomes a deal-qualifying question rather than a nice-to-have. This package is a ready-made answer for the Symfony segment of that question.
• Build vs. buy vs. adopt for SSO. There are three layers: (1) the CAS protocol client (apereo/phpcas, the reference implementation), (2) framework glue (firewall/authenticator integration), and (3) your own tenant/config/onboarding UX. This bundle occupies layer 2 only. It lets you skip layer 2 and spend your engineering budget on layer 3, which is the part that actually differentiates you.
• Effort sizing for a spike or prototype. Because it's a thin wrapper, you can get a working CAS login in a Symfony app in an afternoon to validate a customer requirement, then decide whether SSO is worth a real epic. That's a cheap way to de-risk a six-figure enterprise deal before committing a sprint.
• Scope boundary decisions. This package does not give you: self-service SSO configuration, multi-tenant IdP management, admin UI, SCIM/user provisioning, SAML or OIDC, or an audit/compliance surface. Those remain your product's job. That clarifies what "we support SSO" actually means in a release note.
• Protocol strategy. Choosing a wrapper around phpCAS implies you are betting on CAS specifically. If your customer base is skewing toward SAML or OIDC (most modern SaaS buying), CAS support is a long-tail accommodation, not a platform investment — which argues for a pluggable auth-provider abstraction rather than a CAS-shaped integration.

Important scoping caveat: despite the framing, this is a Symfony bundle, not a Laravel package. It integrates phpCAS with Symfony's security firewall across Symfony 3–8. If your product is Laravel, you cannot adopt it directly — the reusable asset is the pattern (wrap apereo/phpcas, expose it as a guard/authenticator), not the code. You would either use a Laravel-native CAS integration or write a thin custom guard over phpCAS yourself. Factor that into any estimate that assumed drop-in adoption.

When to Consider This Package

Adopt (or closely mirror) when:

• You are on Symfony and need CAS login to satisfy an existing or firmly committed customer requirement.
• You want the firewall/guard integration handled for you, and you're comfortable depending on apereo/phpcas for the protocol itself.
• You need broad Symfony version coverage — this package claims Symfony 3 through 8, which is unusually wide and useful for teams on an older LTS.
• Your CAS configuration is static and per-deployment (single IdP, config-file driven), not per-tenant at runtime.
• You are prototyping to validate demand, where velocity matters more than long-term dependency depth.

Look elsewhere / don't adopt when:

• You're on Laravel. This is the most likely disqualifier. Use a Laravel-native package or write the guard yourself over phpCAS.
• You need multi-tenant SSO with per-organization IdPs configured by admins at runtime. This bundle assumes deployment-level config; you'd be building the tenant layer regardless.
• Your buyers want SAML or OIDC — that's the majority of modern enterprise procurement. CAS is usually a specialized accommodation; don't mistake it for a general SSO strategy.
• Community size and bus factor are gating. 9 stars and 0 dependents is essentially no third-party validation. One maintainer organization (l3-team) owns it. If your procurement or security review requires a supported vendor, an SLA, or evidence of broad production use, this won't clear the bar.
• You need SAML-grade library maturity. phpCAS is mature and widely deployed in academia; the wrapper around it is not a large or heavily exercised codebase. Plan to own the integration's correctness yourself.
• Licensing is unresolved for your legal team. The underlying phpCAS is Apache-2.0; confirm the bundle's license and any transitive obligations before shipping.

Diligence checklist before committing: confirm the Symfony 6/7/8 path uses the modern AuthenticatorInterface (not the deprecated guard system), check open issue count and mean time to response, read the actual code size (a thin wrapper is small enough to vendor or fork), and confirm SLO (single logout) behavior — CAS logout is where most integrations quietly break, and it's the detail that generates support tickets.

How to Pitch It (Stakeholders)

For executives: A small, actively maintained open-source wrapper that lets us support CAS single sign-on — the login standard used across universities, research institutions, and public-sector systems — without writing a protocol client ourselves. The strategic value is deal enablement: it removes a hard technical blocker in institutional sales conversations at near-zero build cost. The risk is equally small and easy to contain: very low community adoption, a single maintainer, and no vendor support, so we treat it as a thin, replaceable layer we pin and can fork in days rather than a strategic dependency. Investment required is measured in engineering days, not a quarter.

For engineering: This is glue, not a protocol implementation — it wires apereo/phpcas (the reference CAS client, Apache-2.0, heavily used in academia) into the framework's security layer. The surface area is small, which is both the appeal and the mitigation: pin the version, wrap it behind our own auth-provider interface so we're not locked to CAS, and be prepared to vendor or fork if maintenance stalls. Coverage across Symfony 3–8 suggests disciplined maintenance and recent releases, but with 9 stars and zero dependents, assume no community safety net. Verify the modern authenticator path on Symfony 6+ and explicitly test single-logout before we promise it.

For the roadmap record: This is an enabler under an "Enterprise SSO" theme, not a standalone feature. It buys us protocol coverage on the Symfony side only. Budget separately for the parts customers actually experience — tenant configuration, admin UI, provisioning, and audit — and note that a Laravel-based product would require a different integration path despite the shared protocol.