Product Decisions This Supports
- Partner/enterprise integration sequencing: WSSE (WS-Security UsernameToken) is a gate for connecting to legacy SOAP or enterprise APIs (payment gateways, shipping carriers, banking/ERP, Salesforce SOAP, etc.). Adopting this package lets you ship those integrations without blocking on custom security code, directly informing which partner integrations land this quarter vs. next.
- Build vs. buy for auth plumbing: A ~200-line middleware is commodity work. This package argues for "buy" (MIT, drop-in) over building bespoke nonce/timestamp/digest logic in-house — useful when scoping engineering effort for a single integration and deciding whether it warrants a story point or a dedicated workstream.
- Legacy vs. modern API roadmap: If a meaningful share of your partner surface is SOAP/WSSE, this becomes a symbol of a "integration debt" theme. It supports the decision to keep a thin, well-tested SOAP adapter layer alive rather than force premature migration to REST/OAuth2.
- Security & compliance posture: Password-digest WSSE with nonce and created-timestamp is a known standard; using a package (rather than ad-hoc header construction) reduces audit findings around homegrown crypto. This supports security review sign-off on partner integrations.
- Vendor onboarding playbook: Standardizing on a single Guzzle middleware lets you templatize "new enterprise partner" onboarding — a reusable checklist item rather than a per-integration negotiation.
When to Consider This Package
Consider it when:
- The target API explicitly requires WSSE UsernameToken authentication and your stack is PHP/Laravel with Guzzle as the HTTP client.
- You want the auth concern isolated as a Guzzle middleware/handler, composable with retries, logging, and existing client configuration.
- You need only UsernameToken (digest) semantics — nonce, created timestamp, base64-encoded SHA1 password digest.
- The integration is low-churn: one or a handful of partner APIs, not a platform-wide auth standard.
Look elsewhere or build in-house when:
- You need X.509 certificate signing, WS-Security encryption, or SAML assertions — this package does not cover those.
- You need modern auth (OAuth2, OIDC, mTLS, HMAC request signing) — different problem entirely.
- Maintenance risk is unacceptable: last release 2019, ~31 stars, zero dependents on Packagist. Treat it as a vendored/forked dependency with a named owner, or reimplement the ~100-line digest middleware against
robrichards/wse-php or Guzzle's own middleware primitives.
- Guzzle major-version compatibility is unverified for your target — confirm before committing a roadmap item to it.
Adoption guardrails: pin the version, vendor the source, and add a contract test asserting the exact WSSE header format your partner validates. Do not let it become an implicit single point of failure across many integrations without an owner.
How to Pitch It (Stakeholders)
To executives: This is a small, free (MIT) component that unblocks a class of enterprise and partner integrations — the kind that still speak SOAP and require WS-Security. It removes custom security code from our critical path, shortens integration timelines, and reduces audit exposure. Cost is effectively zero; the only real risk is that the upstream project is dormant, which we mitigate by pinning and vendoring it under engineering ownership. Recommendation: adopt for specific integrations, not as a platform standard.
To engineering: It's a Guzzle middleware that injects WSSE UsernameToken headers (nonce, created, SHA1 digest) into outgoing requests — no bespoke crypto, no per-client boilerplate. It composes cleanly with existing handler stacks and is trivial to fork if we need to extend it. Caveats: released 2019, so we should verify Guzzle compatibility, pin the version, and add a contract test on the emitted header. If we need X.509 signing or OAuth2, this isn't the tool — plan a separate decision.