Web Services Trust Model | Understanding Web Services Specifications and the WSE (Pro Developer)

As I have described, authentication is the key step in determining whether or not to fulfill a Web service request. For authentication to succeed, a requesting application must supply a set of credentials, which include claims about the application s identity as well as evidence of proof-of-possession information to back up the claim. Based on the supplied credentials, the Web service decides whether or not to trust the application making the request. To reiterate, in the WS-Security model, claims are made by including security tokens in or referencing these tokens from the Security message header, and these claims are substantiated by using a token s related proof-of-possession information to sign the message. For a username token, proof-of-possession can be either a hashed password or, more securely, an attached digital signature generated using the password, and for an X.509 certificate, proof-of-possession is an attached digital signature created using the private key associated with the certificate.

Even though I have just described how applications are authenticated in the Web services world, this still doesn t mean that a given Web service is able to accept the authentication credentials being presented in order to complete the authentication process. When a Web service must decide whether or not to trust the authentication credentials presented by a requesting application, there are two general trust relationships that come into play, direct trust and brokered trust. In a direct trust relationship, both parties have sufficient information about each to be able to make a determination of trust directly, without the help of an outside party. Shared secrets are an example of a direct trust relationship, where each party has access to the other s proof-of-possession information that can be used to validate the authentication claims. For example, a username security token can be sent in a request along with a digital signature over the message created using the corresponding password or hashed password. Since the message recipient also has a copy of the same password or password hash for the username in the token, it uses its copy to verify the signature, thereby establishing trust.

A direct trust scenario, whether using shared passwords or shared symmetric cryptographic keys, requires some other mechanism for distributing shared secrets that is secure and out-of- band with the Web service itself. This requires that both parties in the Web service interaction, or conversation, have a preexisting relationship. This requirement for secure key exchange before trust can be established can limit the potential for real-time discovery of and access to Web services.

Rather than having a pre-negotiated, direct trust relationship, Web services also need to be able to accept security tokens from a requesting party without any direct knowledge of them. This is the basis of the brokered trust scenario, in which trust between two parties is obtained, or brokered, by a third party. For example, a Web service request can include a security token that has been digitally signed by a security token service (STS), such as a certificate authority (CA). While the token itself identifies the requesting application, the service has no way, on its own, to know whether or not to trust this identity, and all that a digital signature indicates is that the security token was sent with the message and that neither was tampered with. Therefore, in order to trust the sender and authenticate the request, the Web service must trust the third-party service that issued them the security token. In general, this process goes something like this:

A WS-Security-enabled Web service receives a SOAP request message and checks the attached signed security token. If no signed security token is attached, then the message should be rejected.
If the attached signed security token is a binary security token, then the Web service decodes the signed security token into its original binary format.
The Web service checks if it trusts the issuer of the security token and verifies the issuer s signature. If these signatures cannot be verified or if the service has no trust relationship with the token issuer, then the message should be rejected. For an X.509-based security token, the service may optionally validate the certificate chain to find a trusted authority up to the root certificate authority.
Once trust has been established, the signature included with the message must be verified using the validated security token. If the signature cannot be verified for the validated security token, the message should be rejected.
If the previous steps have succeeded, then the trust is established between the message sender and the service, and the request can be fulfilled.

Brokered trust requires that signed security tokens be used, since a signature by a token-issuing authority, known in our discussion as a security token service (STS), provides the basis for this trust model. This trust model is based on authentication mechanisms that use signed, binary security tokens, in which case, the binary security token attached is a Base64 binary representation of an X.509 certificate that is signed by the issuing CA, a Kerberos ticket, or some other binary security token. The WS-Trust specification defines both this trust relationship as well as a SOAP-based mechanism for requesting, validating, and exchanging security tokens.

Signed Security Tokens

Trust relationships are established based on an exchange of signed security tokens. As we saw in Chapter 6, a policy document can be used to indicate to requesting applications what type of signed security tokens are accepted by a Web service for authentication, including such details as which STSs are trusted by the service. In the trust-based Web service security model described in WS- Trust, in order for an application to access resources from a Web service, it needs to take the following steps:

