Once a request for security token (RST) has been made, a client should expect the response (RSTR) to include a security token. The security token should ideally be treated, according to WS-Trust as an opaque structure that does not need to be parsed. An critical information that a client may need, such as the token lifetime, should be communicated in additional elements. While the response could be contained in the header, it is often in the body.
The actual cipher values were remove from the listing above for brevity.
The individual sections need to be expanded but the basic outline is helpful to understand. The actual token is included in the RequestedSecurityToken and we expect that to be signed and encrypted. Hence, we expected the key element child to be "EncryptedData" as described in a previous section. The actual token response is wrapped in a RequestSecurityTokenResponseCollection as an STS could return multiple tokens. For MS CRM, we receive a single token response.
There are a few key parts of the message that come from WS-Trust:
Lifetime: A Timestamp in the header is provided with an Id of "_0". This is the Timestamp mentioned in previous section that is required when using Transport level security. The Timestamp helps prevent replay attacks.
AppliesTo: The token can only be used with a specific endpoint. Although the child element appears to include a URL, it is really a URI of a resource on the server. The token is only good for that URI. In MS CRM, you need a different token for each service, Discovery or Organization.
TokenType: The token type is SAML. If we were to decrypt the token, it would have a SAML XML structure. The SAML version is 1.0. This is a slighly older version as SAML 1.1 is available.
RequestType: The RST requested a token, so the request type is one of "issued."
KeyType: The key inside the SAML token is symmetric.
The next few parts are fairly interesting:
RequestedProofToken: This element contains a base64 encoded key. It is a "proof of possession" token that is used to sign the signature. It is unencrypted but does not need to be decoded from it's base64 format. This token is included as a * BinarySecret which should only be used when Transport level security is available, which it is since HTTPS is being used.
RequestedAttachedReference/RequestedUnattachedReference: A token reference provides a "pointer" to the actual token. Embedding the actual token in the response message is optional in which case a token reference would provided that contains an Id to the token. The Id is issued by the server and is only valid on the server. In the case of MS CRM, the token is returned and a token references are provided. The Ids in each section are identical.