Wsse Authentication Bundle Laravel Package

Product Decisions This Supports

• Sizing a partner-integration bet before committing engineering. WSSE (UsernameToken profile) shows up when an enterprise counterparty — payment processor, telco/SMS gateway, SOAP-era B2B API — mandates it. This package answers "how do we satisfy their auth spec" with a known small surface area, so a PM can scope the integration as a bounded spike rather than an open-ended security project.
• Correctly classifying the work: compatibility, not capability. The product decision is to treat WSSE as an interop adapter for partner endpoints. It should never enter the roadmap as "our API authentication" — that conversation belongs to JWT/OAuth2/mTLS. If a stakeholder asks for WSSE on first-party clients, the PM's job here is to say no and cite the constraint.
• Build vs. buy on a security-sensitive primitive. The protocol looks like ten lines of hashing, but the failure modes are real: nonce replay windows, clock skew, digest construction (base64(sha1(nonce + created + password, true))), and nonce expiry. Adopting (or porting) vetted logic is a defensible "buy" against a hand-rolled implementation carrying a subtle auth-bypass risk.
• A stack-fit gate that must be settled first. This is a Symfony bundle, not a Laravel package — AppKernel::registerBundles(), app/config/security.yml, and app/console are all pre-Symfony-4 conventions. If we are a Laravel shop (as the brief assumes), the decision is not "adopt this dependency"; it is "use this repo as a reference implementation and budget a middleware build." That distinction changes the estimate, the owner, and the risk profile, and it is a PM-level call, not an engineering detail.
• An operational commitment, decided up front. Nonce storage grows monotonically. Adoption implies choosing a store (Doctrine table vs. Redis with TTL), a retention window, and wiring escape:wsseauthentication:nonces:delete <firewall> into the scheduler. Small, but it is a runbook item with an owner — and a throughput cliff if nonces hit the primary database per request.
• Vendor-risk posture for a low-adoption artifact. 135 stars, 0 dependents, "readme"-level maturity, and no upstream pressure to fix anything. The right product framing is "we are adopting code we will own" — pin the version, wrap it behind our own interface, and pre-agree who forks it when PHP or framework compatibility breaks.

When to Consider This Package

Adopt (or fork) when:

• The target is a legacy Symfony 2.x/3.x service (still on kernel/config layout) and a partner requires WSSE UsernameToken.
• Authentication is genuinely stateless per request — no sessions, no interactive login.
• You can own the nonce store and purge job: a table or Redis with TTL, plus a scheduled command invocation.
• You want replay protection and digest handling to live in reviewed code rather than hand-rolled code, and you're willing to pin the constraint and read the source once.
• You're prepared to treat it as vendored/owned code, forkable on a day's notice.

Look elsewhere when:

• The stack is Laravel. No bridge exists; the listener, DI extension, and firewall factory would never register. Reimplement the protocol as middleware (cheap — the surface is small) or, better, negotiate a modern scheme.
• The stack is Symfony 4+/Flex. Bundle registration and config paths in the README are outdated; expect friction and verify compatibility before accepting the ^2.2 constraint.
• The partner needs more than UsernameToken. No XML Digital Signature, X.509, encryption, or other WSSE profiles. "Sign the body" is out of scope entirely.
• Throughput matters. Per-request nonce writes are a scaling cliff; there is no built-in rate limiting or abuse protection.
• You need a supported dependency with a maintainer. Zero dependents means you are the maintainer on day one.
• The counterparty will accept OAuth2 client credentials, mTLS, or signed JWTs. Take that path; this package exists to serve a constraint, not a preference.

How to Pitch It (Stakeholders)

For executives (one paragraph): A partner or counterparty requires WSSE authentication — an older security standard still common in enterprise, telco, and payment integrations. This package is a small, single-purpose component that handles the risky part (replay protection and password digest) so we don't write security code ourselves. Integration is roughly a day plus a scheduled cleanup job, and it is scoped to partner endpoints only — it does not touch our product's login or our own API authentication. Two caveats shape the recommendation: it is a Symfony bundle, not a Laravel package, so on our stack it serves as a reference implementation we'd port rather than a drop-in dependency; and it is low-adoption and lightly maintained, so we should treat it as code we own — wrapped behind an interface, version-pinned, fork-ready. Recommendation: a time-boxed spike, adopting only if the partner's WSSE requirement is firm and the target service is legacy Symfony.

For engineering (the practical brief):

• What it actually gives us: a wsse security firewall listener (~5 lines of config), a token/provider/listener set, and the escape:wsseauthentication:nonces:delete pruning command. That narrow surface is the appeal — and also why porting it is cheap.
• What it does not give us: Laravel support, Symfony 4+/Flex-friendly registration, anything beyond UsernameToken, or a performance story for nonce storage. Assume glue work and a Redis-backed nonce store.
• Integrate defensively: hide WSSE specifics behind our own authentication interface; pin the composer constraint and vendor the source for review; wire the purge command into the scheduler with an explicit retention window; add tests asserting replay rejection and clock-skew handling — those two are where home-grown implementations fail.
• For a Laravel build (the likely path): the protocol is nonce + created + PasswordDigest = base64(sha1(nonce + created + password, true)); treat this repo as the spec, not the dependency.
• Questions to close in the spike: target framework/PHP version, whether the exact requirement is UsernameToken with or without password digest, nonce store choice under expected request volume, and fork ownership if upstream goes quiet.
• Effort estimate: low single-digit days including tests and ops setup. The ongoing cost is ownership, not integration.