If the Web service implements WS-Policy, the application accesses the Web service s policy document to determine what signed security tokens must be supplied to prove identity to the service and which STSs are trusted.
If already in possession of the required signed security tokens, steps 2 and 3 can be skipped . If a new token is needed to satisfy the Web service s policy requirements, then the application sends a valid RequestSecurityToken message to the STS.
If the request message conforms to the STS policy and it validates the supplied token and signatures made with the token s proof-of-possession, it issues a RequestSecurityTokenResponse message containing the requested token. If the service has doubts about information in a request, it can instead return a challenge in the RequestSecurityTokenResponse message. Only after successfully responding to this challenge will a token be issued.
The application includes the acceptable signed security tokens in the request message to the Web service and uses the private-key portion of the token to sign the message.
The Web service verifies that the message conforms to its policy and that the signatures are valid. Only then will it fulfill the request with an appropriate Web service response message.

Security Token Services

At the core of the WS-Trust model for secure Web services is the STS. The responsibilities of such a service are to issue, validate, exchange, and refresh security tokens. Before a security token is issued to an application, the service must trust the requestor , and this trust is based on a positive authentication using the supplied security tokens and the accompanying digital signatures. By authenticating requests and enforcing policies, an STS behaves like any other Web service.

Both an X.509 Certificate authority (CA) and a Kerberos key distribution center (KDC) can be the starting point for an STS, provided that they implement a Web service-based messaging interface as described in WS-Trust. Of course, some services will be built using a legacy username and password authentication system. You could create your own STS to support a Web service that uses custom security tokens, which is supported by WSE. The WSE also supports the ability to create an STS that distributes security context tokens, as defined by the WS-SecureConversation specification, which I will describe shortly.

Requesting Security Tokens

The messaging exchange for requesting security tokens from a security token Web service is defined in the WS-Trust specification. When requesting a security token, a RequestSecurityToken message is sent to the STS. This request message must contain a security token and proof-of-possession information, usually a digital signature made with a password or secret key, sufficient for the service to make a determination of trust (i.e. authentication). Again, these requirements can be published in the service s policy document. In the following example, RequestSecurityToken message is sent to an STS to obtain an X.509-based security token, where the request includes a username token and is signed using a hash of the password, timestamp, and the nonce (the password itself is not included):

 <soap:Envelope xmlns:wsu="http://schemas.xmlsoap.org/ws/2002/07/utility" 
 xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/12/secext" 
 xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> 
 <soap:Header> 
   
 <wsu:Timestamp> 
 <wsu:Created wsu:Id="Id-0b7e1eb0-0384-4b95-ab30-070e5949f789"> 
 2003-08-09T07:48:33Z 
 </wsu:Created> 
 <wsu:Expires wsu:Id="Id-9edcffb2-548f-402d-a2ac-809ed0228dd5"> 
 2003-08-09T07:53:33Z 
 </wsu:Expires> 
 </wsu:Timestamp> 
 <wsse:Security soap:mustUnderstand="1"> 
 <UsernameToken 
 wsu:Id="#SecurityToken-5cc594bb-44bb-4e47-9377-d8ebc10507e2"> 
 <Username>Jeannine Gailey</Username> 
 <Nonce>F6ocfBSFU6c57d5KGaU=</Nonce> 
 <wsu:Created>2001-10-13T09:00:00Z </wsu:Created> 
 </UsernameToken> 
 <Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> 
 <SignedInfo> 
 <CanonicalizationMethod 
 Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /> 
 <SignatureMethod 
 Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" /> 
 <Reference URI="#Id-454b39ba-fdc7-4f8f-9fbc-9e17e5a66f84"> 
 <Transforms> 
 <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /> 
 </Transforms> 
 <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" /> 
 <DigestValue>R3Iymwi+qZUsVuANDQG/6aREMZQ=</DigestValue> 
 </Reference> 
   
 </SignedInfo> 
 <SignatureValue>VQxRVl9F6ocfBSFU6c57d5KGaUsvB...</SignatureValue> 
 <KeyInfo> 
 <wsse:SecurityTokenReference> 
 <wsse:Reference 
 URI="#SecurityToken-5cc594bb-44bb-4e47-9377-d8ebc10507e2" /> 
 </wsse:SecurityTokenReference> 
 </KeyInfo> 
 </Signature> 
 </wsse:Security> 
 </soap:Header> 
 <soap:Body wsu:Id="Id-454b39ba-fdc7-4f8f-9fbc-9e17e5a66f84"> 
 <wsse:RequestSecurityToken> 
 <TokenType>wsse:X509v3</TokenType> 
 <RequestType>wsse:ReqIssue</RequestType> 
 <wsse:Base> 
 <wsse:Reference 
 URI="#SecurityToken-5cc594bb-44bb-4e47-9377-d8ebc10507e2" /> 
 </wsse:Base> 
 </wsse:RequestSecurityToken> 
 </soap:Body> 
 </soap:Envelope>

