- Can I use nbgrp/onelogin-saml-bundle in a Laravel application?
- No. It is a Symfony bundle, not a Laravel package. Composer will install it, but nothing wires up because Laravel has no bundle registration, no FrameworkBundle, no Symfony security firewall, and no kernel config-tree lifecycle. Only the underlying onelogin/php-saml toolkit is reusable in a Laravel app.
- What does this bundle actually provide for SAML service provider support?
- It provides a thin Symfony integration layer: a Bundle class, DI extension, config tree, security firewall factory, a dedicated SAML authenticator, and a metadata controller. The actual SAML protocol work lives upstream in onelogin/php-saml. The integration layer is inert outside Symfony; the protocol layer and the configuration schema are what transfer.
- Is there a Laravel SAML package I should evaluate before building my own?
- The Laravel SAML ecosystem is thin and unevenly maintained, so treat this as a build-vs-buy spike rather than a default choice. Evaluate available Laravel SAML packages first. If none meet your requirements, building on onelogin/php-saml and patterning the config on this bundle's schema is the most reliable path.
- How do I port the bundle's IdP and SP configuration into a Laravel config file?
- The bundle's config schema is a well-formed spec: SP entity ID, ACS and SLO URLs, IdP metadata, X.509 certificates, signing algorithm, and attribute mapping. Copy those keys into a config/saml.php file and bind them in a service provider. Expect roughly one to two sprints for a faithful Laravel-native port, including validation.
- Which Laravel routes do I need to implement for a SAML service provider?
- You need a metadata endpoint (typically /saml/metadata), an assertion consumer service route that accepts the IdP's POST, a login route that builds and redirects a SAML AuthnRequest, and a single logout route if SLO is in scope. None of these are provided by this bundle for Laravel. Each is a Laravel-native route plus controller you write against onelogin/php-saml.
- Does the v3.0.0 release make this bundle compatible with Laravel?
- No. v3.0.0 adds Symfony 8.0 support inside the Symfony integration layer, which is exactly the part that is inert in a Laravel app. It is a breaking change for Symfony consumers, since Symfony 7.x and earlier are likely dropped from the supported range. For a Laravel port it is a no-op, so do not let the major version label trigger a re-plan.
- Is nbgrp/onelogin-saml-bundle actively maintained, and what is the bus factor?
- It is BSD-3-Clause licensed, builds on a mature upstream toolkit, and cut a major release to track Symfony 8.0, which is a positive vitality signal. However, roughly 57 stars and zero recorded dependents suggest a single-maintainer project with a thin user base. The contributor and dependent concentration risk is unchanged by v3.0.0.
- What SAML security issues should I plan for in a Laravel port?
- SAML signature wrapping (XSW), assertion replay, audience and recipient validation, clock skew handling, and encrypted assertions are all places a hand-rolled port goes wrong. These need an explicit security review, not just a passing test suite. Also verify whether your chosen onelogin/php-saml version pins a patched XML-signature library, since the bundle release notes do not mention a dependency bump.
- How do I map SAML attributes to an Eloquent user model instead of a Symfony user?
- This bundle maps assertion attributes to Symfony user objects via configuration, which has no Laravel equivalent. In Laravel you write a custom attribute mapper that reads the nameID and attribute keys from the assertion and resolves or creates an Eloquent user. If just-in-time provisioning is expected, define that logic explicitly and decide how to handle attribute changes on subsequent logins.
- Does this bundle support single logout, signed assertions, and IdP-initiated flows?
- The bundle advertises signed assertion support, logout, custom user providers, and configurable IdP and SP settings. Whether encrypted assertions, signed authn requests, and IdP-initiated SSO are enabled depends on your toolkit configuration and your IdP's requirements. Confirm with your IdP whether SP-initiated, IdP-initiated, or both flows are required, since that materially changes routing and config design.