All posts

Our Identity Protocol Debugger Now Supports WS-Trust

There are moments in software development when you ask yourself an important question:

“Should I spend time implementing a SOAP protocol designed before smartphones existed?”

Apparently, my answer was yes.

I’m happy to announce that the Identity Protocol Debugger now supports WS-Trust, adding another major identity protocol to the growing collection of debugging tools available at IDPTools.com.

If you’re one of the approximately fourteen people left on Earth integrating WS-Trust, this one’s for you.

Why WS-Trust?

WS-Trust occupies a unique place in identity history.

Long before OAuth2, OpenID Connect, and JWTs became the lingua franca of modern authentication, enterprise identity revolved around SOAP web services and the WS-* family of specifications.

At the center of that ecosystem was the Security Token Service (STS).

Rather than authenticating directly with every application, a client would request a security token from the STS using WS-Trust. That token could then be presented to one or more relying parties, enabling federation across organizational boundaries.

It was, in many ways, the spiritual predecessor to today’s OAuth 2.0 Authorization Servers.

Supported Versions

The Identity Protocol Debugger now supports every significant version of the protocol.

  • WS-Trust 1.0
  • WS-Trust 1.1
  • WS-Trust 1.2
  • WS-Trust 1.3
  • WS-Trust 1.4

While intermediate committee drafts (1.1 and 1.2) existed during the standardization process, production deployments overwhelmingly implemented one of the three versions above.

Whether you’re debugging an early Microsoft implementation or a modern OASIS-compliant Security Token Service, the debugger has you covered.

More Than Just XML

If you’ve ever attempted to troubleshoot WS-Trust using browser developer tools, you’ve probably experienced at least one of the following:

  • XML namespaces spanning half a page
  • Digital signatures buried three elements deep
  • Base64-encoded binary security tokens
  • Canonicalization transforms that invalidate signatures when a single space changes
  • SOAP Faults that somehow contain less useful information than a 404

The Identity Protocol Debugger is designed to make these messages understandable.

Instead of staring at a wall of XML, you can inspect requests and responses as structured protocol messages, making it much easier to understand what’s actually happening during token issuance and exchange.

Request Types

The debugger understands the major WS-Trust operations, including:

  • RequestSecurityToken (RST)
  • RequestSecurityTokenResponse (RSTR)
  • Token issuance
  • Token renewal
  • Token validation
  • Token cancellation
  • Token exchange

Whether you’re issuing SAML assertions or exchanging existing tokens, the debugger exposes the underlying protocol details that are often hidden by client libraries.

Why Does This Still Matter?

It’s tempting to assume WS-Trust disappeared the moment OAuth arrived.

It didn’t.

Many enterprise environments continue to depend on WS-Trust every day.

Examples include:

  • Active Directory Federation Services (AD FS)
  • Microsoft WCF applications
  • SharePoint
  • Dynamics deployments
  • Legacy enterprise service buses
  • Government identity infrastructures
  • Long-lived enterprise SOAP services

These systems aren’t going away overnight.

In fact, many organizations continue migrating from WS-Trust to OAuth 2.0 and OpenID Connect, meaning engineers often find themselves supporting both generations of identity protocols simultaneously.

Another Piece of the Identity Puzzle

The goal of the Identity Protocol Debugger has always been simple:

Make identity protocols easier to understand.

Whether you’re working with:

  • SAML 2.0
  • OAuth 2.0
  • OpenID Connect
  • OpenID Federation
  • WS-Trust

…the debugger aims to expose the protocol itself rather than hiding it behind SDKs and frameworks.

Because when something breaks, it’s almost always the protocol that tells the real story.

Looking Forward

Identity continues to evolve.

Today’s engineers may spend their mornings debugging SAML, their afternoons implementing OAuth, and their evenings trying to understand SD-JWT Verifiable Credentials.

Tomorrow’s protocols will undoubtedly introduce new acronyms, new specifications, and new opportunities to wonder why XML namespaces seemed like such a good idea twenty years ago.

Until then, WS-Trust joins the growing family of protocols supported by the Identity Protocol Debugger.

Happy debugging — and may all of your security tokens be valid, your signatures verify successfully, and your SOAP Faults contain enough information to avoid opening Wireshark.

Check out the GitHub repo.

Notes

  • AI / GenAI / ChatGPT / etc were not used to generate the text of this article.
  • ChatGPT was used to generate the images.
  • I used em dashes in my writing before the current GenAI wave was a thing. Not planning on changing now.
  • Names have been changed to protect the guilty.
  • None of the hostnames or users used in examples actually exist.
  • Feel free to post any comments or suggestions below.

Originally published on Medium.