Remember that in order to protect the username information, the RequestSecurityToken message should be sent by means of an encrypted transport, like SSL. If the STS authenticates the request, it will return the requested token, in this case, an X.509 certificate encoded as a binary security token in a RequestSecurityTokenResponse message, as follows :

 <soap:Envelope xmlns:wsu="http://schemas.xmlsoap.org/ws/2002/07/utility" 
 xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/12/secext" 
 xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> 
 <soap:Header> 
   
 <wsu:Timestamp> 
 <wsu:Created wsu:Id="Id-0b7e1eb0-0384-4b95-ab30-070e5949f789"> 
 2003-08-09T07:48:33Z 
 </wsu:Created> 
 <wsu:Expires wsu:Id="Id-9edcffb2-548f-402d-a2ac-809ed0228dd5"> 
 2003-08-09T07:53:33Z 
 </wsu:Expires> 
 </wsu:Timestamp> 
 <wsse:Security soap:mustUnderstand="1"> 
 <wsse:BinarySecurityToken ValueType="wsse:X509v3" 
 EncodingType="wsse:Base64Binary" 
 xmlns:wsu="http://schemas.xmlsoap.org/ws/2002/07/utility" 
 wsu:Id="SecurityToken- d8ebc1bb-44bb-4e47-9377-5cc5940507e2"> 
 Ypjr4FOk3IFNSd3lJj6ItzANBgkqhkiG9w0BAQQFADAWMRQwEgukRlDwXbc... 
 </wsse:BinarySecurityToken> 
 <Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> 
 <SignedInfo> 
 <CanonicalizationMethod 
 Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /> 
 <SignatureMethod 
 Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" /> 
 <Reference URI="#Id-454b39ba-fdc7-4f8f-9fbc-9e17e5a66f84"> 
 <Transforms> 
 <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /> 
 </Transforms> 
 <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" /> 
 <DigestValue>R3Iymwi+qZUsVuANDQG/6aREMZQ=</DigestValue> 
 </Reference> 
   
 </SignedInfo> 
 <SignatureValue>SFU6BsmcBleGUDQGzWV73tAPyPkfb...</SignatureValue> 
 <KeyInfo> 
 <wsse:SecurityTokenReference> 
 <wsse:Reference 
 URI="#SecurityToken- d8ebc1bb-44bb-4e47-9377-5cc5940507e2" /> 
 </wsse:SecurityTokenReference> 
 </KeyInfo> 
 </Signature> 
 </wsse:Security> 
 </soap:Header> 
 <soap:Body> 
 <RequestSecurityTokenResponse> 
 <RequestedSecurityToken> 
 <wsse:BinarySecurityToken ValueType="wsse:X509v3" 
 EncodingType="wsse:Base64Binary" 
 xmlns:wsu="http://schemas.xmlsoap.org/ws/2002/07/utility" 
 wsu:Id="SecurityToken-5cc594bb-44bb-4e47-9377-d8ebc10507e2"> 
 MIIBxDCCAW6gAwIBAgIQYpjrw0BAQQFADAWMRQwEgYDVQQDEwtSb290IEFnZ... 
 </wsse:BinarySecurityToken> 
 </RequestedSecurityToken> 
 </RequestSecurityTokenResponse> 
 </soap:Body> 
 </soap:Envelope>

Note that this response, containing the token, is signed so that the client can verify that it was sent by the STS. Again, since a Username token does not facilitate encryption, SSL should be used to safely transport this new security token in the RequestSecurityTokenResponse message. If the initial security token request was secured with a signed security token, then message-level encryption, as described in WS-Security, could instead be used to secure the newly issued security token in the response.

Challenge and Response

If the STS has any reason to doubt the validity of a RequestSecurityToken message that contains a valid token, such as a missing or expired timestamp, the service can attempt to establish trust dynamically using a challenge-response mechanism. In such cases, the STS will send a RequestSecurityTokenResponse message containing a SignChallenge element that specifies the conditions of the challenge. To satisfy this challenge, the requestor must sign a portion of the challenge message using a proof-of-possession token. The part of the message is specified in the Challenge element, which relies on the semantics described in the WS-Policy Integrity element, which I described in Chapter 6. The following is an example of the RequestSecurityTokenResponse containing a challenge to the requestor issued by an STS, where the challenge is to sign the supplied nonce:

 <RequestSecurityTokenResponse> 
 <SignChallenge> 
 <Challenge> 
 <MessageParts 
 xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/12/secext"> 
 GetInfosetForNode(GetHeader(/)/wsse:Security/wsse:Nonce) 
 </MessageParts> 
 </Challenge> 
 </SignChallenge> 
 </RequestSecurityTokenResponse>

To answer the challenge, the requestor includes the new signature in the SignChallengeResponse element in its own RequestSecurityTokenResponse message, as follows:

 <RequestSecurityTokenResponse> 
 <SignChallengeResponse> 
 <Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> 
 <SignedInfo> 
 <CanonicalizationMethod 
 Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /> 
 <SignatureMethod 
 Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" /> 
 <Reference URI="#Id-454b39ba-fdc7-4f8f-9fbc-9e17e5a66f84"> 
 <Transforms> 
 <Transform _ 
 Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /> 
 </Transforms> 
 <DigestMethod _ 
 Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" /> 
 <DigestValue>6aREM R3Iymwi+qZUsVuANDQG ZQ=</DigestValue> 
 </Reference> 
   
 </SignedInfo> 
 <SignatureValue>SFU6BsmcBleGUDQGzWV73tAPyPkfb...</SignatureValue> 
 <KeyInfo> 
 <wsse:SecurityTokenReference> 
 <wsse:Reference 
 URI="#SecurityToken- d8ebc1bb-44bb-4e47-9377-5cc5940507e2" /> 
 </wsse:SecurityTokenReference> 
 </KeyInfo> 
 </Signature> 
 </SignChallengeResponse> 
 </RequestSecurityTokenResponse>

In this case, the key used to sign the message is also included in a security token in the message header. After positively validating the signature to establish trust, the STS can issue the requested security token.

Making Special Requests

WS-Trust specifies additional RequestSecurityToken child elements that enable an application to request special security token functionalities, which includes the following:

Scope Instead of requesting a specific type of token, an application can specify the AppliesTo element to declare the resources for which the requested security token will be used to access. Based on the contents of the AppliesTo element, the STS decides on what type of security token to issue. The AppliesTo element is defined in WS-Policy, and when it is used, the TokenType element should not be used.
Keys When the cryptographic key contained in an issued security token must have certain properties, the following elements can be included in the request:
- RequestKeyType “ specifies the type of key being requested, with a value of either wsse:PublicKey or wsse:SymmetricKey .
- RequestKeySize “ specifies the size of the key being requested.
- RequestSignatureAlgorithm “ specifies the cryptographic algorithm used to sign the RequestSecurityTokenResponse message.
- UsePublicKey “ specifies that the issued token be derived from the requestor s public key, which is specified in the KeyInfo element. If the corresponding private key is used to sign the request, then the signature is referenced in this element s Sig attribute.
- UseKeyRef “ this element contains a SecurityTokenReference that references the key to be used when deriving the requested token. If the corresponding private key is used to sign the request, then the signature is referenced in this element s Sig attribute.
Encryption A requesting application can specify the RequestEncryption or RequestProofEncryption elements to request the returned security token be encrypted, depending on which type of token is being requested.
Delegation The OnBehalfOf element is specified when one party is requesting a security token on the behalf of another. The DelegateTo element specifies that a token is delegated to another entity. A security token or security token reference is included in this element to identify the delegate. To obtain a token that can be delegated to another party, the Delegatable element is specified.
Forwarding To obtain a token that can be forwarded to another party, the Forwardable element is specified.