- Is mi-lopez/OneloginSamlBundle a Laravel package?
- No. It is a Symfony bundle built for OroCommerce and Symfony applications, not a Laravel package. It registers through the Symfony kernel, wires into the DI container, and hooks the security firewall as a custom authenticator, which is not how Laravel's guard-based auth works. Porting it into a Laravel service provider would mean reimplementing bundle bootstrapping with no upstream support.
- How do I install and configure the OneLogin SAML bundle in Symfony or OroCommerce?
- Install it with Composer, then register the bundle in your kernel (bundles.php for Symfony Flex, or the Oro bundle list) and add configuration for your SP entity ID, assertion consumer service URL, IdP metadata, and X.509 certificates. Attribute mapping and optional assertion signing or encryption go in the same config block. Most of the effort is metadata exchange and certificate handling with your IdP, not writing code; expect a few engineer-days for a first working SP-initiated flow.
- What should Laravel developers use instead for SAML single sign-on?
- Do not use this bundle in Laravel. Options are a native Laravel SAML SP package such as 24slides/laravel-saml2, a thin service wrapper around onelogin/php-saml so you control the pinned version, or an identity broker like Keycloak, Authentik, or oauth2-proxy that terminates SAML and lets Laravel consume OIDC. The broker approach adds an operational component but keeps SAML protocol handling out of your application code.
- Does the bundle support both SP-initiated and IdP-initiated SAML logins, plus single logout?
- Yes, the overview states support for both SP-initiated and IdP-initiated logins, and single logout is listed as an optional feature alongside assertion signing and encryption. SP-initiated flows are the more commonly exercised path; IdP-initiated and SLO are where thin SAML wrappers tend to be weakest. Test SLO explicitly against each IdP you plan to support before relying on it.
- Which identity providers work with this SAML bundle?
- Any standards-compliant SAML 2.0 identity provider should interoperate, including Microsoft Entra ID, Okta, OneLogin, Google Workspace, and Shibboleth. Compatibility depends less on the bundle and more on correct metadata exchange, certificate rotation, and NameID format agreement. Decide your IdP list up front because each one adds configuration and testing surface.
- How do I map SAML attributes to local user accounts with this bundle?
- The bundle exposes attribute mapping configuration where you map SAML assertion attributes such as username, email, and roles onto your local user fields. The bundle is only a thin integration layer, so the actual attribute names come from your IdP's assertion and must be confirmed in its metadata or a debug capture. Verify the NameID format and check how unknown users are handled, whether provisioned on the fly or rejected.
- Is mi-lopez/OneloginSamlBundle safe and maintained enough for production?
- Treat it with caution: it is a downstream fork of hslavich/OneloginSamlBundle with no stars, no dependents, and a single maintainer, so there is no community catching regressions or security reviews. If you proceed, fork it internally on day one and track the upstream diff yourself. Authentication code is a security boundary, so plan for a security review rather than only a code review.
- Which version of onelogin/php-saml does it pin, and are there known CVEs?
- You must verify the pinned onelogin/php-saml version yourself, because the bundle is only a wrapper and all cryptographic and protocol logic lives in that upstream toolkit. OneLogin has signaled reduced or ending maintenance of its SAML toolkits, so check the pin against known issues including XML signature wrapping, xmlsec handling, and XXE. This is the single most important due-diligence item before adopting the package.
- Can it handle multiple identity providers or multi-tenant SAML setups?
- The bundle's surface is oriented around a single IdP configuration: SP entity ID, ACS URL, IdP metadata, and attribute mapping. Multi-tenant deployments with several IdPs usually require custom work to resolve the right IdP per request, typically via tenant-specific ACS endpoints or metadata lookups. Confirm this requirement early, because it changes the integration design more than any other factor.
- How do I test SAML SSO locally without a real identity provider?
- Use a test IdP such as samltest.id, a local SimpleSAMLphp instance, or OneLogin's developer tier, and generate self-signed certificates for signing and encryption checks. Exercise the failure paths too: expired assertions, wrong audience, replayed InResponseTo values, and clock skew. Those negative tests are what catch auth bypass bugs that a happy-path login will never reveal.