Raven Bundle Laravel Package

Technical Evaluation

Architecture fit: There is no direct fit. misd/raven-bundle is a Symfony 2 bundle, not a Laravel package: it registers through AppKernel, wires services into Symfony's DI container, and plugs into the Security component's firewall and AuthenticationProviderInterface. Laravel exposes no equivalent extension surface — no bundles, and a guard/provider model that is structurally different. The bundle cannot be installed into config/auth.php or resolved by a Laravel service provider. Its only leverage for a Laravel team is as a reference implementation of the UCam WebAuth (Raven/WAA) protocol — specifically the WLS redirect construction (ver, url, date, desc, skey) and the WLS-Response validation path (signature check, issue freshness window, params replay protection, kid key selection).

Documentation integrity flag: The supplied description.md describes a Sentry/Raven PHP error-tracking integration, which contradicts the package's actual identity and every other source in this set. Either the metadata is mismatched or the repository was repurposed. A TPM should treat the README as untrustworthy and require source-level review before any build-vs-buy call — and should log the metadata discrepancy as evidence that this package has no maintained documentation contract.

Integration feasibility: Low as an install, moderate as a port. Two viable paths: (a) fork and extract the response-validation logic into a framework-agnostic class, wrap it in a custom Laravel Guard or Socialite-style provider; (b) discard it and adopt a maintained SAML / UCam WebAuth library (SimpleSAMLphp, onelogin/php-saml, LightSAML) behind a custom guard. Path (b) is usually cheaper than reviving PHP 5-era code.

Technical risk: High, and concentrated on the most security-sensitive surface in the product. One star, zero dependents, no visible CI on current PHP, single-organisation maintainer, no security advisories. Signature verification and replay protection are precisely the code paths that rot silently when unpatched. Composer will refuse resolution against PHP 8.x and Laravel 9+; forcing --ignore-platform-reqs on auth code is not an acceptable mitigation.

Key questions:

• Is the requirement genuinely Cambridge Raven, or a general "institutional SSO" need better served by OIDC/SAML against a modern IdP? Raven is increasingly fronted by Shibboleth/ADS.
• Is the target application actually Laravel, or is this a legacy Symfony system mislabelled in the request?
• Do we need ptags/entitlement-to-role mapping, single logout, and kid rotation — and who owns key distribution?
• Is there an institutional mandate or existing IdP relationship that constrains the protocol choice?
• Is Cambridge affiliation a launch-blocking customer requirement, or a speculative feature?

Integration Approach

Stack fit: None out of the box. Symfony 2.x only, and only if pinned to that generation's component versions. For Laravel, plan for an owned adapter, not a dependency.

Migration path (recommended sequencing):

1. Protocol recon spike (1–2 days). Confirm with the customer/institution which protocol is actually required (Raven direct vs Shibboleth/ADS vs OIDC bridge). Stand up the test WLS endpoint, capture a real WLS-Response, and document the required validation rules: ver, issue tolerance, kid, signature algorithm, params replay store.
2. Build-vs-adopt decision. Default to a maintained SAML/WebAuth library as the protocol layer. Port the bundle's logic only if review shows it is correct and non-trivial relative to available libraries. Gate all downstream work on this decision.
3. Laravel adapter. Two routes (/auth/raven redirect-out, callback redirect-in) plus a custom guard or Socialite provider delegating to the protocol layer. Map principal → local user, ptags → roles, with a decision on auto-provisioning vs pre-registration.
4. Verification. Fixture-based automated tests plus a live test-IdP round trip, including negative cases: expired issue, tampered sig, replayed params, unknown kid.

Compatibility: Treat the bundle as read-only source, not a Composer dependency. Extract the validation class; do not inherit its service definitions or PHP version constraints.

Sequencing: Do not let the team start by forking. Forking first locks in PHP 5 idioms and an unaudited validation path before the protocol requirement is even confirmed — the dominant effort is the framework gap and the protocol decision, not the ~150 lines of WLS handling.

Operational Impact

Maintenance: Effectively zero upstream. Once forked, the code is permanently in-house: protocol drift, PHP upgrades, and security patches become internal backlog items with no external fallback. Budget it as owned code from day one.

Support: No community (1 star, 0 dependents), no visible issue triage, no advisories, single-maintainer development shop rather than a maintained OSS project. Escalation ceiling is reading the source. Record as a single-maintainer, no-SLA dependency in the risk register even if it is only used as a reference — copy-paste inherits its assumptions.

Scaling: Authentication volume is negligible; throughput is not the concern. Real constraints are (a) the params replay-protection store, which must be shared across app instances (Redis/DB), not in-process; (b) kid key caching and refresh; (c) session/cookie handling across the WLS redirect, including HTTPS-only callback URLs.

Failure modes to design for:

• IdP/WLS unreachable or slow → redirect loops and login timeouts; needs circuit-breaking and a clear error page.
• Clock skew on issue → intermittent validation failures; enforce NTP and an explicit tolerance window.
• kid rotation without local key refresh → total login outage; needs a refresh path and alerting.
• CRSid case/normalisation mismatch → duplicate or orphaned user records.
• ptags/entitlement changes not re-evaluated on existing sessions → stale authorisation.
• No SSO logout propagated → users remain authenticated after central logout.

Ramp-up: Small codebase, non-trivial domain. Onboarding cost sits in Raven/UCam WebAuth specifics and the institutional IdP relationship, not in reading the bundle — and the bundle supplies no usable documentation, as the contradictory README demonstrates. Plan for a single engineer to own protocol knowledge, and budget the work as days of spike plus an owned adapter, not weeks of revival. Net recommendation: do not adopt as a dependency; use as a protocol reference and build a thin, owned Laravel guard against a maintained SAML/WebAuth library.