Security is important for any distributed computing environment. But, security is becoming even more important for Web services due to the following reasons:
- The boundary of interaction between communicating partners is expected to expand from intranets to the Internet. For example, businesses increasingly expect to perform some transactions over the Internet with their trading partners using Web services. Obviously, from a security perspective, Internet communication is much less protected than intranet communication.
- Communicating partners are more likely to interact with each other without establishing a business or human relationship first. This means that all security requirements such as authentication, access control, nonrepudiation, data integrity, and privacy must be addressed by the underlying security technology.
- More and more interactions are expected to occur from programs to programs rather than from humans to programs. Therefore, the interaction between communicating partners using Web services is anticipated to be more dynamic and instantaneous.
- Finally, as more and more business functions are exposed as Web services, the sheer number of participants in a Web services environment will be larger than what we have seen in other environments.
Currently, the most common security scheme available for today's Web services is SSL (Secure Socket Layer), which is typically used with HTTP. Despite its popularity, SSL has some limitations when it comes to Web services. Thus, various XML-based security initiatives are in the works to address Web services' unique needs. This article examines those schemes.
First, SSL is designed to provide point-to-point security, which falls short for Web services because we need end-to-end security, where multiple intermediary nodes could exist between the two endpoints. In a typical Web services environment where XML-based business documents rout through multiple intermediary nodes, it proves difficult for those intermediary nodes to participate in security operations in an integrated fashion.
Second, SSL secures communication at transport level rather than at message level. As a result, messages are protected only while in transit on the wire. For example, sensitive data on your hard disk drive is not generally protected unless you apply a proprietary encryption technology.
Third, HTTPS in its current form does not support nonrepudiation well. Nonrepudiation is critical for business Web services and, for that matter, any business transaction. What is nonrepudiation? Nonrepudiation means that a communicating partner can prove that the other party has performed a particular transaction. For example, if E-Trade received a stock transaction order from one of its clients and performed the transaction on behalf of that client, E-Trade wants to ensure it can prove it completed that transaction to an arbitration committee, for example, if a dispute arises. We need some level of nonrepudiation for Web services-based transactions.
Finally, SSL does not provide element-wise signing and encryption. For example, if you have a large purchase order XML document, yet you want to only sign or encrypt a credit card element, signing or encrypting only that element with SSL proves rather difficult. Again, that is due to the fact that SSL is a transport-level security scheme as opposed to a message-level scheme.
During the past few years, the technology industry has been working on various XML-based security schemes to provide comprehensive and unified security schemes for Web services. These schemes include:
- XML digital signature
- XML Encryption
- XKMS (XML Key Management Specification)
- XACML (Extensible Access Control Markup Language)
- SAML (Secure Assertion Markup Language)
- WS-Security (Web Services Security)
- ebXML Message Service
- The Liberty Alliance Project
In this article, I define each of these security initiatives, why each is important, and how they all can work together.
XML digital signature
XML digital signature, like any other digital signing technology, provides authentication, data integrity (tamper-proofing), and nonrepudiation. Of all the XML-based security initiatives, the XML digital signature effort is the furthest along. The W3C (World Wide Web Consortium) and the IETF (Internet Engineering Task Force) jointly coordinate this effort. The project aims to develop XML syntax for representing digital signatures over any data type. The XML digital signature specification also defines procedures for computing and verifying such signatures.
Another important area that XML digital signature addresses is the canonicalization of XML documents. Canonicalization enables the generation of the identical message digest and thus identical digital signatures for XML documents that are syntactically equivalent but different in appearance due to, for example, a different number of white spaces present in the documents.
So why XML digital signature? XML digital signature provides a flexible means of signing and supports diverse sets of Internet transaction models. For example, you can sign individual items or multiple items of an XML document. The document you sign can be local or even a remote object, as long as those objects can be referenced through a URI (Uniform Resource Identifier). You can sign not only XML data, but also non-XML data. A signature can be either enveloped or enveloping, which means the signature can be either embedded in a document being signed or reside outside the document.
XML digital signature also allows multiple signing levels for the same content, thus allowing flexible signing semantics. For example, the same content can be semantically signed, cosigned, witnessed, and notarized by different people.
What is XML Encryption?
The W3C is also coordinating XML Encryption. Its goal is to develop XML syntax for representing encrypted data and to establish procedures for encrypting and decrypting such data. Unlike SSL, with XML Encryption, you can encrypt only the data that needs to be encrypted, for example, only the credit card information in a purchase order XML document:
<purchaseOrder> <name>Alice Smith</name> <address> ... </address> <EncryptedData xmlns='http://www.w3.org/2000/11/temp-xmlenc'> <EncryptionMethod Algorithm="urn:nist-gov:tripledes-ede-cbc"> <s0:IV xmlns:s0='http://somens'>ABCD</s0:IV> </EncryptionMethod> <KeyInfo xmlns='http://www.w3.org/2000/09/xmldsig#'> <KeyName>SharedKey</KeyName> </KeyInfo> <CipherData>A23B45C56</CipherData> </EncryptedData> <prodNumber>8a32gh19908</prodNumber> <quantity>1</quantity> </purchaseOrder>
XKMS stands for the XML Key Management Specification and consists of two parts: XKISS (XML Key Information Service Specification) and XKRSS (XML Key Registration Service Specification). XKISS defines a protocol for resolving or validating public keys contained in signed and encrypted XML documents, while XKRSS defines a protocol for public key registration, revocation, and recovery. The key aspect of XKMS is that it serves as a protocol specification between an XKMS client and an XKMS server in which the XKMS server provides trust services to its clients (in the form of Web services) by performing various PKI (public key infrastructure) operations, such as public key validation, registration, recovery, and revocation on behalf of the clients.
Now let's talk about why we need XKMS. To explain it, I must discuss PKI first. PKI proves important for e-commerce and Web services. However, one of the obstacles to PKI's wide adoption is that PKI operations such as public key validation, registration, recovery, and revocation are complex and require large amounts of computing resources, which prevents some applications and small devices such as cell phones from participating in PKI-based e-commerce or Web services transactions.
XKMS enables an XKMS server to perform these PKI operations. In other words, applications and small devices, by sending XKMS messages over SOAP (Simple Object Access Protocol), can ask the XKMS server to perform the PKI operations. In this regard, the XKMS server provides trust services to its clients in the form of Web services.
XACML stands for Extensible Access Control Markup Language, and its primary goal is to standardize access control language in XML syntax. A standard access control language results in lower costs because there is no need to develop an application-specific access control language or write the access control policy in multiple languages. Plus, system administrators need to understand only one language. With XACML, it is also possible to compose access control policies from the ones created by different parties.
Next up is the Security Assertions Markup Language effort, or SAML, which is being defined by the OASIS (Organization for the Advancement of Structured Information) security services technical committee. The committee aims to outline a standard XML framework for exchanging authentication and authorization information.
In a nutshell, SAML is an XML-based framework for exchanging security information. As a framework, it deals with three things. First, it defines syntax and semantics of XML-encoded assertion messages. Second, it defines request and response protocols between requesting and asserting parties for exchanging security information. Third, it defines rules for using assertions with standard transport and message frameworks. For example, it defines how SAML assertion messages can transport using SOAP over HTTP.
The SAML specification developed three use-case scenarios to drive its requirements and design: single sign-on, distributed transaction, and an authorization service.
Figure 1 shows how SAML is used to enable single sign-on.
Suppose a user logs in to Smith.com and is authenticated. Later, the same user accesses Johns.com. Without single sign-on, the user would typically have to reenter his user identity information to Johns.com. Under the SAML scheme, by sending an SAML assertion request message, Johns.com can ask Smith.com if the user has already been authenticated. Smith.com then sends back an SAML assertion statement indicating that the user in fact has been authenticated. Once Johns.com receives the SAML assertion statement, it allows the user to access its resources without asking the user to reenter his identity information.
Figure 2 illustrates a distributed transaction use-case.
In this case, let's say a user buys a car from Cars.com. The same user then decides to buy automobile insurance from Insurance.com. Now, when the user goes to Insurance.com to buy insurance, the user's profile such as name, address, and credit history, which Cars.com has already collected, can pass to Insurance.com. In this case, Insurance.com sends an SAML assertion request, such as, "Send me user profile information," to Cars.com, and Cars.com sends all the user profile information it knows to Insurance.com in SAML assertion statements.
Figure 3 shows a SAML use-case for an authorization service.
Let's say a Works.com employee named Sang wants to order million worth of furniture from Office.com, Works.com's preferred furniture supplier. When Office.com receives the purchase order from Sang, obviously it wants to know if Sang is authorized to complete the order and, if so, the maximum dollar limit he can spend. So in this scenario, when Office.com receives a purchase order from Sang, it sends an SAML assertion request message to Works.com, which then sends back an SAML assertion indicating that Sang in fact is allowed to order the furniture, but the maximum amount he can spend is ,000.
I already briefly touched on SAML assertions, which are XML documents containing security information. Formally, an SAML assertion is defined as someone's declaration of fact. SAML assertions include one or more of three kinds of statements about a subject, which can be either a human being or program entity. The three kinds of statements are:
- Authentication statement
- Attribute statement
- Authorization statement
Now let's look at each of the different kinds of SAML statements in more detail.
An authentication statement basically says that an issuing authority (asserting party) asserts that a subject S was authenticated by M's authentication means at time T. As you probably guessed, the authentication statement is used to enable single sign-on.
Listing 1 shows an example of an SAML assertion containing an authentication statement:
Listing 1. SAML assertion containing an authentication statement
<saml:Assertion ...> <saml:AuthenticationStatement AuthenticationMethod="password" (By means M) AuthenticationInstant="2001-12-03T10:02:00Z">(At time T) <saml:Subject> (Subject S) <saml:NameIdentifier SecurityDomain="sun.com" Name="Sang" /> <saml:ConfirmationMethod> http://...core-25/sender-vouches </saml:ConfirmationMethod> </saml:Subject> </saml:AuthenticationStatement> </saml:Assertion>