Someone always inherits that one legacy service running on SOAP. You know the one. It hums quietly in the corner, immune to your shiny new REST policies and OAuth flows. Now security asks you to federate it with Keycloak. Welcome to the oddly specific world of Keycloak SOAP integration.
Keycloak handles modern identity and token-based security beautifully through OIDC and SAML, but real infrastructures have baggage. SOAP still powers plenty of enterprise backends, and those systems want to verify users and permissions too. The trick is connecting Keycloak’s identity tokens with the SOAP layer so neither team has to rewrite history.
In a typical workflow, Keycloak issues an access token after authentication. A service broker or adapter then maps that token into a SOAP-compatible header or WS-Security envelope. The SOAP endpoint validates the assertion using Keycloak’s public keys or an intermediary identity gateway. From there, your service can recognize the caller, apply roles, and keep an auditable trail — without forcing a rewrite.
Think of it as plumbing between generations of security protocols. Old pipes, new water.
How do you integrate Keycloak with a SOAP service?
Use Keycloak to handle login and token issuance, then configure your SOAP service or proxy to validate those tokens via WS-Trust or a security handler. The client makes the SOAP request including the signed token, and the server checks it against Keycloak’s public key endpoint. No human approval chain required, just trust that flows automatically.
Best practices matter here. Use short token lifetimes and enforce HTTPS everywhere. Rotate service credentials and verify the signature before processing any payload. Map Keycloak roles to SOAP service permissions to keep least-privilege authorization intact.