Home arrow Security arrow Page 6 - Trust, Access Control, and Rights for Web Services Part 1

RequestSecurity TokenResponse - Security

Several other important standards are derived from and are complementary to WS-Security; they relate to such fundamental security topics as trust, access control, and rights. In this chapter, we review the family of WS-Security–related technologies. This is part 1 of chapter 9 from Securing Web Services with WS-Security, by Rosenberg and Remy (ISBN 0672326515, Sams, 2004).

TABLE OF CONTENTS:
  1. Trust, Access Control, and Rights for Web Services Part 1
  2. Building Blocks
  3. WS-* Security Specifications for Trust Relationships
  4. Prior to Having Secure Communications...
  5. RequestSecurityToken
  6. RequestSecurity TokenResponse
  7. WS-* Security Specifications for Interoperability
  8. SecurityContextToken
  9. WS-* Security Specifications for Integration
By: Rosenberg, Remy
Rating: starstarstarstarstar / 8
July 26, 2004

print this article
SEARCH DEV SHED

TOOLS YOU CAN USE

advertisement

<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.

SamsThis 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.



 
 
>>> More Security Articles          >>> More By Rosenberg, Remy
 

blog comments powered by Disqus
escort Bursa Bursa escort Antalya eskort
   

SECURITY ARTICLES

- Secure Your Business for Data Privacy Day
- Google Testing Security Fob Password Alterna...
- Security News Highlights Concerns
- Going to Extremes for Data Security
- Skipfish Website Vulnerability Scanner
- Critical Microsoft Visual Studio Security Pa...
- US Faces Tech Security Expert Deficit
- LAN Reconnaissance
- An Epilogue to Cryptography
- A Sequel to Cryptography
- An Introduction to Cryptography
- Security Overview
- Network Security Assessment
- Firewalls
- What’s behind the curtain? Part II

Developer Shed Affiliates

 


Dev Shed Tutorial Topics: