Casauth Bundle Laravel Package

Product Decisions This Supports

• Enterprise SSO / education-market entry. CAS (Central Authentication Service) is the default SSO for a large share of universities, colleges, hospitals, and research institutions. If roadmap includes selling into EDU or research, CAS support is frequently a hard procurement requirement, not a nice-to-have — this package is the cheapest way to answer that checkbox.
• Authentication roadmap sequencing. Supports a decision to ship SAML/OIDC first for the commercial mid-market and add CAS as a segmented integration for EDU, rather than treating CAS as a first-class protocol investment.
• Build vs. buy. This is a thin Symfony security bundle over Apereo phpCAS — the protocol work is already "bought" upstream. The real decision is whether to adopt a third-party wrapper (fast) or write ~200 lines of glue ourselves (safer). Either way, do not budget for building CAS ticket validation in-house.
• Use cases it fits: student/staff-facing portals, internal dashboards, research tooling, and intranet apps already deployed on Symfony 5.4+ that need to sit behind a campus IdP.
• Stack fit decision. Despite being surfaced as a Laravel/PHP package, this is a Symfony bundle, not Laravel. It informs a "do we standardize on Laravel service containers and find a native CAS adapter, or run a small Symfony component for SSO" decision.
• Maintenance/supply-chain triage. 2 stars, 0 dependents, a single maintainer, and a repo/vendor rename (scar63/CasAuthBundle → yraiso/casauth-bundle) are themselves a finding: it argues for vendoring and an exit plan, and against any deep dependency.

When to Consider This Package

Consider it when:

• Your application is Symfony 5.4 or later and you need CAS quickly. If your stack is Laravel, this is a mismatch — look at a Laravel-native phpCAS wrapper or a small custom guard instead.
• You have named EDU/research prospects or contracts whose IdP only speaks CAS.
• You need only basic CAS service-ticket validation, plus logout/SLO and simple attribute mapping — i.e., the surface you can realistically audit in a thin wrapper.
• You are willing to pin the version, vendor or fork it into your monorepo, and assign a named owner. At this size, adopting it is closer to "copying a snippet" than "taking a dependency."
• You want to abstract auth behind an internal interface so CAS is one adapter among SAML/OIDC and can be swapped per-tenant.

Look elsewhere when:

• You need SAML 2.0, OIDC, or WS-Fed — use a mainstream, well-maintained integration instead; CAS is a narrow, aging protocol outside EDU.
• Requirements include vendor support, an SLA, SOC 2 evidence, or third-party pen-test reports — an MIT bundle with 2 stars and no dependents will not pass procurement review.
• You need MFA/step-up, per-tenant attribute mapping, SCIM provisioning, or session policy control beyond what a thin wrapper provides.
• You are on a Symfony version above the stated floor with no confirmed compatibility, or already on a framework where a first-party auth system covers you.
• Your threat model treats an unmaintained single-maintainer auth dependency as unacceptable — auth code is the worst place to accept that risk.

How to Pitch It (Stakeholders)

Executives (one paragraph): CAS is how a large portion of universities and research institutions run single sign-on. Supporting it is a market-access enabler for our EDU/research segment and removes a recurring procurement blocker, at essentially zero license cost (MIT) and low engineering effort. The trade-off is maintenance risk: this is a small, low-adoption, single-maintainer wrapper. We recommend adopting it only if a named deal or segment justifies it, and de-risking by vendoring the code under our own control with a documented exit path — not treating it as a strategic platform bet.

Engineering (summary): It's a Symfony security bundle wrapping Apereo phpCAS — firewall factory, ticket validation, logout. Expect roughly 2–5 days to integrate, including firewall config, SLO handling, and attribute mapping, plus a test CAS server. Known risks: 2 stars, 0 dependents, single maintainer, vendor rename, Symfony 5.4 floor. Mitigations: pin to a commit, vendor the source into our repo, wrap it behind an internal AuthProvider interface, add integration tests, and keep a SAML/OIDC fallback so swapping out is a config change rather than a rewrite. Treat it as owned glue code, not a supported dependency.