Saml2 Okta Laravel Package

Technical Evaluation

Architecture fit: filamentSaml2Okta is a Filament panel plugin that layers SAML 2.0 Service Provider (SP) authentication against Okta as the Identity Provider (IdP). Architecturally it is a thin auth adapter: it registers a Filament login route/provider, delegates protocol handling to a PHP SAML toolkit, and hands a resolved user back to Laravel's guard/session. That is the correct shape for the problem — SSO should not touch domain logic, and Filament's panel/provider abstraction is the right seam. It fits any Laravel app where a Filament admin panel needs enterprise-mandated SSO and where Okta is the sanctioned IdP.

Integration feasibility: Moderate. The expected path is composer require, publish config, populate SP entity ID / ACS URL / IdP metadata (or metadata URL), register an Okta SAML app, map attribute statements (email, firstName, lastName, groups), and enable just-in-time user provisioning or attribute-based matching to existing users. Most effort is on the Okta side and on identity-mapping decisions, not on PHP. Two non-obvious tasks drive the estimate: deciding the local user-matching key (email vs. Okta NameID/subject) and deciding whether group claims drive Filament role/permission assignment.

Technical risk:

• Ecosystem coupling. The plugin's real risk surface is inherited, not authored: the underlying SAML toolkit (e.g. onelogin/php-saml), Filament major version (v3 vs v4), and Laravel major. Version 2.x of the plugin implies a prior breaking line — v1→v2 upgrade notes are not evidenced here, so treat the v1/v2 boundary as unverified.
• Bus factor. Single-maintainer GitHub project (Johnrivera7). Recent releases are documentation-only (SECURITY.md, README badge, changelog), which is a healthy hygiene signal but not evidence of active feature or security-patch cadence. Low release velocity is a supply-chain concern for an auth-critical dependency.
• Security surface. SAML SP implementations are high-value targets: signature validation, assertion replay windows, audience/recipient checks, and XML canonicalization. These must be verified in the inherited toolkit, not assumed from this package.
• Quality gating (positive). The v2.0.2 addition of a Plumb score badge and a Plumb-triggered SECURITY.md indicates automated package-health checks and a defined private vulnerability-reporting channel — both are meaningful for internal security review and procurement.

Key questions:

1. Does v2.0.2 introduce any functional change? Evidence says no — SECURITY.md, README badge, changelog only. Confirm via diff before treating it as a drop-in patch on 2.0.1.
2. Which SAML toolkit and version range does the composer manifest pin, and is that range currently patched?
3. Supported matrix: Filament 3.x and/or 4.x, Laravel 10/11/12, PHP 8.1–8.4?
4. Is IdP-initiated SSO supported, or SP-initiated only? Okta app templates default to IdP-initiated for many users.
5. Does it support SLO (single logout), assertion encryption, and signed AuthnRequests?
6. JIT provisioning: does it create users, and can it sync Okta group claims into Filament roles/permissions?
7. Multi-panel / multi-guard: can SSO be scoped to one panel while a password guard remains for break-glass admins?
8. SECURITY.md exists — is there a published response SLA, and is there a security contact with a track record?

Integration Approach

Stack fit: Assumes a conventional Laravel + Filament stack (Blade/Livewire admin surface, Eloquent users, standard session guard). No mismatch expected — the plugin targets the panel's own login flow rather than wrapping the whole app. It does not replace API auth; if the same app exposes machine or mobile clients, plan for token-based auth as a separate track.

Migration path:

1. Pin to 2.0.x and read the v1→v2 changelog before upgrading anything. If already on v2.0.1, v2.0.2 is a documentation-only bump and is safe to take in a routine dependency refresh.
2. Introduce SSO alongside existing password auth. Do not remove the password guard in the same release.
3. Roll out to a pilot cohort (internal admins) via per-user or per-panel enablement before broad enforcement.
4. Deprecate password login only after a full Okta-side break-glass account and recovery runbook exist.

Compatibility: Validate against the exact Filament major in use — Filament panel/auth APIs changed across 3→4, and a plugin pinned to one major will not silently work on the other. Verify PHP and Laravel version constraints against the platform's support window. Check tenant isolation if the app is multi-tenant: SAML config and IdP metadata may need to be per-tenant, which is a common gap in single-tenant-oriented plugins.

Sequencing:

• Spike (2–3 days): sandbox app + Okta developer tenant, prove login, attribute mapping, and JIT against a real Filament panel.
• Design: decide user-matching key, group→role mapping, and fallback auth policy.
• Build: config, certificates, metadata retrieval, and env-per-environment IdP apps (dev/stage/prod must be distinct Okta apps).
• Harden: test expired-cert, clock-skew, and malformed-assertion paths before production.
• Cutover: pilot → enforce → decommission password fallback (weeks, not days).

Operational Impact

Maintenance: Low code churn, but the burden shifts to configuration and certificate lifecycle, which is recurring and unbudgeted in most estimates. Pin the version, subscribe to GitHub releases, and track the pinned SAML toolkit's advisories independently of this package. The documentation-only v2.0.2 is a routine bump; expect no operational change and no regression risk beyond the version string.

Support: Community-supported, single maintainer, no commercial SLA. For enterprise use, that argues for either (a) a maintained fork or (b) treating the SAML protocol path as internally owned and reviewable. The new SECURITY.md gives a private disclosure channel — a prerequisite for most security reviews and a genuine procurement unblock, even though it changes no code.

Scaling: SAML is login-path only; steady-state cost is a session lookup, so throughput scaling is a non-issue. Watch two things instead: IdP metadata/certificate fetching on the login hot path (cache it, and never let a metadata URL outage block all logins), and JIT provisioning bursts or group-sync volume if group claims are large — Okta caps assertion/attribute size, and large group lists get truncated silently.

Failure modes:

• Expired or rotated Okta signing certificate — the classic mass-lockout; needs a rotation runbook and a documented dual-cert overlap window.
• Clock skew outside the assertion validity window — enforce NTP on app hosts.
• Stale cached IdP metadata — a cached copy can outlive reality; provide a manual cache-bust command.
• Attribute drift — an Okta admin renames a claim or changes NameID format and logins fail or, worse, users are mismatched.
• Break-glass gap — if SSO is the only path and Okta is down, admins are locked out of the panel; retain one local credential path with tight controls.
• Major-version breakage — v2 signals a previous breaking line; assume future majors will require migration work.

Ramp-up: A Laravel developer familiar with Filament needs roughly 1–3 days to a working staging integration, with the majority of that spent in Okta configuration and identity-mapping decisions rather than PHP. Add meaningful time for the security review (assertion validation, cert handling, disclosure policy), the pilot, and the break-glass runbook — realistically one to two weeks end-to-end for a production rollout by a small team. Okta admin access and coordination with the identity team should be secured before the sprint starts; that dependency, not the code, is the usual schedule risk.