Wsse Authentication Bundle Laravel Package

Technical Evaluation

Architecture fit. This is not a Laravel package — it is a Symfony2 bundle (mopa/wsse-authentication-bundle) that plugs into the Symfony Security component via a custom AuthenticationProvider, a firewall listener, a WsseToken, and a nonce cache. Its integration surface is Symfony's DI container (XML/YAML service definitions), the security.firewalls config tree, and Symfony\Component\Security\Core\* interfaces. None of that exists in Laravel's guard/middleware model. There is no path to composer require this into a Laravel application; its value to us is as a reference implementation of the WSSE UsernameToken digest and replay-protection pattern, not as a dependency.

Integration feasibility. The protocol logic worth harvesting is small — roughly 200–400 LOC: parse the Authorization: WSSE profile="UsernameToken" header, Base64-decode the UsernameToken, extract Username, PasswordDigest, Nonce, Created, verify Base64(SHA1(nonce + created + password)), validate the Created timestamp against a clock-skew window, and record the nonce in a TTL cache to block replay. Reimplementing that as a Laravel middleware plus a custom guard is a 3–5 day task for one engineer including test coverage. Reusing the package directly is not feasible on PHP 8.x / Laravel 10–11; the code targets PHP 5.3-era syntax and Symfony 2.0/2.1 APIs that were removed years ago.

Technical risk.

• Abandonment. 18 stars, 0 dependents, health score 0.27 — no upstream maintenance, no security response, no compatibility work. Anything we ship is a fork we own permanently.
• Password storage constraint (the blocker). The standard WSSE digest requires the server to hold the plaintext password to recompute SHA1(nonce + created + password). That is incompatible with bcrypt/argon2 hashing and would force a reversible or plaintext credential store. If we build this, we must deviate from the spec (HMAC with a stored per-client secret) or scope WSSE strictly to a dedicated API-credential table that never touches user passwords.
• Replay protection is mandatory and easy to get wrong. Correctness depends on a shared, atomic nonce store. A per-node in-memory cache silently defeats the entire scheme behind a load balancer.
• Legacy protocol surface. WSSE is a WS-Security construct; demand is concentrated in SOAP/enterprise partner integrations and older mobile clients. Adopting it broadly would be an architectural regression versus OAuth2/Passport or signed request schemes.
• License/provenance. Confirm the license and code provenance before copying any code into our tree.

Key questions.

1. Which specific client or partner is demanding WSSE, and can they support a signed-request or OAuth2 alternative instead?
2. Does the requirement mandate the exact UsernameToken digest, or only "stateless header auth"? If the latter, we control the algorithm and avoid the plaintext-password problem entirely.
3. What is the actual credential set — service-to-service API keys, or end-user passwords? This determines whether the digest variant is even viable.
4. Is there a hard deadline tied to a contract, and who owns the fork long-term?

Integration Approach

Stack fit. Poor as a dependency, adequate as a pattern source. Target implementation: a WsseAuthenticate middleware registered on the relevant API route group, delegating credential lookup to a dedicated WsseCredential model (client id, secret/key, active flag, allowed clock skew), with Illuminate\Support\Facades\Cache backed by Redis for the nonce store. Do not attempt to graft Symfony's AuthenticationProvider semantics onto Laravel's Guard; a middleware that resolves the client and calls Auth::setUser() (or simply authorizes the request) is simpler and matches Laravel idioms.

Migration path. Treat this as greenfield server-side implementation, not a migration:

1. Spike (1–2 days): stand up the digest verification against the real client's requests, capture fixtures from the partner's test environment, confirm header formatting and encoding quirks.
2. Protocol conformance suite: cover valid digest, wrong password, expired Created, replayed nonce, malformed Base64, missing header, clock skew at both boundaries.
3. Shadow mode: log-only middleware in production to measure real traffic shape and skew before enforcing.
4. Enforce, then decommission any interim shared-secret basic auth.

Compatibility. Package itself: incompatible with modern PHP/Symfony, untestable on our matrix — record as "reference only." Our implementation: PHP 8.2/8.3, Laravel 10/11, Redis 7, PHPUnit/Pest. If a Symfony service ever needs to consume the same API, the middleware logic ports cleanly to a Symfony listener, so keep the digest/verification code framework-agnostic in a small Wsse support class.

Sequencing. Lock the algorithm decision (spec digest vs. HMAC variant) before implementation — it drives the credential schema and cannot be changed later without breaking clients. Then nonce store, then middleware, then conformance tests, then shadow rollout. Coordinate the enforce step with the partner's release calendar.

Operational Impact

Maintenance. We own 100% of it. Budget ~2–4 engineering days per year for dependency drift (Laravel major upgrades, Redis client changes) plus incident time. Keeping the surface small — one middleware, one support class, one migration — keeps that number defensible. Do not vendor the bundle's code; rewrite from the spec so we are not carrying GPL/unknown-provenance fragments or dead Symfony scaffolding.

Support. No upstream, no community, no CVE feed. Internal documentation and a named owner are prerequisites, not nice-to-haves. Partner-facing support for digest failures will land on our on-call unless we ship a diagnostic path.

Scaling. The nonce cache is the scaling chokepoint: it must be shared across all app instances and atomic. Use Redis SET key NX EX <skew_window> and treat a failed set as a replay. Size at roughly one key per authenticated request within the skew window — trivial volume, but it makes Redis a hard dependency on the auth path. Horizontal scaling of the app tier is otherwise unaffected; the scheme is stateless apart from the cache.

Failure modes.

• Redis unavailable: fail closed (401/503) or you have an auth bypass. Decide explicitly and alert on it.
• Clock drift between client and server: manifests as intermittent, hard-to-reproduce 401s. Log both timestamps at debug level and publish the tolerated skew to the partner.
• Nonce store eviction under memory pressure: silently reopens replay windows; monitor eviction counts.
• Plaintext/reversible credential store (if spec digest is used): a database read becomes a full credential compromise. Scope these credentials to API access only, never user passwords, and rotate on a schedule.
• Opaque failures: "invalid digest" is a single error for many causes — build structured logging (client id, reason code) from day one.

Ramp-up. Low individual learning cost: the protocol is well documented and the code surface is a few hundred lines; a mid-level engineer is productive in a day. The organizational cost is higher — this is a legacy auth scheme with a permanent ownership tail and no vendor to escalate to, so it should be adopted only where a partner contract forces it, and documented as a deliberate exception to our standard auth stack.