Laravel Saml2 Laravel Package

Product Decisions This Supports

• Build vs. buy for enterprise SSO. The package owns SAML2 tenant configuration in a saml2_tenants table, which points to per-tenant identity provider support — the capability enterprise buyers ask for when their security team insists on their own IdP. This is a buy-shaped problem (certificate rotation, assertion validation, clock skew, metadata refresh); the alternative is a bespoke SAML integration that consumes a sprint and keeps consuming maintenance.
• Multi-tenant roadmap scoping. A tenants table implies the package is designed for one Laravel application serving multiple customer organizations, each with its own IdP. That supports product decisions about tiering (SSO as an enterprise-plan gate), tenant provisioning flows, and whether onboarding is self-serve or assisted.
• Schema ownership and data governance. Shipping the migration as a publishable stub (rather than running it from the package) moves ownership of the saml2_tenants schema into the application. That is a meaningful decision lever: it enables adding columns (plan tier, IdP owner contact, forced-SSO flags), controlling migration ordering in your deploy pipeline, and answering data-residency or schema-change-review questions from security reviewers.
• Onboarding and deployment ergonomics. The install path is now explicit — publish, then migrate — rather than implicit. This affects docs, seed/CI scripts, and any environment bootstrap automation, and it removes a hidden side effect from composer install.
• *Evidence note: this assessment is derived from the v1.1.0 changelog only; feature-level claims beyond tenant-scoped SAML2 configuration should be verified against the package README before committing roadmap._

When to Consider This Package

Consider it when:

• You need SAML2 SSO in a Laravel application and each customer organization brings its own identity provider — the multi-tenant table strongly suggests this is the intended shape.
• You want application-owned schema. The publishable-stub migration is a good fit for teams that centralize migrations, run review gates on schema changes, or need to extend the tenants table.
• You are comfortable with Laravel conventions (vendor:publish --tag=... + migrate) and can absorb a two-step install in your onboarding documentation and deployment runbooks.
• You already ship (or are planning) enterprise-tier packaging where SSO is a paid capability rather than a default.

Look elsewhere when:

• You need only single-tenant SSO for internal staff — a simpler first-party or OIDC-based solution will be less surface area to operate.
• You need social/OIDC consumer login rather than enterprise SAML; this is the wrong tool for that job.
• You want to avoid owning IdP lifecycle operations (certificate rotation, metadata expiry, per-tenant support burden) — a hosted identity broker is the better buy.
• Your deployment model cannot accommodate explicit migration steps (e.g. immutable images with auto-run migrations that you don't control), or you cannot guarantee ordering of the published migration against your own.

How to Pitch It (Stakeholders)

For executives: This is the piece that unblocks enterprise deals where the buyer's security team requires SSO against their own identity provider. We buy the hard, standards-heavy part instead of building it, which converts an open-ended integration project into a configuration and onboarding task. The v1.1.0 release is housekeeping, not a change in scope — no re-platforming, no renegotiation of the plan.

For engineering: v1.1.0 removes the package-run migration in favor of a publishable stub, matching the pattern already used across the vendor's other packages. The upgrade from 1.0 is a no-op: the saml2_tenants table already exists, and re-publishing plus migrating is idempotent — it preserves the existing table and only adds what is missing. New environments now require php artisan vendor:publish --tag=saml2-migrations followed by php artisan migrate, so bootstrap scripts, Docker entrypoints, and the README quickstart need updating. The run_migrations option is gone; anything referencing it should be deleted.

For support and solutions teams: New customer deployments have one extra setup step. Existing customers need no action — the table is already in place and the upgrade is safe to run without coordination.