How WS-Trust Issues and Validates Security Tokens

The WS-Trust specification provides a standardized framework for establishing trust, issuing, renewing, and validating security tokens in XML-based web services. Built as an extension to WS-Security, WS-Trust defines messaging protocols that enable disparate systems to request and exchange security tokens securely. By utilizing a trusted third-party known as a Security Token Service (STS), WS-Trust allows systems with different security mechanisms or across different trust boundaries to interoperate seamlessly.

Core Components of WS-Trust

WS-Trust relies on a three-party model to manage identity and access:

  1. Requestor (Client): The entity requesting access to a target service.
  2. Relying Party (Web Service): The resource provider that requires a valid security token to grant access.
  3. Security Token Service (STS): The trusted authority responsible for issuing, validating, and transforming security tokens.

How WS-Trust Issues Security Tokens

Token issuance occurs when a client needs a specific token format (such as SAML, Kerberos, or X.509) to access a relying party. The process follows these steps:

  1. Request Security Token (RST): The client sends a RequestSecurityToken message to the STS. This message specifies the type of token needed, the target service (AppliesTo), cryptographic key requirements, and claims needed for authorization.
  2. Authentication and Evaluation: The STS authenticates the client using standard WS-Security headers (e.g., username tokens or digital signatures). Once authenticated, the STS evaluates whether the client is authorized to receive the requested token based on security policies.
  3. Request Security Token Response (RSTR): The STS generates the requested token, signs it using its private key, and encapsulates it inside a RequestSecurityTokenResponse message. The response may also include proof-of-possession keys or encrypted keys to allow the client to authenticate with the relying party.
  4. Service Invocation: The client attaches the newly issued token to its SOAP request when calling the target web service.

How WS-Trust Validates Security Tokens

When a relying party receives a SOAP message containing a security token, it must ensure the token is authentic, untampered with, and still valid. Validation can be handled directly or delegated back to the STS:

  1. Validation Request: If the relying party cannot validate the token internally (for example, if it lacks the required certificate or the token format is unfamiliar), it creates an RST message with a Validate action and forwards the received token to the STS.
  2. STS Evaluation: The STS checks the integrity of the token’s digital signature, verifies that the token has not expired, and confirms that the issuing authority is trusted.
  3. Validation Response: The STS responds with an RSTR containing a <wst:Status> element. This element specifies a status code (e.g., Valid or Invalid) along with an optional reason describing the validation result.
  4. Access Determination: Based on the STS response, the relying party either processes the original request or rejects it with a SOAP fault.

Token Exchange and Renewal

Beyond basic issuance and validation, WS-Trust supports token transformation (exchanging one token type for another, such as converting a Kerberos ticket into a SAML assertion) and token renewal, which extends the expiration time of an existing token without requiring a full re-authentication process.