- Can I install javer/symfony-bridge in a Laravel application?
- No. It is a Symfony bundle (SymfonyBridgeBundle) built on Symfony's bundle and dependency injection conventions, and Laravel consumes Symfony components rather than bundles. Composer require will not give you a bootable Laravel integration because there is no Laravel service provider, facade, or config publisher. You would have to port the wiring yourself.
- What does javer/symfony-bridge actually do?
- It wires the Javer/LightSAML core library into Symfony's service container and HTTP kernel. It provides a configuration tree and service definitions for SP/IdP metadata and signing credentials, plus likely routing for metadata and ACS endpoints. It is thin glue for Symfony, not a SAML engine and not a Laravel package.
- Does version 1.6.0 add Laravel support?
- No. Release 1.6.0 is version-currency housekeeping: Symfony 7 support, a PHP 8.1 floor, and a GitHub Actions refresh. It does not touch packaging, namespaces, or the framework surface. The core Laravel mismatch stands unchanged.
- Which Symfony and PHP versions does javer/symfony-bridge 1.6.0 support?
- It declares Symfony 7 support with a PHP 8.1 minimum. Because Symfony 7 requires PHP 8.2 or newer, the real matrix is likely PHP 8.1 with Symfony 6.4 and PHP 8.2+ with Symfony 7. Confirm that your target combination is actually exercised in CI rather than merely declared.
- Is javer/symfony-bridge safe for production SAML authentication?
- The risk is high. The bundle has zero stars, zero dependents, no substantive issue history, and a single-maintainer release cadence. SAML assertion parsing and signature validation are a classic exploit class (XSW, XXE), and 1.6.0 does not disclose which LightSAML core version you would inherit. Betting an authentication path on an unaudited wrapper is a poor trade regardless of the underlying library's quality.
- What is the best way to add SAML SSO to Laravel if this package is Symfony-only?
- Integrate the LightSAML core library directly through a Laravel service provider, or use a maintained Laravel SAML package. The bundle is small enough that a competent PHP engineer can read it in an afternoon and port the wiring in days. That port is likely cheaper and safer than standing up a Symfony tier for a single auth flow.
- Can I run javer/symfony-bridge in a sidecar and call it from Laravel?
- Technically feasible: run a standalone Symfony application that terminates SAML and have Laravel call it. Version 1.6.0 removes the most likely hard blocker by supporting Symfony 7 and PHP 8.1, so the sidecar need not run an end-of-life framework. However, you take on a second framework runtime and a second configuration idiom for one capability.
- How is javer/symfony-bridge configured?
- It uses a Symfony bundle configuration tree, typically under a bundle-specific key in config/packages, with service definitions for SP/IdP metadata and signing credentials. That idiom does not map to Laravel's config files or service container. In Laravel you would express the same values in a config file and bind services in a provider.
- Is javer/symfony-bridge actively maintained?
- Release cadence is sparse, surfacing once every several months, with no downstream dependents to absorb abandonment. 1.6.0 is a positive signal on version currency but not on community or support. For an authentication path, that governance profile is not a supportable foundation.
- Can I use javer/symfony-bridge as a reference implementation for Laravel SAML wiring?
- Yes, that is its most realistic use in a Laravel-first estate. Read it to see how SP/IdP metadata, signing credentials, and ACS and metadata routes are wired, then port those service definitions to a Laravel service provider. Treat it as documentation, not a dependency.