Laravel4 Saml2 Laravel Package

Product Decisions This Supports

• Whether to invest in SSO for a legacy stack at all. This package only matters for one scenario: a Laravel 4.x app in production that an enterprise buyer or internal security team requires to speak SAML 2.0. The real product decision is not "which SAML library" but "do we pay for SSO on a stack we should be retiring, and if so, for how long."
• Build vs. buy vs. bridge. Three viable paths, and this package is only one of them:
  • Buy (this package): thin Laravel 4 wrapper over the OneLogin php-saml toolkit. Cheapest to start, but with a dormant repo and 2 stars you are effectively adopting the code, not a dependency.
  • Build: wire onelogin/php-saml (or a successor) directly into your app behind an internal SsoProvider interface. More upfront work, but you own the upgrade path and can swap toolkits.
  • Bridge: terminate SAML at the edge (reverse-proxy/ALB SAML auth, Keycloak as an OIDC broker, Cloudflare Access, oauth2-proxy, WorkOS/Auth0) and leave the Laravel app untouched. Often the right answer when the app has a limited remaining lifespan.
• Roadmap sequencing and a forced decision date. An enterprise SSO requirement is a natural trigger to schedule the migration/replatform instead of patching Laravel 4. If SSO lands in the contract, the migration date becomes a customer-facing commitment — decide that deliberately.
• Enterprise tier / procurement readiness. SSO is a checkbox on security questionnaires and a common deal blocker. Note the scope gap: this package covers SP-initiated authentication only. It does not do SCIM provisioning, IdP-initiated flows, or (as shipped) logout/advanced session policy — so it may satisfy the questionnaire item without satisfying the actual enterprise requirement.
• Support-cost forecasting. Adopting it transfers ongoing ownership to your team: certificate rotation, metadata refresh, clock-skew handling, assertion debugging, and any future CVE in the underlying SAML toolkit. That is a recurring cost line that must be budgeted, not a one-time integration.
• Scope control for the initial release. If you proceed, deliberately narrow v1 to SP-initiated SSO against one IdP with a fixed attribute mapping. Multi-IdP-per-tenant and IdP-initiated support are meaningfully more work and should be separate decisions.
• Abandonment signal. Last release 2016-11-01, single maintainer, minimal adoption. Treat "is this maintained?" as already answered — it is not — and plan accordingly rather than re-litigating it.

When to Consider This Package

Consider it when:

• You are running Laravel 4.x in production and cannot migrate within the window an enterprise customer has given you; you need working SAML SSO in weeks, not quarters.
• The integration is narrow: a small number of IdPs, SP-initiated login, standard NameID/email attribute mapping, no SCIM and no advanced session/logout requirements.
• You are prepared to vendor or fork the code into your repository and own it — at 2 stars and no releases since 2016, that is the realistic operating model, not "using a library."
• Someone on the team can debug SAML specifics (XML signature validation, certificate expiry, clock skew, assertion replay) and you can test against a real IdP sandbox before committing.
• The exposure is bounded: internal users, a single trusted IdP, and an app whose blast radius you understand.

Look elsewhere or build in-house when:

• You are on Laravel 5+ or any modern PHP. This package targets Laravel 4 and will not run. Use a maintained alternative (e.g. a current laravel-saml2 package), integrate the SAML toolkit directly, or use a managed identity provider.
• The app is revenue-critical or customer-facing. SAML handling is an authentication bypass surface; XML signature-wrapping and assertion-confusion bugs are a well-known attack class. An unmaintained wrapper around an unmaintained toolkit gives you no CVE response path.
• You need a vendor, SLA, or deprecation policy. There is no vendor here. If procurement asks who supports it, the honest answer is "we do."
• You need IdP-initiated SSO, multi-tenant per-customer IdPs, SCIM provisioning, or single logout. These are out of scope for the package as shipped and amount to a custom build regardless.
• The app is retiring within a couple of quarters. Put SAML at the edge (proxy/broker) and spend nothing inside the Laravel codebase.
• The only thing keeping the app on Laravel 4 is inertia. Fund the migration and use the SSO requirement as the forcing function.

How to Pitch It (Stakeholders)

For executives: Enterprise buyers and internal security reviews treat SSO as a gate, not a nice-to-have, so this capability can directly unblock revenue. However, the specific package in front of us is a small, single-maintainer Laravel 4 wrapper whose last release was in 2016 — adopting it means our team owns that code permanently, including security patches. There are three options: (1) spend roughly one to two engineer-weeks integrating and hardening this package, accepting ongoing ownership; (2) put SSO in front of the app at the infrastructure layer and spend nothing inside the legacy codebase; (3) accelerate the migration and do SSO properly once. The recommendation is to decide between (2) and (3) first, and only fall back to (1) if a customer commitment forces SSO sooner than either can deliver. The decision we need is a date on the legacy app, not approval of a library.

For engineering: This is a Laravel 4 service-provider wrapper over the OneLogin php-saml toolkit — it gives you SP-initiated login, IdP metadata/certificate configuration, assertion validation, and session establishment, with routes, controllers, config, and views. It is genuinely less work than hand-rolling SAML, and it removes a meaningful chunk of custom auth code. Treat it as pre-production code you are adopting, not a dependency you are installing:

• Fork it into our repo, pin the commit, and wrap it behind an internal interface so it can be replaced or removed.
• Harden before shipping: enforce HTTPS and secure cookies, validate signatures and audience/recipient, add a replay/assertion cache, allow for clock skew, restrict to a single trusted IdP, and confirm only the intended endpoints are publicly routable.
• Write a runbook for certificate rotation and IdP metadata changes — these are the failures you will actually get paged for.
• Test against the customer's real IdP or a sandbox, not just a mock; XML canonicalization and signature quirks only show up against a real provider.
• Budget for the underlying toolkit going quiet: if a CVE lands, we patch it ourselves.

The payoff is fast SSO and less custom code; the cost is permanent ownership and no upstream support. Validate both in a time-boxed spike before we commit either way.