Symfony Cas Bundle Laravel Package

Product Decisions This Supports

• Enterprise/higher-ed SSO go/no-go: If a prospect requires CAS-based single sign-on (common across universities and research institutions), this package answers the "can we support CAS without building it ourselves?" question. It wraps the Apereo phpCAS client, so the protocol work is vendor-maintained rather than bespoke.
• Build vs. buy on authentication: The bundle is a thin Symfony integration layer over phpCAS. The real "buy" here is phpCAS (mature, Apereo-backed); this package is the glue. Decision: adopt phpCAS as the transport and treat this bundle as optional glue for Symfony services — never as the reason to adopt CAS.
• Roadmap sizing for SSO: Gives engineering a known reference implementation for CAS login/logout flows (redirects, ticket validation, attribute mapping) — useful for estimation even if you don't ship this exact package.
• Auth architecture for mixed-stack portfolios: Relevant only if part of your platform runs Symfony 5.4+. For a Laravel-first stack it supports a "no" decision with evidence, not a "yes."
• Procurement/licensing gate: License is reported as NOASSERTION — an unresolved licensing posture. That is a product-level decision (legal sign-off required before shipping), not an engineering detail.
• Maintenance-risk triage: 4 stars, 0 dependents, single-institution maintainer. Supports a decision to absorb/fork rather than depend on upstream responsiveness.

When to Consider This Package

Consider it when all of the following hold:

• Your service is Symfony 5.4+ (this is a bundle; it does not install into Laravel).
• The customer's IdP speaks CAS — not SAML, not OIDC. If it's SAML/OIDC, use a first-party-maintained package instead; CAS is the legacy-adjacent protocol in most higher-ed estates, though still widespread.
• You need only authentication + basic attribute retrieval, not complex authorization, MFA orchestration, or session policy engines.
• You can accept self-support risk: 0 dependents means no ecosystem validation, thin issue traffic, and an upstream that is effectively one university's internal tool published openly.
• Legal can clear the NOASSERTION license or you isolate it behind your own auth interface.
• Your team is comfortable pinning to phpCAS and patching the bundle if needed.

Look elsewhere when:

• Your app is Laravel. There is no Laravel service provider here. Retrofitting a Symfony bundle into Laravel is not a wrapper job; budget a port or pick a Laravel-native CAS/SAML package.
• You need OIDC/SAML or a commercial IdP relationship.
• You require a supported vendor for compliance (SOC 2, contractual SLAs) — this has neither.
• You expect multi-tenant IdP management, attribute-driven provisioning, or admin UI. This is a client, not a product.

How to Pitch It (Stakeholders)

To executives: This is a small, low-risk protocol adapter, not a platform bet. It lets us answer CAS SSO requirements from university and research customers without custom auth work. But it is unproven in the market — 4 stars, zero downstream projects, and an unclear license. Recommend it only as a scoped, single-integration dependency, gated on legal review, and only for Symfony-based services. Do not let it enter the platform's critical path.

To engineering: Symfony 5.4+ bundle wrapping Apereo phpCAS. You get CAS login/logout and attribute retrieval with minimal code. It is not a Laravel package — if our target is Laravel, we should use phpCAS directly or a Laravel-native alternative and treat this repo as a design reference. Expect to own the fork: vendor it, pin phpCAS, and wrap it behind our own authentication interface so swapping it out is a one-file change.

To the deal team / customer-facing: We can commit to CAS SSO on Symfony services. Timeline is one integration, not a build. We should not promise roadmap features that assume active upstream maintenance.

Recommendation: Conditional adopt — Symfony only, behind an internal auth abstraction, with a license review as a hard gate and an explicit exit plan (direct phpCAS) if upstream stalls. Score reflects ecosystem signals (low opportunity, no dependents) rather than code quality, so treat it as a component, not a dependency strategy.