Laravel Samlidp Laravel Package

Technical Evaluation

What the package is. codegreencreative/laravel-samlidp turns a Laravel application into a SAML 2.0 Identity Provider — the app authenticates users and asserts their identity to third-party Service Providers (customer SaaS tools, internal dashboards, partner portals). It is not a Service Provider package; if our need is "let users log in with Okta/Entra," this is the wrong side of the protocol and should be disqualified early.

Architecture fit. Good fit when the Laravel app is the system of record for user identity and we need to federate outward to SPs we don't control. The package is Laravel-idiomatic — publishable config, routes/controllers for metadata, SSO and SLO endpoints, and a service-provider registry — so it slots into existing middleware, auth guards, and event patterns rather than requiring a parallel auth stack. Poor fit if we need fine-grained, per-tenant protocol customization, non-standard bindings, or certified/audited federation behavior.

Delta in v5.4.0. The release is a single change: a community PR adding Laravel 13.x compatibility, shipped as a minor version bump (5.3.2 → 5.4.0). No new features, no deprecations, no breaking API changes, no protocol-layer changes. Read it as a maintenance signal, not a capability change: the package is keeping pace with Laravel's annual major cadence. The practical consequence is that the v5.3.x line is now the "old framework" line, and staying on it accrues framework-upgrade debt rather than package-upgrade debt.

Integration feasibility. Low-to-moderate. Installation and configuration are a few hours; a working end-to-end SSO flow against one real SP is a few days; a production-grade, multi-SP, cert-rotating deployment is measured in weeks. The hard parts are never the Composer install — they are the certificate/key lifecycle, the per-SP attribute and NameID contracts, and interop testing against the specific SPs our customers actually use.

Technical risk. This is a security-critical component sitting directly on the authentication path, so risk is asymmetric — a defect means either lockout or, worse, an authentication bypass. Key exposures:

• Transitive protocol dependency. The package delegates XML signing, signature verification, and binding handling to an underlying SAML library. That library's maintenance status and advisory history matter more than this package's release notes. The v5.4.0 PR almost certainly touched only framework version constraints, which means the protocol-layer posture is unchanged from v5.3.2 — inherited, not improved.
• Thin CI surface. A framework-compatibility PR merged as the sole change in a release is a signal to verify the test matrix ourselves. Framework constraint bumps frequently pass static checks while failing at runtime on container bindings or deprecated helpers.
• Protocol-level hardening. Verify explicitly: signature verification is mandatory and not configurable-off, XML parsing is protected against XXE and signature-wrapping, assertion replay and NotBefore/NotOnOrAfter windows are enforced, and only modern signing algorithms (SHA-256+) are offered.
• Maintainer concentration. Small-maintainer packages in the auth path are a bus-factor risk; the active 13.x support is reassuring but does not constitute a support contract.

Key questions to answer before committing:

1. What is the exact PHP and Laravel version constraint in v5.4.0's composer.json, and does it drop any Laravel/PHP version we currently run?
2. Which underlying SAML library and version does it pin, and what is that library's release and CVE history?
3. Does the package's own CI matrix actually exercise Laravel 13, or was compatibility asserted without a matrix entry?
4. Which SAML profiles are supported — SP-initiated only, or IdP-initiated too? Is Single Logout implemented and reliable?
5. How are signing certificates supplied and rotated — file path, config, secrets manager — and is zero-downtime rotation possible (multi-cert metadata)?
6. Can SP definitions and attribute mappings be driven from the database for multi-tenant use, or is this config-file-per-deployment?
7. What is the NameID format policy, and can it be set per SP?

Integration Approach

Stack fit. Targets the standard Laravel application structure and modern PHP. It composes with existing auth rather than replacing it: the package answers "who is this user and how do I assert it," while our existing guards, session handling, and user model stay authoritative. Assumes a stable, non-reassignable user identifier — do not anchor NameID to a mutable email address without an explicit, agreed format and a change-management story.

Migration path.

