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.
- The syntax of a SAML assertion.
- How an application will request an SAML authority for the issuance of an SAML assertion.
- 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
Conditions element, an
AuthenticationStatement element, and a
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.)
AuthenticationStatement states the outcome (the final
result) of an authentication process.The other two elements
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
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 (
specifies the instant of time when the authentication took place.
The only child element is an element named
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
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
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
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
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
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
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