Web Services Security, Part 3

In the first article of this series, I explained why traditional network firewalls are inadequate to provide security to web service applications, which is why we need to implement web service security at the XML messaging layer.

In the second article, I discussed signed and encrypted XML messages and a B2B scenario to elaborate the application of XML signature and encryption in web services. At the end of the second article, I introduced Web Services Security (WSS) and explained how WSS applies XML signature and XML encryption to SOAP messages. I also introduced the concept of security tokens and demonstrated the use of digital certificates as security tokens in WSS messages.

In this article I discuss XML-based authentication and the sharing of authentication information across different applications, known as Single Sign-On (SSO). The Security Assertions Markup Language (SAML, often pronounced "sam-ull") from OASIS helps reach this goal by wrapping authentication information in an XML format.

What is Authentication?

For our purposes, authentication means verifying the identity of a user. When you check your e-mail, you enter your username and password to get authenticated. It is assumed that you have kept your password confidential. Therefore the knowledge of your password is used to make sure that you are the one who is trying to check your email.

Similarly, in the second article I demonstrated the use of certificates as authentication tokens. Recall from Listing 9 of the second article that an X509 certificate was wrapped within the SOAP header of the GetSepcialDiscountedBookingForPartners method call. The certificate was actually a security token (just like a password) that the recipient of the WSS message can use in order to authenticate the user before allowing specially discounted rates for booking.

Sharing of Authentication Information

A security token is presented to a gatekeeper in order for a user to get authenticated. Now imagine that the gatekeeper is guarding the main gate of a large building with many offices. Visitors are required to show their ID cards and get authenticated at the main gate. The gatekeeper checks the ID card by matching it with his internal record and then allows the visitor to enter the building.

Let's suppose that you want to visit several offices in the building. Each office has an entrance with a gatekeeper guarding the entrance of each office. You need to get authenticated at the entrance of each office. The gatekeeper at the entrance of each office repeats the same authentication act.

What if individual offices in the building trust the authentication performed by the gatekeeper of the main gate? The building will become a trusted domain, of which each individual office will be a part. Naturally if this type of trust exists between different offices, they would like to share the processing load of the authentication act.

A possible solution to allow sharing of authentication information is to issue a temporary identification badge to a visitor at the main gate of the building. The gatekeeper at the main gate will issue a badge to each visitor after successful authentication. The identification badge will have a short expiry. The visitor will show the identification badge while entering each office. The office gatekeeper will check the validity of badge before allowing or disallowing a person to enter the office.

Such scenarios are common in Enterprise Application Integration and B2B applications. Whether applications are running within or across the boundaries of an enterprise, the sharing of authentication information forms an important part of application integration effort. Naturally, the sharing of authentication information prevents each application from having to perform the entire authentication process.

A B2B Application Scenario

Let's suppose that the hotel and tour operator enterprises that we introduced earlier in this series of articles are part of an electronic marketplace. The marketplace provides the basic B2B and B2C enabling framework, and different enterprises as well as final customers (e.g. tourists) use the framework to do business on the electronic marketplace. As part of the enabling framework, the marketplace provides financial services by maintaining relations with financial institutions. The marketplace issues its own credit cards and credit limits, while customers and enterprises can open their accounts with the marketplace and can perform monetary transactions.

As a result of providing financial services, the marketplace is in a position to issue assertions about different enterprises doing business on the marketplace. In this marketplace context, we will assume the following:

• The hotel and tour operator businesses are trusted business partners of the marketplace.
• The hotel and the tour operator are new to each other (i.e. they have no relationship of trust with each other).
• The tour operator wants to enjoy the specially discounted rates that the hotel offers.

So the tour operator will ask the marketplace to issue an identification and security badge (an assertion) stating that the tour operator is a trusted business partner of the marketplace. Once the tour operator gets the assertion, it will present it to the hotel and ask them to let it enjoy the specially discounted rates.

SAML is an XML vocabulary that defines the syntax necessary to exchange authentication information between applications. The authentication information is exchanged in the form of assertions. The marketplace is responsible to provide assertions about its trusted business partners and therefore acts as an SAML assertion authority.

The tour operator application will request an assertion from the marketplace (a SAML authority). The tour operator is a requester application and the subject of the assertion as well. After getting the assertion from the marketplace, the tour operator will wrap the assertion in a WSS message and send the WSS message to the hotel application. The hotel will rely on the assertion to decide whether to allow the tour operator the special discount or not. The hotel is a relying party.

The rest of the article discusses how all this is accomplished using SAML and WSS.

