Raven Bundle Laravel Package

Product Decisions This Supports

• Institutional SSO scoping ("log in with university account"): Informs whether Cambridge Raven / Ucam WebAuth is a launch-blocking requirement for a target segment (Cambridge and UK higher-education clients) or a post-MVP nice-to-have. The package is only relevant if a real customer demands Raven credentials specifically.
• Build vs. buy on authentication: Serves as the "buy" data point in an auth analysis — and a weak one: 1 star, 0 dependents, single maintainer, Symfony 2-only (EOL since 2018). Its genuine value is as a free specification of what wiring Raven requires, which makes the "build" estimate credible (days, not weeks).
• Framework/platform commitment: Forces an explicit call on Symfony vs. Laravel. This is a Symfony bundle and cannot be installed or wired into a Laravel app through config/auth.php. Choosing it implies committing to a legacy Symfony generation and porting it; staying on Laravel means reimplementing the protocol in a custom guard.
• Epic sizing for education-sector roadmap items: Exposes the hidden work the package does not solve — attribute release, entitlement/ptags group mapping, kid key rotation, replay-protection storage, SSO logout — which is usually the bulk of the actual epic.
• Risk register input: Supports a standing decision not to take a maintenance dependency on an unmaintained, single-maintainer, zero-adoption package in the authentication code path, and to record it as no-SLA / permanently in-house if forked.
• Vendor and protocol discovery: Useful as a conversation artifact with Cambridge-affiliated clients to confirm which protocol they actually expect — Raven direct, or Shibboleth/ADS fronting it. Raven-direct is increasingly the wrong target.
• Metadata-trust hygiene: The package listing's own description text describes Sentry error tracking while the code implements authentication. Any decision that treats package metadata as purchase/procurement signal without reading the source is unreliable — verify before it enters a roadmap.

When to Consider This Package

Consider it — or more accurately, consider reading it — only when all of the following hold:

• The customer is Cambridge University or an affiliated institution that explicitly requires Raven / Ucam WebAuth, and will not accept Shibboleth/ADS or an OIDC bridge.
• The target application is a legacy Symfony 2.x app you are maintaining, not a new build.
• You are comfortable treating the bundle as a read-only reference implementation to copy or port, not a long-term dependency.
• The auth flow needed is the simple case: redirect to Raven, validate the WLS-Response, extract CRSid, map to a local user, done.
• You have an owner for protocol knowledge — the package ships no usable documentation or community support.

Look elsewhere when:

• You are on Laravel (the likely case). There is no Laravel integration. Budget a custom Guard or Socialite-style provider and reimplement WLS-Response signature verification, issue freshness, kid handling, and params replay protection yourself — or use a maintained UCam WebAuth library as the protocol layer.
• You are on modern Symfony (5/6/7). The bundle targets an EOL framework generation; expect to rewrite the DI definitions and the security listener/authenticator.
• You need anything beyond basic login: group/entitlement mapping, single logout, multi-institution federation, MFA policy, or audit logging are not solved here.
• You want a supported dependency. Prefer Shibboleth SP, SimpleSAMLphp, onelogin/php-saml, or an OIDC broker, behind a thin adapter you own.
• The institution has moved to Shibboleth-backed "University Login." Raven-direct is the wrong target.
• The need is generic SSO rather than Cambridge-specific. OIDC/SAML against a modern IdP is cheaper and safer.

How to Pitch It (Stakeholders)

To executives: This is a small, unmaintained Symfony 2 plugin for Cambridge's legacy Raven login, not a product decision in itself. Its value is as a signal that one of our target segments authenticates through institutional SSO, and as a free specification that lets us price that work accurately. The recommendation is not to adopt it: a one-star, zero-dependent, end-of-life-framework dependency sitting in our most security-sensitive code path, with no vendor to call when it breaks. Instead, treat it as a reference, budget a short engineering spike (days) to implement Raven/Shibboleth SSO natively or via a supported service-provider stack, and confirm with the customer which protocol they actually require before it enters the roadmap. Cost of the build path: days. Cost of the dependency: an unpatched auth library we cannot get support for, owned by us forever.

To engineering: Read it, don't ship it. The reusable content is the WLS-Response validation logic and the security-listener wiring — both portable into a Laravel guard or a modern Symfony authenticator inside a sprint. Any implementation must include independent signature and WLS-Response verification, issue timestamp tolerance with NTP discipline, url/fail code checks, a shared (Redis/DB) replay-protection store for params, and an explicit decision on how CRSid and ptags map to our user and role model. Design for the failure modes now: IdP outage and redirect loops, kid rotation causing total login outage without a key-refresh path, clock skew on issue, ptags changes not re-evaluated on live sessions, and SSO logout not propagated. The dominant effort is the framework gap and the protocol hardening — not the plugin scaffolding.