- Can I install mlightsaml/symfony-bridge in a Laravel application?
- No, not as a runtime dependency. It is a Symfony bundle built around Symfony's dependency injection container, configuration tree, and security firewall model. Composer may resolve some shared Symfony components, but the bundle requires symfony/framework-bundle and symfony/security-bundle, which would pull a parallel kernel and container into Laravel. Use it as a design reference instead of an installed package.
- What is mlightsaml/symfony-bridge actually used for?
- It is a Symfony bridge for the LightSAML PHP library. It provides dependency injection service definitions, configuration for identity provider and service provider settings, routing and HTTP integration, and reusable services for building SAML requests and responses. Its purpose is to reduce glue code for SAML SSO inside Symfony applications, not Laravel applications.
- Is mlightsaml/symfony-bridge a Laravel package?
- No. Despite the vendor name and any brief framing, it is a Symfony bundle from DiegoCardosoSenaiSC/SymfonyBridgeBundle. Laravel has no bundle, compiler pass, or security.yaml firewall model, so there is no conventional install path. For Laravel, treat it as an architectural reference for wiring LightSAML services.
- How do I add SAML 2.0 service provider support to Laravel then?
- Depend on lightsaml/lightsaml directly only if you genuinely need its feature coverage. Implement a thin, testable service provider in Laravel: bind a SamlServiceProvider, add a guard or middleware, expose ACS, SLS, and metadata routes, and keep settings in config/saml.php. That stays on Laravel's container and avoids a second Symfony kernel.
- Which Laravel versions and PHP versions are supported?
- The package itself does not declare Laravel support because it is a Symfony bundle. Its own constraints track Symfony framework and security bundles, not Laravel. PHP 8.2 and 8.3 compatibility for the upstream LightSAML stack is unverified, especially around XML digital signatures. You must run a compatibility spike before relying on it.
- What does this fork change compared to upstream mlightsaml/symfony-bridge?
- The repository is a single-maintainer fork with zero stars and zero dependents, so you must diff it against upstream before trusting it. Determine whether it is PHP 8-patched or simply renamed. That answer decides whether it is a viable reference design at all. There is no downstream scrutiny or CVE-response process to lean on.
- Is it safe to use for production SAML authentication?
- Treat it as high risk for a production authentication path. SAML involves signature validation, XML canonicalization, XXE hardening, assertion replay windows, and certificate rotation, all of which need dedicated review. A zero-dependent, single-maintainer fork provides no community bug-finding or security response. Fund an explicit security review and name a maintainer before adoption.
- How does it compare with aacotroneo/laravel-saml2 or onelogin/php-saml?
- Those options are Laravel-oriented or standalone PHP libraries, while this is Symfony bundle glue. onelogin/php-saml and aacotroneo/laravel-saml2 are more natural starting points for a Laravel service provider integration. This package only makes sense if LightSAML's specific binding support is a hard requirement. Otherwise the LightSAML constraint disappears.
- What IdP features might require LightSAML instead of a simpler SAML library?
- Non-standard bindings such as IdP-initiated SSO, artifact binding, or encrypted assertions are the usual reasons to need broader SAML coverage. If your identity providers only need standard SP-initiated redirect or POST bindings, a simpler library or managed provider may suffice. Confirm which IdPs are actually in scope before committing. That determines whether LightSAML is necessary at all.
- How should I test a LightSAML integration in Laravel?
- Start with a one-to-two week compatibility spike in a throwaway Laravel 10 or 11 app. Install LightSAML core, resolve its XML and crypto dependencies, and prove one SP-initiated login round trip against a test IdP. Then define your own SamlAuthenticator contract and test it with mocked assertions. Avoid installing the Symfony bundle into the main application.