Web Services Security, Part 4
In this fourth and final article of this series, I will put the pieces together to demonstrate the simultaneous use of all the four XML security standards, XML signature, XML encryption, WSS, and SAML, in one application. Here we will discuss two important and typical web services security application scenarios and learn two things: first, how the different web services security standards work together in an XML firewall to protect SOAP servers; second, what the different types of security tokens that you can use in WSS messages are and how they are related to digital signatures and encrypted data. -->
XML firewalls for Web Services Security
Have a look at Figure 1, which shows three actors engaged in an exchange of secure SOAP messages. You can see the following sequence of events in Figure 1.
|
| Figure 1. |
Step 1
A tour operator wants to book some rooms with a partner hotel at specially
discounted rates. The tour operator and the hotel have existing business
relationship. The tour operator's request for special discount should
accompany some proof that the request is coming from a trusted business
partner. For this purpose, the tour operator will include a security
token in the GetSpecialDiscountedBookingForPartners request.
Listings 1 to 4 show the same GetSpecialDiscountedBookingForPartners
request with different types of security tokens. Let's have a look at
the security tokens one by one.
Have a look at the wsse:Security element within the SOAP
Header of Listing 1. The first
child element of the wsse:Security element is a wsse:UsernameToken
element. The wsse:UsernameToken element wraps a username
security token, very much like the username and password pairs that
you use to check your e-mail.
The wsse:UsernameToken element contains three child elements,
which together form the username token. The token is meant to prove
the identity of the author of Listing
1.
The first child element of the wsse:UsernameToken element
is a wsse:Username element, which wraps a username (ATrustedPartnerTourOperator)
as its contents.
The second child element of the wsse:UsernameToken element
is a wsse:Nonce element, which contains some binary data
(a sequence of octets). The third child is a wsu:Created element. The
Nonce and Created elements are used here in
pair. In order to understand what Nonce and Created
elements do, we need to understand the concept of keys generated form
hashing (or message digest) functions.
Digest calculation
Let's suppose the tour operator and the hotel know a shared secret, just like your email account password, which is a shared secret between you and your email service provider. The tour operator can apply a digest algorithm to its password and arrive at a digest value. It can then use that digest as a symmetric key to encrypt or sign a message and send the message to the hotel. The hotel will use its knowledge of the shared secret to repeat the digest calculation and use the digest value (as a key) for decryption and signature verification.
What is the advantage of doing digest calculation? Why not use the password
itself as a symmetric key for encryption and signing? In fact there's
hardly an advantage if the tour operator is not using Nonce
and Created elements.
The Nonce element wraps randomly generated sequence of
bytes, while the Created element wraps a timestamp showing
the time when the message was authored. The tour operator will combine
the contents of these elements with his password to generate the digest
value.
Combining these two elements in digest calculation has the advantage
that it becomes difficult for hackers to guess the password from encrypted
data or signatures. If the tour operator uses only its password for
digest calculation, he will arrive at the same key every time he performs
the digest calculation. Using the Nonce and Created
elements in digest calculation will result in different keys, provided
the tour operator doesn't re-use random numbers for Nonce
element in a specified period of time.
Such keys derived by hashing a shared secret are known as HMAC (Hashed Message Authentication Code) keys.
Notice that the ds:Signature element in Listing
1 has a ds:KeyInfo element, which contains a wsse:SecurityTokenReference
element. The wsse:SecurityTokenReference element has a
child wsse:Reference element, whose URI attribute
refers to the tour operator's username security token by means of a
fragment identifier (#TourOperatorUsernameToken). We covered
the use of wsse:SecurityTokenReference element in the last
section of the second
part of this series of articles.
This means that the tour operator used the key derived from the username token. The hotel's XML firewall will use its knowledge of the tour operator's password to repeat the digest calculation and arrive at the key that the tour operator used to sign the request of Listing 1.
Kerberos ticket
Now have a look at Listing 2, which
contains a binary security token wrapped inside a wsse:BinarySecurityToken
element. We introduced the use of binary security tokens in the last
section of the second article of this series of articles. This time,
we have wrapped a Kerberos ticket in Listing
2.
There are two types of Kerberos tickets, Ticket Granting Ticket (TGT) and a Service Ticket (ST). A Kerberos Server (also known as Key Distribution Center or KDC) hosts Kerberos ticket issuing services. It issues two types of Kerberos tickets, Ticket Granting Ticket (TGT) and a Service Ticket (ST). Let's discuss how the tour operator will use the two types of tickets to get authenticated with the hotel.
The tour operator will get a TGT from an Authentication Service (AS) hosted by the KDC. The tour operator will keep the TGT confidential and will never give it to anyone, as the TGT contains confidential information, such as a session key. If stolen, this information can be used to impersonate the tour operator.
The session key inside the TGT has a limited life time and it proves that the holder is an authenticated party for the duration of a single session. The tour operator will present the TGT to a Ticket Granting Service (TGS) at the same KDC. The TGS will provide a service ticket to the tour operator, which the tour operator can send to anyone (such as the hotel). The same TGT can be used to get as many service tickets as needed from the same KDC.
Once the tour operator has the service ticket, he will wrap the service
ticket inside the wsse:BinarySecurityToken element of Listing
2 and send Listing 2 to the
hotel.
The service ticket contains all information needed to specify the address of the KDC who issued the ticket and the entity to whom the service ticket was issued (in our case, the tour operator). The hotel will extract the service ticket from Listing 2 and get it authenticated or validated form the KDC who issued the ticket. If the ticket is successfully validated (and the hotel trusts the KDC), the hotel can be sure that the sender was really the tour operator.
In order for this scheme of using Kerberos tickets, it is necessary that both the tour operator and the hotel trust the KDC.
Note that the process of issuing a TGT, getting a service ticket, and validating the service tickets is not part of WSS. WSS only defines how to wrap a Kerberos ticket in a BinarySecurityToken element. The rest of the details are covered by the Kerberos specification that IETF has defined. We have included some links in the resources section, where you can find more details about using Kerberos tickets.
Security token reference
Now look at Listing 3, which does
not contain any security token. Instead the wsse:Security
element has a wsse:SecurityTokenReference child element.
The wsse:SecurityTokenReference element contains a wsse:Reference
element, which has a URI attribute whose value (http://www.myTourOperator.com/keys/Key1)
points to an HTTP address.
This means that the key that the tour operator used for signature is
the security token and it is available from the address that the URI
attribute of the wsse:Reference element specifies. The
hotel will dereference the URI to get the security token before being
able to validate the signature.
Key identifier
Listing 4 shows another variety
of using security tokens in a WSS message. Juts like Listing
3, Listing 4 also does not
contain any security token. Instead it contains a wsse:SecurityTokenReference
element, which in turn contains a wsse:KeyIdentifier element.
The wsse:KeyIdentifier element wraps an identifier that
identifies the key used to produce the signature. It is assumed that
the hotel can uniquely identify the key from the identifier and fetch
the key as well. This means that the key identification mechanism is
mutually agreed between the tour operator and the hotel. For example,
the tour operator and the hotel may have already exchanged keys through
any mechanism and agreed on identifiers to identify the keys.
Notice the ValueType attribute of the wsse:KeyIdentifier
element, which identifies type of the key. In our case, the value of
this attribute is "wsse:X509v3", which means the key is
actually an X509 certificate.
We have seen four alternate ways of wrapping or referencing security tokens using WSS. This covers step number 1 of Figure 1. The tour operator can send any of the messages shown in Listings 1 to 4 to the hotel's XML firewall.
Step 2
Notice from Figure 1 that step 2 occurs inside
the XML firewall, which guards the hotel's SOAP server. The XML firewall
receives the request, which contains a GetSpecialDiscountedBookingForPartners
method invocation call. The XML firewall knows that before it can let
the request make its way to the SOAP server, it has to check two things:
- Authentication: In order to check the requester's identity, the XML firewall will extract the security token from the incoming request and process it to check who sent this message.
- Message integrity: Making sure that the message received is exactly the one that was sent by the sender, and that no one has altered the message while on its way over the Internet. The XML firewall will validate the signature contained in the WSS message to check the integrity of the message. We have already discussed the details of this in part 2 of this series.
After successful authentication and message integrity check, the XML firewall will forward the SOAP request to the SOAP server. Listing 5 is the SOAP request that the XML firewall will send to the SOAP server. Notice that Listing 5 is the result of simply removing the SOAP Header from any of the Listings 1 to 4. This means that the SOAP server will receive only the SOAP Body without any security information, because it does not need any security information. The security information has already been utilized by the XML firewall for user authentication and message integrity.
At this point we would also like to clarify another point. We have shown the SOAP server and the XML firewall as two separate entities. This is because we are explaining web services security as a topic independent from SOAP. In real practice, an XML firewall may or may not be a separate entity i.e. some vendors may want to integrate their XML firewall and SOAP implementations. Let us consider both cases separately.
In case the XML firewall and the SOAP server are two separate entities, they will most likely be listening on two different addresses. For example, if we are considering HTTP communications between the tour operator and the hotel, the hotel may have used the following two HTTP addresses:
For XML firewall: http://www.myHotel.com/XMLfirewall
For SOAP server: http://localhost/SOAPServer
In order for the scheme shown in Figure 1 to work, the hotel will need to make sure that its web server does not allow any external client (e.g. web clients) to access the SOAP server. The security policy of the web server will allow only the XML firewall to reach the SOAP server and all other requests to the SOAP server will either be rejected or be routed to the XML firewall instead of the SOAP server.
On the other hand, the XML firewall and the SOAP server may also be integrated as one product. In this case, the XML firewall will listen to all incoming requests and the SOAP server will simply be a part of the over-all application (e.g. as a collection of Java classes), not capable of receiving requests from any client other than the XML firewall.
Step 3
Now the XML firewall sends the SOAP request of Listing 5 to the SOAP server.
Step 4
The SOAP server invokes the web service and prepares the SOAP response that goes back to the SOAP server.
Step 5
The SOAP server sends the response back to the XML firewall. The SOAP server's response back to the SOAP server is shown in Listing 6.
Pages: 1, 2 |
