Weave Code
Symfony Bridge Laravel Package
lightsaml2/symfony-bridge
Symfony bridge for LightSAML2 that integrates SAML 2.0 service provider and identity provider support into Symfony apps, with bundle configuration, security firewall integration, and endpoints for authentication requests, responses, metadata, and single logout.
Light SAML Symfony bridge bundle
Frequently asked questions about Symfony Bridge
- Can I use lightsaml2/symfony-bridge in a Laravel application?
- Not directly. It is a Symfony bundle built around Symfony's bundle system, DI container compiler passes, and SecurityBundle firewall listeners, none of which exist in Laravel. Laravel consumes selected Symfony components such as HttpFoundation, Routing, and Console, but it has no firewall-listener seam for a SAML token flow. Treat this package as reference architecture for a spike, not a Composer dependency.
- What does lightsaml2/symfony-bridge actually do?
- It is a thin integration layer that connects the LightSAML2 SAML 2.0 toolkit to Symfony by registering service provider and identity provider services in the container, exposing bundle configuration for IdPs, and generating SP metadata. It also wires response parsing and validation hooks into Symfony's request lifecycle. It contains very little SAML logic of its own; the protocol and cryptographic work lives in the underlying lightsaml core library.
- Is lightsaml2/symfony-bridge safe for production SAML authentication?
- The adoption signals here are effectively a null result: roughly one star, zero dependents, and a composite score near 0.005. For a package whose job is verifying cryptographic assertions, nobody having looked at it is disqualifying rather than a yellow flag. A thin wrapper over a low-activity core inherits the full SAML attack surface, including XML Signature Wrapping, canonicalization edge cases, XXE in assertion parsing, assertion replay, clock-skew tolerance, and encrypted assertions, with no upstream security response behind it. Broken SAML tends to fail silently as an authentication bypass that looks like a successful login.
- How would I build SP metadata and an ACS endpoint in Laravel without this bundle?
- Hand-build three routes against the lightsaml/lightsaml core: /s AML/metadata to emit SP metadata XML for IdP registration, /saml/acs as an assertion consumer service controller, and /saml/sls if single logout is in scope. Pair those with a custom auth guard, a UserProvider, and a just-in-time provisioning listener. Budget roughly two to four weeks for an engineer already fluent in SAML, and note that the bundle under evaluation contributes essentially nothing to the shipped design.
- What PHP and framework versions does it support?
- The available material does not publish a clear support matrix, so verify commit cadence, last release date, Packagist publication, and PHP 8.2 and 8.3 constraints before any commitment. Because the bundle targets Symfony's bundle and security APIs, its PHP constraints track Symfony's, not Laravel's. Check composer.json on Packagist rather than assuming a version floor.
- What are the alternatives to lightsaml2/symfony-bridge for Laravel?
- 24slides/laravel-saml2 is a Laravel-native wrapper over onelogin/php-saml with materially better maintenance signals and a large installed base, making it a far better starting point for a service provider. Managed brokers such as Okta, Entra ID, Auth0, WorkOS, or Cloudflare Access integrated through Socialite are the buy option. The Symfony bridge is worth reading for metadata XML generation, AuthnRequest construction, and validation orchestration patterns, but not for shipping.
- Does it support IdP-initiated SSO and single logout?
- The description mentions endpoints for authentication requests, responses, metadata, and single logout, but the scope of unsolicited IdP-initiated responses is not documented in the available material. Single logout is disproportionately expensive to implement correctly, since it requires session index tracking and front-channel or back-channel logout propagation. Confirm both against the source before scoping them into a build.
- How is multiple identity provider configuration handled?
- The bundle exposes pluggable identity provider configuration through Symfony bundle settings, with each IdP typically defined by entity ID, SSO and SLO endpoints, and signing certificate. A Laravel reimplementation would mirror that as a config/saml.php array plus a resolver keyed by entity ID or tenant. Supporting per-customer IdP metadata and certificate rotation roughly triples implementation and operational surface compared with single-tenant.
- How do I test SAML authentication without a real identity provider?
- Use a test IdP or a self-signed certificate pair to sign assertions, and build fixtures for valid, expired, and tampered responses so you can assert that validation actually rejects them. The failure mode to guard against is a response that appears to authenticate while the signature covers a different assertion, so negative tests matter more than happy-path ones. In Laravel, exercise the ACS route through feature tests, stub the core validation step, and run at least one end-to-end check against a real IdP in staging.
- Should we build SAML in-house or buy a managed solution?
- If the driver is only a vague possibility that SSO might be needed one day, defer, because SSO is a commodity purchase and not a differentiator. If a named enterprise IdP sits in a signed or in-flight contract, or a security questionnaire is blocking a deal, compare a managed broker against the build cost first. Building only makes sense when you need control a broker cannot give you and have SAML expertise already in-house.
Weaver
How can I help you explore Laravel packages today?