Filament Sso Client Laravel Package

Technical Evaluation

Architecture fit

• Provides a Filament v3 panel plugin that wraps jeffersongoncalves/laravel-sso-client (1.1+) and hooks three surfaces of the auth lifecycle: the login page (SSO button, SSO-only mode, or forced redirect), the user menu (federated logout), and panel request handling (Single Logout enforcement middleware).
• This is a thin adapter, not a standalone SSO implementation. All protocol work (SAML/OIDC handshakes, token validation, session mapping) lives in the upstream client, so the plugin's risk profile is largely inherited from that dependency.
• Fits the common shape of a Laravel admin/monolith with one or a few Filament panels where workforce identity is centralized in an enterprise IdP. It is not positioned for per-tenant or consumer-facing multi-IdP SSO without extension work.

Integration feasibility

• Installation is a standard Composer add plus plugin registration in the relevant PanelProvider, with configuration published for the upstream client (IdP metadata, entity ID, ACS/logout URLs, signing certificates).
• The real effort is not code; it is IdP coordination: SP registration, callback URL allow-listing, attribute/claim agreement, and logout endpoint configuration on the IdP side. That typically dominates the timeline.
• Forced-redirect and SSO-only modes are one-line configuration flips but have outsized blast radius (see risk below).

Technical risk

• Maturity: this is a 1.0.0 first release. No public track record of production use, and the upstream client is itself young (1.1+). Expect API churn on both layers.
• Concentration: both packages appear to be maintained by the same individual. Bus factor and support depth are the primary concerns; vendor continuity should be treated as an explicit assumption to validate.
• Protocol ambiguity: the release notes say "SSO" without naming SAML 2.0 vs OIDC. This materially changes IdP configuration, testing, and failure analysis and must be confirmed before commitment.
• Lockout risk: SSO-only / forced-redirect modes can strand administrators if the IdP, certificates, or metadata drift. A documented break-glass local admin path is mandatory.
• Per-request cost: SLO enforcement on panel requests implies a check on each request (session/back-channel state). The plugin does not state whether this is a cache-backed lookup or a remote call; this needs verification before high-traffic deployment.
• Auth surface: no stated coverage for JIT user provisioning, attribute/role mapping, MFA policy passthrough, or IdP-initiated flows — all commonly required in enterprise rollouts.

Key questions

1. Which protocols are supported (SAML 2.0, OIDC, both), and which IdPs are known-tested (Entra ID, Okta, Google, Keycloak, ADFS)?
2. What is the supported version matrix for PHP, Laravel, and Filament, and is a Filament v4 path planned?
3. Does SLO enforcement make a remote call per request, or use cached/local session state? What is the measured overhead?
4. How are users provisioned and mapped (JIT creation, attribute mapping, role/group mapping), and what happens to local users on first SSO login?
5. Is there a documented break-glass procedure, and can local auth remain enabled alongside SSO?
6. What test coverage, CI, static analysis, and security disclosure process exist for both the plugin and the upstream client?
7. License terms, release cadence, and stated backwards-compatibility policy for pre-1.0 upstream changes?

Integration Approach

Stack fit

• Target: Laravel 10/11 applications running Filament v3 admin panels, PHP 8.1+. Clean fit for a single-tenant internal back office where the IdP is the system of record for workforce identity.
• Poor fit, out of the box, for multi-tenant SaaS admin panels needing per-tenant IdPs, or for B2C/consumer login.

Migration path

• Adopt incrementally: install alongside existing local auth, enable the SSO button first (least invasive), then SSO-only for a pilot panel, and only then forced redirect for production panels.
• Keep at least one local break-glass administrator account outside the SSO path for the entire migration and permanently thereafter.
• Pin exact versions of both the plugin and laravel-sso-client in composer.json. Given the 1.1+ constraint and pre-1.0 upstream, treat any minor bump as potentially breaking until proven otherwise.

Compatibility

• Filament v3 only. If a Filament v4 upgrade is on the roadmap within the next two quarters, plan for a gap or a fork.
• The upstream client constraint is a floating floor (1.1+), which means resolution can silently pull behavior changes; lock it.
• Verify Laravel and PHP support explicitly rather than assuming; the release notes omit the matrix.

Sequencing

1. Confirm protocol and collect IdP metadata; register the SP (ACS and SLO URLs) with the identity team.
2. Security review of both packages (dependency audit, license check, code read of the middleware and login override).
3. Staging install; configure guard/provider, attribute and role mapping; keep local auth enabled.
4. Test matrix: SP-initiated login, IdP-initiated login, federated logout from the user menu, back-channel SLO enforcement, forced-redirect behavior, IdP-unreachable scenario, expired-certificate scenario.
5. Document break-glass runbook and on-call escalation; add login-failure and certificate-expiry alerting.
6. Canary with a small admin cohort on one panel; monitor failure rates and support tickets for one to two weeks.
7. Roll out per panel; only then consider SSO-only/forced-redirect for the highest-privilege panels, if at all.

Operational Impact

Maintenance

• Small dependency surface (a login page override, a menu action, a middleware) means low ongoing code maintenance, but also low upstream momentum. Budget a named internal owner for auth and roughly a few days per quarter to track releases, refresh IdP certificates, and re-run the test matrix.
• Fork-and-own is a realistic contingency and is tractable given the thin adapter design; keep a fork ready if upstream stalls or introduces a breaking change.

Support

• Expect GitHub-issues-level support with no SLA. Escalation is internal. Contractual or 24/7 support should not be assumed.
• Enterprise IdP vendors will disclaim responsibility for third-party SP behavior; the boundary between "IdP problem" and "plugin problem" will need internal triage capability.

Scaling

• Login-path cost is bounded by the SSO handshake and is not a steady-state concern.
• The SLO enforcement middleware is the scaling question: if it performs a remote or uncached session lookup per panel request, it becomes a per-request latency and IdP-availability dependency across the entire admin surface. Measure before wide rollout; cache metadata and signing certs; honor assertion validity windows.
• Back-channel logout volume scales with session count, not request count — generally modest.

Failure modes

• IdP outage or network partition: all SSO admins locked out. Mitigation: break-glass account, documented runbook.
• Certificate or metadata expiry: sudden, total login failure across all users. Mitigation: expiry alerting at 30/14/7 days, metadata refresh automation.
• Misconfigured forced redirect: redirect loop or redirect to an unregistered callback, producing a hard lockout. Mitigation: staged enablement, pilot cohort.
• Clock skew / assertion window drift: intermittent, hard-to-reproduce login failures. Mitigation: NTP hygiene, tolerance monitoring.
• Upstream breaking change on composer update: silent production breakage. Mitigation: version pinning, staged dependency updates, CI smoke tests of the login flow.
• Role/attribute mapping drift on the IdP side: users authenticate but lose panel access, presenting as an authorization bug rather than an IdP change. Mitigation: mapping contract documented and jointly owned with the identity team.

Ramp-up

• A Filament-fluent developer can wire the plugin in well under a day; the configuration surface is small.
• The dominant cost is organizational: IdP coordination, security review, and test-matrix execution. Plan roughly one to two sprints end-to-end including the identity team's availability, with the majority of that time outside the codebase.
• Recommend a security review before production given the first-release status and the fact that this code sits directly on the authentication path.