• Greenfield (no IdP today): lowest risk. Adopt at v5.4.0 if we are on Laravel 12/13; adopt at v5.3.x if we are pinned to an older major and upgrade in one step later. No dual-running required beyond a pilot SP.
• From v5.3.x: effectively a constraint bump. Update, run the full suite, and smoke-test metadata, SSO, and SLO against a staging SP. Treat as a low-risk patch-equivalent change.
• From a homegrown IdP or simpleSAMLphp: materially larger. The work is not code migration, it is behavior migration — attribute release sets, NameID formats, signing algorithm choices, endpoint URLs published to SPs, and metadata refresh coordination with each SP owner. Budget for parallel operation during cutover, because SP-side metadata changes are outside our change window.

Compatibility. Build an explicit SP interop matrix and test against the real ones — Okta, Microsoft Entra ID, Google Workspace, and any bespoke customer SP — rather than against a reference implementation. SAML interoperability failures cluster in attribute naming, NameID format expectations, and clock/algorithm defaults, and they surface only against the real counterparty. Also confirm behavior behind our load balancer and TLS termination: some SAML libraries reconstruct URLs from request headers and produce wrong ACS/entity IDs behind a proxy.

Sequencing.

1. Non-production spike: one SP, one flow, end to end. Timebox it. This is the cheapest possible falsification of the whole approach.
2. Certificate and key handling runbook — generation, storage, rotation, expiry alerting — before any production SP is onboarded.
3. SP registry and attribute-mapping data model, if multi-tenant or more than a handful of SPs.
4. Per-SP attribute contract agreed in writing with each SP owner.
5. Canary one low-criticality SP in production; keep the fallback login path live.
6. Broaden SP coverage; then retire fallbacks.
7. Pin the version in composer.json and add the Laravel 13 job to CI before changing our framework default.

Operational Impact

Maintenance. Low ongoing code footprint, but not zero-touch. Expect an update roughly annually to track Laravel majors, plus ad-hoc security releases from the transitive SAML dependency. Budget on the order of one sprint per year for upgrades and interop re-verification, and treat any advisory in the underlying SAML library as an out-of-band page, not a backlog item.

Support. Support is community-only — GitHub issues, no SLA, no vendor escalation. Internally we own the on-call story: federated login failure is a total access outage for the affected user population, and the first responder will be our team, not the package author. Before launch we need a runbook covering certificate expiry, metadata drift, SP-side config errors, and the "disable federation temporarily" escape hatch. If enterprise customers require contractual uptime, audit evidence, or a named support contact for federation, that requirement points toward a commercial IdP rather than this package.

Scaling. Endpoints are conventional HTTP handlers and scale horizontally with the app tier; there is no stateful bottleneck in the package itself. Two things to watch: RSA sign/verify is CPU-bound, so model it against peak login concurrency rather than average (it is cheap per-request but not free at burst); and any session-index tracking for Single Logout implies shared session storage across nodes — an in-memory or per-node session driver will silently break SLO.

Failure modes, ranked by likelihood.

1. Certificate expiry or half-completed rotation — by far the most common cause of SAML outages. Mitigate with expiry alerting at 60/30/7 days and a rehearsed dual-cert rotation.
2. Metadata drift — an SP changes its ACS URL or entity ID and nobody tells us. Mitigate with periodic metadata reconciliation.
3. Clock skew — assertion rejected for a few seconds of drift. Mitigate with NTP across app nodes and a documented, narrow skew allowance.
4. Attribute/NameID mismatch — a new SP expects a format we don't emit; login succeeds at the IdP and fails at the SP, which makes it look like our bug.
5. Proxy/URL reconstruction errors after an infrastructure change — works in staging, fails behind production TLS termination.
6. Malformed or oversized SAML payloads — a robustness and availability concern at the edge; ensure request size limits and that parse failures return clean errors rather than stack traces.
7. Orphaned sessions where SLO is unsupported by an SP — a security-hygiene issue, not an outage, but it needs a documented maximum session lifetime.

Ramp-up. A competent Laravel developer is productive with the package in a day or two; the package is not the learning curve. SAML itself is — bindings, profiles, signature validation, and the fact that failures are opaque and bilateral. Realistic time to independent confidence is one to three weeks, and the fastest path is pairing with someone who has shipped SAML before, or paying for a short interop engagement. Plan knowledge to live with at least two engineers; a single person who understands the certificate lifecycle is an operational single point of failure.