- Is mlightsaml/lightsaml a Laravel package?
- No. LightSAML is a framework-agnostic SAML 2.0 PHP library that provides message models, bindings, metadata, and XML signing/encryption, but it has no service provider, config publisher, facade, or HTTP middleware. In a Laravel app it would sit as a low-level protocol engine inside your own SamlService, typically called from an ACS controller or middleware. All configuration, session handling, and user provisioning must be written in house.
- How do I install mlightsaml/lightsaml with Composer?
- Run composer require mlightsaml/lightsaml and confirm that the fork's composer.json resolves against your PHP and Laravel versions. Pay particular attention to the robrichards/xmlseclibs and symfony/* constraints, since an outdated pinned transitive dependency is the most common installation failure for LightSAML-derived packages. Also verify that ext-dom, ext-openssl, and ext-libxml are present in your runtime image.
- Does LightSAML support Laravel 10, Laravel 11, and PHP 8.2?
- The library is technically usable on PHP 7.x and 8.x only if the fork has patched upstream's legacy constraints, so you must check the composer.json before assuming Laravel 10 or 11 compatibility. Laravel 10 and 11 typically imply PHP 8.1 or newer, which is a stricter baseline than the original LightSAML releases targeted. Treat PHP 8.2+ support as something to verify with a proof of concept rather than something to assume.
- Which identity providers does LightSAML work with, such as Azure AD, Okta, ADFS, or Shibboleth?
- The evaluation does not confirm support for any specific IdP, so you must validate against your actual provider in a staging tenant. Critical checks include signed-assertion-only mode, encrypted assertions, and the metadata round trip. Do not assume Azure AD, Okta, ADFS, or Shibboleth compatibility until you have exercised the real flow end to end.
- Does LightSAML handle both SP-initiated and IdP-initiated SAML flows?
- LightSAML provides the bindings and message models needed to build either flow, but it does not implement the flow for you. You will write the AuthnRequest generation, ACS response handling, and assertion-to-user mapping yourself. IdP-initiated support is entirely a function of your adapter code and the specific IdP configuration.
- How do I wire LightSAML into a Laravel application?
- The realistic architecture is a thin adapter: a config/saml.php file, a singleton binding for the LightSAML AuthnRequest and Response builders, an ACS controller, and a guard or event that maps assertions to users. Metadata exchange, certificate rotation, and logout remain bespoke work. Budget for the adapter as a first-class deliverable rather than as glue code, and expect roughly 2 to 4 days for a first working SP flow.
- Is mlightsaml/lightsaml safe to use in production?
- The evaluation raises material concerns. Upstream LightSAML was effectively abandoned years ago, and this fork shows zero stars and zero dependents, with no visible community review, security policy, CVE history, or test coverage signals. SAML defects such as XML Signature Wrapping, comment-truncation canonicalization, XXE, and relaxed audience or InResponseTo checks become authentication bypasses, so independent security review is required before production. The cost of that review likely exceeds the savings versus a maintained alternative.
- How does LightSAML compare to onelogin/php-saml or aacotroneo/laravel-saml2?
- OneLogin and aacotroneo/laravel-saml2 offer maintained, Laravel-wired paths with a much larger user base. If you are already on either of those, do not migrate to this package. If LightSAML is mandated by an existing integration, isolate it behind an internal SamlAuthenticator interface so the implementation can be swapped later without touching domain code.
- What security tests should I write for a LightSAML integration?
- Cover the negative paths, not just the happy path: expired assertions, wrong audience, wrong recipient, bad or missing signatures, replayed assertions, and XML Signature Wrapping attempts. Add XXE and comment-truncation canonicalization probes because those are the classic failure modes in SAML libraries of this lineage. These tests should be written before production cutover, alongside a fallback authentication path.
- What is the maintenance burden of depending on this LightSAML fork?
- It is the dominant cost. With no upstream release cadence, your team owns the library: tracking SAML and xmlseclibs advisories, patching PHP compatibility, and re-validating signature handling after every change. The evaluation recommends completing security and maintenance due diligence before writing adapter code, and defining an exit plan if the fork is abandoned.