The Foundations of Web Services Security

Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

The objective of this article is to detail the various Web services security models prevailing in today’s IT world. This article is targeted towards the developer community working to secure their Web services. This would be a starting point for developers to know about the various standards available in the market for securing a Web service and how the standards are related.

A Web service is a self descriptive, reusable, and loosely coupled software component defined using WSDL, registered using UDDI, and invoked using SOAP that is exposed over the Internet. It is a real interoperable technology that makes any two applications communicate with each other using a common protocol; for example, XML. This behavior makes Web services play a major role in enterprise application integrations and building business applications based on Service Oriented Architecture.

The Need to Secure Web Services

It’s been some time since the emergence of Web services in the IT paradigm. More and more enterprises are developing and deploying Web services for their business models in the production environment. As the usage of Web services increases, the need to standardize the way to secure the Web services also increases. Today, securing the Web service is a big concern for enterprises. Web services can be dynamically discovered and consumed by posting XML messages over a standard protocol such as HTTP. It is obvious that HTTP is vulnerable to many security attacks. The potential security problems that Web services may face are:

• An unauthenticated person might try to consume the services
• An authenticated person without sufficient permissions might try to access services
• The XML message might be modified by hackers and the recipient might get the message in altered form
• The sender might try to non-repudiate

Consider the following enterprise bank service exposed as a SOAP service and the various threats on this service when exposed on the Internet.

A Real-Time Scenario

Enterprise X, as a part of providing value and adding services to the customers, would like to expose some of its banking capabilities to its consumers through the Internet as Web services. The banking service provides the functionality to transfer funds between accounts. Valid users can transfer funds from one account to another. This functionality of the enterprise is exposed as a Web service. Other possible business functionalities that can be exposed by this service would be checkBalance, viewLastTransaction, and printStatementforMonth.

The following diagram shows the various client invocations to the banking service when deployed as a SOAP service.

Now, consider various scenarios in which the banking service gets invoked.

Scenario 1: Client A invokes the “transferFund” operation of the banking service. Because this is a valid client, the invocation goes through and the client A is able to transfer funds between accounts.

Scenario 2: Client B, who is authorized to invoke the other operations and is NOT authorized to access the transferFund operation, can also invoke the transferFund operation because there is no security imposed to restrict this access in the server side.

Scenario 3: Client C, who is NOT an authorized client for invoking any of the operations provided by the banking service, can also access all the operations because there is no security imposed to restrict this access in the server side.

Scenario 4: An unknown client (hacker) can trap the SOAP message between client A and the banking service and then can tamper with the SOAP message and send it to the server. This would be the most critical threat to the enterprise running the banking service.

From the above scenarios, you can see that Scenarios 2 through 4 should be considered security threats for any enterprise providing their business capabilities as a Web service. This shows the need for a security model to be followed in the enterprise to make the service more reliable and secure.

Web Services Security Models

The Web services security model can be broadly classified as:

• Transport-level Security
• Message-level security

Transport-level security (SSL)

Secure Sockets Layer is a protocol developed by Netscape for transferring data via the Internet in a secure manner. SSL works by using a private key to encrypt; the key is transferred over the SSL connection. SSL is used to provide transport-level security for the Web services applications. It provides security features including authentication, data integrity, and data confidentiality. SSL enables a peer-to-peer secure session. This basically encrypts the whole of the message on the wire at the transport level rather than the application level.

Limitations of SSL:

1. SSL is designed to provide point-to-point security. In Web services, there may be multiple intermediary nodes before invoking the actual service. In such cases, SSL may not be able to provide end-to-end security between the client and the actual Web service; rather, it could provide security between the client and the first intermediary.
2. SSL encrypts at the transport level and not at the application-message level. Web services might need to secure only part of the SOAP message. This is not feasible with SSL. In other words, SSL does not provide element-wise encryption. As in the banking service example, the enterprise would like to encrypt only the creditAccount, debitAccount, and amount details.

Message-level security

Now that you have seen the limitations of Transport level security, you can explore the capabilities provided by the Message-Level Security model. There are various XML-based security standards emerging in the industry, each trying to address message-level security. Following are some of the popular standards:

XML Encryption: The XML Encryption specification is defined by W3C and addresses the issue of data confidentiality using encryption techniques. Encrypted data is wrapped inside XML tags defined by the XML Encryption specification. For more information, see http://www.w3.org/Encryption/.

XML Signature: The XML Signature is the specification initiated and defined by W3C and IETF. It provides message-level data integrity and authentication wrapped inside an XML format. For more information, see http://www.w3.org/Signature/.

WS-Security: WS-Security is the standard defined by OASIS and provides a mechanism for data integrity, confidentiality, and single message authentication features within a SOAP message. WS-Security makes use of the XML Signature and XML Encryption specifications and defines how to include digital signatures, message digests, and encrypted data in a SOAP message. WS-Security also provides a general-purpose mechanism for associating security tokens with messages.

SAML: Security Assertion Markup Language (SAML) is the standard defined by the OASIS group. It provides a means for partner applications to share user authentication and authorization information. This is essentially the single sign-on (SSO) feature being offered by all major vendors in their e-commerce products. In the absence of any standard protocol on sharing authentication information, vendors normally use cookies in HTTP communication to implement SSO. With the advent of SAML, this same data can be wrapped inside XML in a standard way, so that cookies are not needed and interoperable SSO can be achieved.

The following table details the various Web services standards available defined by the specific standard group. It also captures the various implementations of the standards available in the market and the features of each of the products.

Now, considering your banking service implemented and deployed using the Message-Level security model, the following diagram shows the sample wire SOAP message format that will flow from the client to the service. Now, because the SOAP message is encrypted, any unauthorized client or hacker cannot create or tamper with the SOAP message on the wire and invoke the actual Web service, thus ensuring the security of the end service.

Conclusion

This article captured the various prominent Web services security standards prevailing in the market and the implementations available. This article has focused only on the widely used standards.

References

1. XML Signature: http://www.w3.org/Signature/
2. XML Encryption: http://www.w3.org/Encryption/
3. WS-Security: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss
4. For more details on XSS4J, see http://www.alphaworks.ibm.com/tech/xmlsecuritysuite
5. For more details on Apache-XML-Security-J, see http://xml.apache.org/security/
6. For more information on XML Security by Verisign, see http://www.xmltrustcenter.org/xmlsig/index.htm

About the Authors

Kumar Raj Moorthy has been working as an associate software analyst for the telecom mobility division of Hewlett-Packard, India. He has a Bachelor of Engineering degree in the field of computer science from the Bharathiyar University, India. He has more than six years of software industry experience involving Web services, WS Security, J2EE technologies in enterprise application, and telecom domain. He is currently involved in design and development of Service Delivery Platform using SOA for telecom providers. He can be reached at kumar.raj.m@hp.com or kumarraj@gmail.com.

Ayyappan Gandhirajan holds a Bachelor’s degree in Electronics & Communication Engineering from MK University, India and is pursuing a Master’s in Software Systems from BITS, Pilani. He has been working as an associate system analyst for Hewlett-Packard, Bangalore. He has more than six years of software experience involving Web services, WS Security, and J2EE technologies. He is currently involved in Web services orchestration and access controllers. He can be reached at ayyappan.gandhirajan@hp.com or G_Ayyapparaj@yahoo.com.