Laravel Filament Sso Laravel Package

Technical Evaluation

Architecture fit

• The package is a thin Filament adapter over postiefs/laravel-sso ^1.0: it supplies a plugin entry point (->plugin(SsoPlugin::make())), UI surface (Microsoft 365 button under the login form), redirect/login policy (redirectLogin(), allowLocalLogin()), session-rule middleware on panel requests, and logout routing. Authentication logic stays in the base package, so our domain code and panel resources remain untouched.
• The deliberate trust boundary is the most important design decision for us: identity is federated, entitlement is local. Portal roles are never applied; authorisation runs through our own roles (e.g. Spatie). That is the correct separation for us, but it makes user provisioning and role mapping our problem — and the release notes do not describe how users are created or matched on first callback.
• Session rules running on every panel request, including Livewire updates, means the portal participates in the hot path of normal UI interaction, not just at sign-in.

Integration feasibility

• Install footprint is small: one Composer dependency plus one line in the panel provider. A single-panel pilot in staging is realistically 0.5–1 day of engineering plus verification time; the real cost is the portal test tenant and outage testing, not the code.
• Multi-panel apps need per-panel plugin registration and clarity on the stated behaviour that users "land on the default panel" after callback — that will be wrong for some of our panels.

Technical risk

• Version claims are unverifiable from the notes. Laravel 13 and Filament 5 are not generally available; if the Composer constraints are written loosely to accommodate them, an unrelated composer update could pull a breaking major. Pin versions and inspect the constraint set before adoption.
• Whole-panel availability now depends on the portal. Every panel request and every Livewire update passes through the portal's session rules, so portal latency and downtime become panel latency and downtime. The only stated mitigation is ?local=1 on the login URL — an undocumented-in-notes escape hatch that is simultaneously a security-review item and an incident-response item.
• Middleware collision surface. A browser guard added to every page, plus session checks on the Livewire update route, must be validated against existing middleware ordering, CSP/security headers, and custom login pages that may bypass the plugin's button injection.
• Auth code is hard to test. Redirect loops, callback state handling, logout-to-launchpad behaviour, and session mismatch between the portal session and the Laravel session are exactly the failure classes that only appear under real IdP conditions.

Key questions

1. How are users provisioned or matched on first callback (UPN/email), and what happens when no local user or role exists — hard fail, JIT create, or authenticated-but-403?
2. Are the Laravel 13 / Filament 5 claims backed by a CI matrix, or are they aspirational constraints? What are the exact Composer ranges?
3. Is ?local=1 a permanent, always-available bypass? Can it be disabled per environment, restricted by IP, or at minimum alerted on? Who is allowed to use it?
4. Does the base postiefs/laravel-sso package add tables, migrations, cache keys, or its own HTTP client/timeouts, and is there a circuit breaker or session-check cache to protect panel throughput?
5. What is the vendor's support model — SLA, issue tracker responsiveness, changelog discipline, security disclosure process? The notes point only at a docs folder.
6. For multi-panel estates, can the post-callback landing panel be configured, and does the plugin support panels with distinct login pages or guards?

Note: this assessment is derived solely from the v1.0.0 release notes; no package data, source review, or pilot results were available.

Integration Approach

Stack fit

• Confirm the matrix explicitly: Laravel 11/12 (13 pending GA), Filament 3/4 (5 pending GA), matching Livewire and PHP versions, and which postiefs/laravel-sso 1.x releases are supported. Treat any "5" or "13" support as a forward-compatibility claim to be tested, not assumed.
• Verify the base package's transitive footprint (HTTP client, cache store, session driver assumptions) against our platform standards before it reaches a shared environment.

Migration path

• No data migration is implied, because portal roles are not applied to users. The migration that is required is an identity mapping exercise: audit existing panel users against portal identities (email/UPN) and confirm each will resolve to a local account with the correct roles.
• Roll out behind configuration per panel, starting with one non-critical internal panel. Keep local login enabled for the pilot. Do not enable redirectLogin() estate-wide until the mapping audit and the outage drill both pass.

Compatibility checks before build

• Filament panel middleware ordering, existing auth guards, and the Livewire update route.
• Custom or overridden login pages — the Microsoft 365 button is rendered by the plugin, so a bespoke login view may not show it.
• Logout listeners, Spatie permission cache behaviour, and any code that inspects the authenticated session shape.
• Coexistence with existing SSO, MFA, or password-reset flows that may still be reachable.

Sequencing

1. Dependency and constraint audit; pin both packages; capture the supported matrix in our own docs.
2. Provision a portal staging/test tenant and run an outage drill (portal down → ?local=1 path, then portal restored).
3. Single-panel pilot with local login permitted; instrument login success rate and panel request latency.
4. Validate provisioning and role mapping against real users, including the "authenticated but no role" case.
5. Enable redirectLogin() panel by panel; document and restrict the local fallback.
6. Helpdesk enablement and runbook publication.
7. Schedule a Filament/Laravel major-upgrade review — this package's cadence is now part of our framework upgrade path.

Operational Impact

Maintenance

• Two packages to track (laravel-sso and the Filament plugin) plus the Filament major cadence, which moves faster than Laravel's. Budget a recurring line item for version-pin maintenance and quarterly compatibility review rather than treating this as a one-off install.
• The vendor appears small and the package is early (v1.0.0, docs-in-repo). Assume we will own integration glue, and possibly upstream patches, rather than pure consumption.

Support

• No SLA or support tier is stated in the release notes. Before adoption, confirm the issue tracker's responsiveness and whether there is a security disclosure channel.
• Expect a new helpdesk workload: "I can't sign in" now has a federated cause. Publish a runbook covering portal outage, the ?local=1 route, and the authenticated-but-unauthorised case, and brief the service desk before the first panel flips.

Scaling

• The portal becomes an authentication chokepoint sized by panel traffic, not by sign-in volume, because session rules run on every request including Livewire updates. Livewire polling can multiply request volume substantially in a data-heavy panel — measure portal round-trip latency and confirm whether session checks are cached or batched. Add a latency budget to the pilot's acceptance criteria.
• For multi-panel estates, plan for the portal to serve all of them; capacity and rate-limit behaviour of the portal is now a shared dependency across teams.

Failure modes

• Portal unavailable: all panel authentication is blocked. Only mitigation is the local-login URL flag — which must be documented, monitored, and time-boxed, not left as a permanent open door.
• Silent bypass: ?local=1 usage in production should raise an alert; unreviewed use is a standing audit finding.
• Portal reachable, roles missing: users authenticate successfully then hit 403s, which reads as an application bug and generates support load. Detect and log this distinctly from auth failure.
• Redirect loops / wrong landing panel: post-callback landing on the default panel may misroute multi-panel users; logout returning to the launchpad changes existing user expectations and must be communicated.
• Session desynchronisation: portal session expiry mid-Livewire-interaction produces confusing partial failures; confirm the plugin surfaces a clean re-auth redirect.

Ramp-up

• Engineering: ~1 sprint for the pilot including the outage drill and role-mapping validation; allow extra for any custom login page rework. Understanding the every-request middleware model and the local fallback is mandatory, not optional, knowledge.
• Operations/helpdesk: half-day enablement on the new sign-in topology and escalation path.
• Security review: one pass focused on the ?local=1 bypass, the browser guard's interaction with our headers/CSP, and the trust boundary between portal identity and local authorisation.