WS-Trust over OAuth: a third transport for the OpenID server, for the estate that runs on SOAP

Description and use

redb.Identity added a WS-Trust facade, enabling SOAP clients to obtain and use OAuth tokens without code changes, while maintaining a single token model and compatibility with HTTP and gRPC.

Problem

Estates that rely on SOAP and WCF/CXF buses need an OAuth-compatible token service without adopting HTTP-based OAuth flows, which require tooling and habits they lack.

Outcome

A single redb.Identity instance now supports three transports (HTTP, gRPC, WS-Trust) with a unified token model, allowing legacy SOAP estates to integrate OAuth tokens without new tooling.

Workflow

• 1. Serve WSDL via GET on the WS-Trust endpoint
• 2. Register a client over HTTP (/connect/register)
• 3. Issue a token via SOAP Issue operation (UsernameToken with client credentials)
• 4. Validate the token via SOAP Validate operation
• 5. Cancel the token via SOAP Cancel operation
• 6. Re-validate to confirm revocation
• 7. Attempt to use the token over HTTP to access a protected endpoint
• 8. Observe that the same token is accepted over HTTP
• 9. Test error handling: send wrong secret, observe soap:Fault with wst:FailedAuthentication
• 10. Verify rate limiting and other core verdicts are correctly mapped to WS-Trust faults

Evidence

redb.Identity gained a WS-Trust facade: Issue, Validate, Cancel, Renew on the same core routes.

Source

A token minted over SOAP is accepted over HTTP and gets the same verdict there.

Source

redb.Identity.Soap refuses to start without TLS: WS-Security UsernameToken carries the client secret in clear text.

Source