- How do I install robrichards/xmlseclibs in a Laravel application?
- Install it with composer require robrichards/xmlseclibs. It requires PHP 8.0 or greater, phpseclib/phpseclib ~3.0, and DOM/libxml, while ext-openssl is now optional because phpseclib handles the crypto. There is no service provider or facade, so the usual pattern is to bind a small XmlSec service in your container and inject it wherever you sign or verify. That keeps the library behind an adapter boundary instead of being called directly from controllers or jobs.
- Is xmlseclibs compatible with Laravel 10 and Laravel 11?
- Yes. The master branch requires PHP 8.0+, which lines up with Laravel 9 and later, and Laravel 10 and 11 running on PHP 8.1 or 8.2 are comfortable. There is no framework coupling to break, since the library has no service provider, publishable config, or global state. The only realistic constraint comes from Composer: the phpseclib ~3.0 pin.
- Does xmlseclibs ship a Laravel service provider, facade, or config file?
- No. xmlseclibs is a cryptographic primitive library, not a framework component, so it has no service provider, no publishable config, no facade, and no opinion about HTTP, storage, or key management. That is both the appeal, zero framework conflict, and the cost, because you build and own the seam yourself. A typical setup is your own config/xmlsec.php holding pinned certificates per peer, allowlisted signature and digest algorithms, clock skew, and legacy-interop flags.
- How do I safely verify a SAML or WS-Security signature with xmlseclibs?
- Prefer the safe-by-default verifier verifyDocument() and always pass a caller-supplied, pinned key rather than deriving the key from the document's KeyInfo. It enforces an allowlist for the SignatureMethod and every DigestMethod, rejects DOCTYPE and XPath transforms by default, and only reports success when every reference validated. After a low-level validateReference() call, operate only on getValidatedNodes() and never re-select assertions by Id from the whole document.
- Why does xmlseclibs verify() return -1 and why is that dangerous?
- verify() returns 1 on success and -1 on error, and -1 is truthy in PHP, so a loose boolean check treats a failure as a pass. Always use a strict comparison such as $objDSig->verify($key) === 1. That mistake, combined with trusting KeyInfo and re-selecting nodes by Id, is exactly what produces signature-wrapping exploits. The newer verifyDocument() API sidesteps the trap by failing closed.
- How do I support legacy peers that require SHA-1 or RSA-1.5 in xmlseclibs?
- By default verifyDocument() accepts only SHA-256/384/512 digests and RSA-SHA-256/384/512 plus RSA-PSS signatures, and RSA-1.5 key transport is denied on decryption because of Bleichenbacher risk. For old IdPs, banks, or government e-invoice platforms you widen the sets explicitly, for example $objDSig->allowedSignatureAlgorithms[] = XMLSecurityKey::RSA_SHA1; or $objenc->allowRSA15KeyTransport = true;. Treat every widening as a deliberate downgrade with a documented exception, an owner, and an expiry rather than a code comment.
- Should I use the xmlseclibs 4.0 beta or stay on the stable 3.1 branch?
- All of the hardening lives in the 4.0 line: safe-by-default verifyDocument(), DOCTYPE rejection on verify, XPath transform rejection, RSA-1.5 denial, and fail-closed references. The 4.0 release is still beta, so APIs and defaults may still change, while 3.1 is stable but leaves you to re-implement those hardened defaults and own the bugs. Taking a beta at a security boundary needs explicit written sign-off and a named internal owner accountable for that call.
- Is xmlseclibs safe to use with Laravel Octane and long-running workers?
- The library is stateless and value-in/value-out, so it holds no global state that could leak between requests. Keep XMLSecEnc and XMLSecDSig instances per-request or per-operation instead of storing them on container singletons. Bound that way it behaves fine under Octane, queue workers, and other long-running processes.
- What are the requirements and dependency conflicts for robrichards/xmlseclibs?
- It needs PHP 8.0+, phpseclib/phpseclib ~3.0, and DOM/libxml, while OpenSSL is optional since phpseclib handles the crypto, which can simplify base images. The realistic friction is the phpseclib ~3.0 pin colliding with older SSH or SFTP packages still on 2.x. Run composer why robrichards/xmlseclibs before adding it, because most PHP SAML stacks already pull it in transitively via tools like SimpleSAMLphp, LightSAML, or OneLogin php-saml, and consolidating on one XMLDSig implementation beats adding a second.
- How do I handle XML encryption with RSA-OAEP and AES-GCM in xmlseclibs?
- Prefer RSA-OAEP for key transport and AES-GCM for data encryption, which are the defaults the library steers you toward. You can pin exact algorithms via $objenc->allowedKeyAlgorithms and $objenc->allowedDataAlgorithms, using the XMLSecEnc::DEFAULT_KEY_ALGORITHMS and XMLSecEnc::DEFAULT_DATA_ALGORITHMS presets. Unauthenticated CBC modes remain available for interop but are malleable, so enable them only per peer with a documented justification.