We have three areas to explain and demonstrate.

1. The syntax of a SAML assertion.
2. How an application will request an SAML authority for the issuance of an SAML assertion.
3. Using SAML assertions in WSS applications.

The Syntax of a SAML Assertion

Take a look at Listing 1. It wraps an authentication statement in the format of an SAML assertion. An authentication statement specifies the outcome of an act of authentication which took place in the past. The marketplace (an SAML authority) authenticates a user and issues the security badge (an assertion).

At this point, we are not concerned with the actual process of authentication that took place prior to issuing the assertion. The authentication process is a private issue for the marketplace and may be comprised of one of several methods: for example, a simple username password authentication that you use while checking email or the certificate-based WSS authentication that we demonstrated in Listing 9 of the second article.

However it is important that all applications relying on the SAML assertion issued by the marketplace trust the authentication process. That's why it will contain information regarding the means which were used to authenticate the user.

The assertion from Listing 1 can be stated in English thus:

The entity (person or an organization) named "MyTourOperator" is the owner of a public key named "MyTourOperatorKey". The asserting authority has authenticated MyTourOperator using XML digital signatures. This assertion is valid from time1 until time2.

Here's an explanation of the XML format of Listing 1. The root Assertion element wraps three important bits of information: a Conditions element, an AuthenticationStatement element, and a ds:Signature element.

The Conditions element specifies two conditions for this assertion. The NotBefore attribute tells the time before which the assertion is not valid. Similarly, the NotOnOrAfter attribute specifies the time after which the assertion expires. (Both times are of dateTime data type according to the W3C Schema Datatypes specification.)

The AuthenticationStatement states the outcome (the final result) of an authentication process.The other two elements (Conditions and ds:Signature) are included for helper tasks.

Look at the AuthenticationStatement structure in Listing 1. It contains two attributes and one child element. The first attribute of the element is AuthenticationMethod. The value of this attribute that we have used in Listing 1 (urn:ietf:rfc:3075) specifies that we used XML signatures to authenticate the subject. The SAML specification defines identifiers for several authentication methods (refer to section 7 of the SAML core specification for a list of available authentication methods). The second attribute (AuthenticationInstant) specifies the instant of time when the authentication took place.

The only child element is an element named Subject, identifying the subject of this assertion. In our case, the tour operator is the subject. The Subject element contains two child elements, a NameIdentifier element and a SubjectConfirmation element.

The NameIdentifier element specifies the name of the subject. In addition to the name, we can optionally specify a name qualifier as value of the NameQualifer attribute. The concept of name qualifiers allows multiple username issuing authorities to work without causing any duplication. Each authority will issue names with its own name qualifier. This concept is similar to the concept of XML namespaces, in which each namespace has its own set of elements and two namespaces can have the same element name without producing any ambiguity.

Now look at the SubjectConfirmation element, which specifies the relationship between the subject of an assertion and the author of the message that contains the assertion. Listing 1 is just an assertion. The last section of this article will demonstrate how to wrap this assertion in a WSS message. For the moment, just note that the tour operator is the subject of this assertion and the tour operator itself will eventually author the WSS message to request specially discounted booking rates from the hotel. Therefore, we are interested in the simple case when the subject and the author of the message are the same.

In order to specify that the subject of an assertion and the author of the message that contains the assertion are the same, the SubjectConfirmation element includes two elements. The first is a ConfirmationMethod element and the second is a ds:KeyInfo element. The two elements form a pair inside the SubjectConfirmation element.

The ConfirmationMethod element specifies a method that the hotel (a relying party) will use to confirm the relationship between the subject of the assertion and the author of the message that contains the assertion. Look at the content of the ConfirmationMethod element. It is a string which says urn:oasis:names:tc:SAML:1.0:cm:holder-of-key; it identifies a method known as "holder of key", which means that the subject is the owner of a cryptographic key (e.g. a public key). The key is either included in or referenced from the accompanying ds:KeyInfo element. The ds:KeyInfo element wraps a key named "MyTourOperatorKey".

If the author of a message that contains an assertion can prove that it owns this key, then the relying party can be sure that the author is really the subject of the assertion.

The last section of this article will demonstrate one possible way for the tour operator to prove that it owns the public key named "MyTourOperator".

We have discussed all elements of Listing 1, except the last child of the root Assertion element, which is a ds:Signature element. As readers might have already guessed, this element is actually the signature of the assertion authority (the marketplace). The purpose of including the signature of the issuing authority is to allow the recipient of the assertion to verify that the assertion is not fake.

Pages: 1, 2

Next Page