Trust, Access Control, and Rights for Web Services Part 1 - RequestSecurityToken
(Page 5 of 9 )

Now that you know how the model is supposed to work and you understand the key relationships between Web service provider, requestor, and Security Token Service, it's time to look at the two key WS-Trust elements needed to perform its prescribed functions: <RequestSecurityToken> and <RequestSecurityTokenResponse>.

<RequestSecurityToken>

Listing 9.1 shows a request to have a security token issued.

Listing 9.1 The <RequestSecurityToken> Element

<RequestSecurityToken>
  <TokenType>...</TokenType>
  <RequestType>...</RequestType>
  <Base>...</Base>
  <Supporting>...</Supporting>
</RequestSecurityToken>

Now let's explore each element that makes up a <RequestSecurityToken> element.

<TokenType> The optional <TokenType> element describes the type of security token requested, specified as a QName (see the following section). That is, it describes the type of token that will be returned in the <RequestSecurityTokenResponse> message.

<RequestType> The <RequestType> element is used to indicate, using a QName, the action that is being requested. The following QNames are predefined:

QName	Description
wsse:ReqIssue	Issue security token
wsse:ReqValidate	Validate security token
wsse:ReqExchange	Exchange security token

<Base> The optional <Base> element has the same type as the <SecurityTokenReference> element and references the base (primary) tokens that are used to validate the authenticity of a request. In general, this element isn't used because signatures provided on the request prove the right to make the request.

<Supporting> The optional <Supporting> element has the same type as the <SecurityTokenReference> element and references the supporting tokens that are used to authorize this request. Typically, this element is used to identify tokens in a certificate authority. It is not required to specify any or all supporting tokens; it is simply a hint or aid to the recipient service.

The example in Listing 9.2 shows an X.509 security token being requested based on the security token located in the <Security> header with the ID "myToken". This token specifies a username, and a signature is placed over the request using a key derived from the password (or password equivalent), nonce, and time stamp.

Listing 9.2 - Requesting an X.509 Security Token Based on a Key Derived from a Password

<S:Envelope xmlns:S="..." xmlns=".../secext" xmlns:wsu=".../utility>
  <S:Header>
    ...
    <Security>
      <UsernameToken wsu:Id="myToken">
        <Username>NNK</Username>
        <Nonce>FKJh...</Nonce>
        <wsu:Created>2001-10-13T09:00:00Z </wsu:Created>
      </UsernameToken>
      <ds:Signature xmlns:ds="...">
        ...
      </ds:Signature>
    </Security>
    ...
  </S:Header>
  <S:Body wsu:Id="req">
    <RequestSecurityToken>
      <TokenType>wsse:X509v3</TokenType>
      <RequestType>wsse:ReqIssue</RequestType>
      <Base>
        <Reference URI="#myToken"/>
      </Base>
    </RequestSecurityToken>
  </S:Body>
</S:Envelope>

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: RequestSecurity TokenResponse >>
 

More Security Articles
More By Rosenberg, Remy

Comments On: Trust, Access Control, and Rights for Web Services Part 1

>>> Be the FIRST to comment on this article!