Trust, Access Control, and Rights for Web Services Part 1 - RequestSecurity TokenResponse (Page 6 of 9 )
<RequestSecurityTokenResponse>
The other half of <RequestSecurityToken> is <RequestSecurityTokenResponse>. The syntax for this element is shown in Listing 9.3.
Listing 9.3 The <RequestSecurityTokenResponse> Element
<RequestSecurityTokenResponse>
<TokenType>...</TokenType>
<KeyType>...</KeyType>
<KeySize>...</KeySize>
<wsp:AppliesTo>...</wsp:AppliesTo>
<RequestedSecurityToken>...</RequestedSecurityToken>
<RequestedProofToken>...</RequestedProofToken>
</RequestSecurityTokenResponse>
Let's look at each element in <RequestSecurityTokenResponse> in turn.
<TokenType> The optional <TokenType> element specifies the type of security token returned. Either this element or the optional <AppliesTo> element should be specified. <TokenType> must be provided if a token type other than the requested type is returned.
<KeyType> The optional <KeyType> element specifies the type of key used in the token.
<KeySize> The optional <KeySize> element specifies the size of the key returned.
<wsp:AppliesTo> The optional <wsp:AppliesTo> element specifies the scope to which this security token applies. The WS-PolicyAttachment specification deals with this scope in detail.
<RequestedSecurityToken> The optional <RequestedSecurityToken> element is used to return the requested security token. Normally, this element contains the requested security token, but a security token reference may be used instead. For example, if the requested security token is used in securing the message, the security token is placed into the <Security> header, and a <SecurityTokenReference> element is placed inside the <RequestedSecurityToken> element to reference the token in the <Security> header. Although this element is optional, at least one of <RequestedSecurityToken> or <RequestedProofToken> will be returned unless an error occurs.
<RequestedProofToken> The optional <RequestedProofToken> element is used to return the proof-of-possession token associated with the requested security token. Proof of possession is needed when the client does not provide the public key to use and signs (authenticates) this using the corresponding private key, thereby proving possession. Normally, this element contains the proof-of-possession token, but a security token reference may be used instead. The token (or reference) is specified as the content of this element. For example, if the proof token is used in securing the message, it is placed in the <Security> header, and a <SecurityTokenReference> element is used inside the <RequestedProofToken> element to reference the token in the <Security> header.
Listing 9.4 is a sample response to a request for a security token. In this example, a pre-existing X.509v3 digital certificate, looked up in a directory and encoded into a security token, is returned. As is typical, this example does not return an explicit proof of possession because the client implicitly provided proof of possession by providing the public key to use (and authenticated it using the corresponding private key).
Listing 9.4 <RequestSecurityTokenResponse> Returning a Pre-existing X.509v3 Certificate
<RequestSecurityTokenResponse>
<RequestedSecurityToken>
<BinarySecurityToken ValueType="wsse:X509v3"
EncodingType="wsse:Base64Binary">
MIIEZzCCA9CgAwIBAgIQEmtJZc0...
</BinarySecurityToken>
</RequestedSecurityToken>
</RequestSecurityTokenResponse>
...
WS-Privacy
WS-Privacy is a not-yet-published proposed standard that will use a combination of WS-Policy, WS-Security, and WS-Trust to communicate privacy policies. It is designed to be used by organizations that deploy Web services and require that incoming SOAP requests contain claims that the sender conforms to the service provider's privacy policies. WS-Security encapsulates these claims into security tokens that are verified before accepting any incoming SOAP request.
WS-Privacy will be a standard that allows Web service providers and requestors to state their privacy preferences and organizational privacy practice statements. As of this writing, no public draft of WS-Privacy is available, but from the information that has been published, it will likely be similar to the W3C's Platform for Project Privacy Preferences (P3P).2 P3P was primarily designed for the Web application world (versus the Web services world). It allows an organization to specify its privacy policy in a structured manner and post it on the Web server that is being accessed. Then a P3P-enabled browser can read this policy and compare it to the browser user's privacy preferences. Thus, a user can express her privacy preferences and be notified when she surfs to a site that has privacy practices that conflict with her stated preferences. In a similar manner, WS-Privacy will allow this type of privacy policy exchange and agreement for Web services.
As an example, an individual would state a set of "privacy preferences" that describe what the individual does or does not want to allow applications acting on his behalf to do with his personal information. A calendaring application, working on the individual's behalf, can now access a calendaring service that uses a set of "privacy practice rules" to make statements and decisions about use and disclosure of personal information. The calendar service makes the decision by combining the privacy practice rules with the privacy preferences to determine whether a proposed use or disclosure is permissible.
 This chapter is from Securing Web Services Security with WS-Security, by Jothy Rosenberg and David Remy (Sams, 2004, ISBN: 0672326515). Check it out at your favorite bookstore today.
Buy this book now. |
Next: WS-* Security Specifications for Interoperability >>
More Security Articles
More By Rosenberg, Remy
/ 8 
