Shibboleth Authentication Bundle Laravel Package

Product Decisions This Supports

• Market entry into education/research/public sector. Shibboleth federation login (InCommon, eduGAIN, UK AMF, DFN-AAI) is a procurement gate for universities, research institutes, and many public agencies. This package supports the go/no-go decision on pursuing those segments and the sequencing of federated SSO on the roadmap.
• Build vs. buy vs. broker. It anchors the comparison between (a) integrating a small Symfony bundle, (b) hand-rolling SP-side SAML, and (c) buying a brokered identity layer (Keycloak, Auth0, Okta, SimpleSAMLphp). The right answer changes with deal size and IdP diversity.
• Feature vs. platform. Whether federation is a checkbox feature on an enterprise tier or a platform capability with its own ownership, on-call, and metadata lifecycle.
• Deal unblocking. Security questionnaires and RFPs routinely ask for SAML 2.0 SP support, IdP-initiated flows, attribute release, and signed assertion handling. This is the artifact that answers "can we say yes?"
• Use cases it enables. Campus-wide SSO for a SaaS product; inter-institution research collaboration portals; B2B partner access where the partner's IdP is Shibboleth; affiliate/guest access via federated identity.
• Scope clarity. It is SP-side only (your app is the relying party), which constrains decisions: no IdP, no provisioning, no multi-tenant federation admin.
• Dependency risk posture. Zero stars, zero dependents, and a low opportunity signal mean the PM decision is less "adopt" and more "wrap, vendor, or spike" — it informs whether to isolate behind an internal auth interface.

When to Consider This Package

Consider it when:

• You are on Symfony and need SP-side Shibboleth/SAML authentication that plugs into the framework's security layer rather than a standalone library.
• You have a concrete federation mandate — a named customer, consortium, or RFP requires InCommon/eduGAIN/UK AMF membership and IdP-initiated login.
• Your team already runs, or can run, Apache + mod_shibboleth or a Shibboleth SP, since bundles of this kind typically consume headers/env vars the SP sets after authentication.
• You need authentication plus attribute mapping only — not SCIM provisioning, not IdP operation, not a self-service federation metadata console.
• You can accept a small-maintainer dependency, pin/vendor it, and keep a fallback path.

Look elsewhere when:

• You are on Laravel — this is a Symfony bundle and not directly usable; evaluate laravel-saml2, Socialite providers, or a brokered IdP instead. The framing "Laravel/PHP package" does not hold here, and that mismatch is itself a decision input.
• You need many IdPs or mixed OIDC/SAML — a broker is more robust than per-protocol in-app code.
• You need IdP functionality, multi-tenant configuration, SCIM, or metadata self-service.
• You need a supported, SLA-backed dependency — there is no visible maintainer cadence, community, or dependent base to lean on.
• Your runtime cannot host a Shibboleth SP (serverless, restricted PaaS) — prefer in-process SAML or a broker.
• Compliance demands vendor security review, SBOM provenance, or long-term support commitments.

How to Pitch It (Stakeholders)

Executives. Federated login is a revenue gate for education, research, and public-sector deals — without SAML/SP support we fail security review and lose the opportunity. This package is a small, Apache-2.0 building block for Symfony SP applications: cheap to trial, but unproven (no community, no dependents, no visible maintenance). Recommendation: time-box a spike behind an internal auth abstraction, with a brokered-IdP fallback already priced. Note the stack caveat up front: it is Symfony-only, so if our product surface is Laravel, the real decision is broker vs. in-app SAML library, not this bundle.

Engineering. It handles SP-side plumbing — assertion consumption and attribute mapping into the Symfony security context — so we do not hand-roll SAML. Expect to still operate a Shibboleth SP/mod_shibboleth in front and to own metadata refresh and certificate rotation. Before committing: verify framework compatibility, test coverage, and release cadence; isolate it behind our own authenticator interface so we can swap to a broker or in-house implementation without touching product code. Scope the spike to one federation test environment, one IdP, and one attribute contract, with a clear exit criterion.