Michael Hanson

Subscribe to Michael Hanson: eMailAlertsEmail Alerts
Get Michael Hanson: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Service Firewalls to Protect Web Services

Service Firewalls to Protect Web Services

Walk into a roomful of technology vendors discussing Web services security, and you're likely to choke on all the smoke being blown around. Let's clear the air a little. There is no reason why IT organizations cannot deploy Web services in a secure and manageable way using today's technology.

You don't have to be left behind. This article will outline what it takes to safely expose your business systems over the Internet and keep your applications running safely and cost efficiently.

While Web services standards - UDDI, WSDL, and SOAP - do not directly address security, Web services are based on transport mechanisms that have their own existing security standards. Commercial solutions are available today for architects and developers looking to securely deploy Web services in an interoperable manner over the public networks.

However, when deploying Web services, you must carefully consider what it takes to maintain security for a Web services-enabled application. Once auditors or compliance managers have determined it is safe to deploy an application, partner identities must be managed; certificates must be issued, maintained, and revoked; and transactions must be audited. Additionally, some partners can be trusted to invoke certain interfaces while others cannot. Through all this, developers and administrators struggle to keep up with evolving standards. Keeping these challenges in mind will help you differentiate among Web services security vendors.

The Current State of Web Services Security
While it is possible to secure Web services today - and more is being done to make it easier tomorrow - Web services platforms alone are insufficient to securely deploy Web services-enabled applications. While Web services can take advantage of existing technologies for authentication and authorization, complete Web service security is about more than just access control. Secure Web services deployments must not only implement authentication and authorization capabilities, but also provide content validation, transport- and message-level encryption, digital signatures, a robust logging system, and the ability to effectively manage security to respond to ever-changing business needs.

Application developers who want to implement enterprise-class security for their projects will need more than what the Web Services Security (WSS) specification, currently being developed in OASIS, provides. Web services can take advantage of existing technologies for authentication and authorization, including using bilateral certificates over SSL and exchanging user names in HTTP headers, and these services are currently available in most SOAP activation frameworks. WSS extends these capabilities and enables new security capabilities within the SOAP envelope, but covers only part of the total solution.

The Service Firewall Completes Security
A service firewall is a network element, either logical or physical, that links an enterprise's Web services to external partners or internal consumers in order to secure the bidirectional flow of XML messages. This functionality is separate from what a network firewall provides, and the two should be used together. The service firewall is in the logical data path between organizations. In this position, the service firewall can monitor, secure, and control all Web services traffic.

Shifting this responsibility from the Web services platforms to a single point allows centralized control over which clients have access to what services, and offers the ability to enforce other global security policies across a distributed application. This concentration of security policy enforcement allows an enterprise to shift to new and emerging security standards quickly and easily without having to make changes to each individual application.

The ability to maintain consistent security policy across multiple applications deployed on multiple platforms is another reason why centralization of security is important. In a fully realized service firewall implementation, each Web service invocation that arrives at an application can be assumed to have been decrypted, authenticated, authorized, validated, and logged, allowing the application to process the request without having to perform each of those actions itself. In addition, centralized security management allows new applications and new partners to be quickly, securely, and inexpensively added. This scheme significantly reduces the complexity of Web services applications and improves the security of the system as a whole.

Service Firewall Capabilities
Service firewalls should provide all of the security services necessary to completely secure enterprise Web services. The WSS specification defines many of the standards that a service firewall must implement, but a service firewall must implement a larger set of features to properly secure an application.

Service firewalls can use a variety of means to establish the identity of the client. HTTP/S provides two methods: HTTP Basic-Auth headers and SSL Client Certificates. Both of these methods are applicable to Web services requests. WSS also defines four new means of establishing identity within the SOAP envelope and independently of the transport: user names and passwords, X.509 certificates, Kerberos tokens, and SAML assertions. Listing 1 shows the use of an X.509 certificate to show proof of possession.

Once the identity of the Web services client is established, the service firewall must check the entitlements granted to that identity. This can be done by accessing a variety of entitlement repositories, or by having an integrated store for managing entitlement. In the former case, the source could be an enterprise LDAP server, Active Directory, or another database. In addition, certificates can be checked with certificate authorities to determine if they are current or have been placed on a certificate revocation list (CRL).

Encryption is an important part of maintaining message privacy. Web services can use HTTP over SSL to provide point-to-point encryption of messages, and a service firewall should be able to perform all forms of SSL and TLS functions. Depending on the privacy requirements, it may be necessary to use a long (128-bit) RSA key, in which case the help of a hardware accelerator might be appropriate.

WSS defines a method of using XML-Encryption to encrypt portions of a SOAP message and include additional information about how the encryption was performed in the Security header. Listing 2 shows the use of XML-Encryption in a SOAP message requesting credit card authorization.

XML digital signatures allow senders of SOAP messages to sign the content of messages before sending them so that receivers of these messages can verify that the contents have not been changed in transit. WSS specifies a means to include signatures in the Security header of a SOAP message. Service firewalls can perform signing and verification functions for both incoming and outgoing messages.

Content validation
Some might assume that an authenticated and authorized request whose contents have been decrypted and whose signatures have been validated should be approved. However, this would ignore a critical aspect of application security, namely, validating the correctness of the request for both semantics and syntax. Checking both is important because no single party controls both ends of the communications channel; therefore, no message, even one that is from a trusted identity, can be assumed to be correct and not from a malicious individual within the trusted partner organization. Service firewalls need access to a repository of DTD and XML Schema files to perform this content validation.

Service firewalls should be able to log each message in a reliable and auditable way and report on what SOAP messages were sent by whom, when, with what parameters, and with what result. The best practices regarding log file retention suggest that log files may need to be kept for as long as seven years depending on their role in business processes (such as for accounting and billing). This is important, and when considering service firewall architectures, the logging system must have archival capabilities in order to fulfill its role as a central log for all inter-enterprise Web services traffic. Because of this, the service firewall should be deployed on an open hardware platform that allows administrators to configure hardware to satisfy logging requirements, such as a large disk array or a tape backup unit, both at the time of deployment and as part of the ongoing task of maintaining a service firewall.

All of the security functionality mentioned above could be implemented as a stand-alone service firewall or integrated into a Web services application. The stand-alone service firewall, however, can be managed much more easily and at a lower cost than a custom application; when providing security for more than one application, these advantages become even more compelling.

To understand this, it is best to first break down the costs associated with managing Web services integrations. First, there are the costs of setting up valid credentials: creating and distributing client certificates, distributing information about how to access the services, and testing and debugging initial connections. Then there are the ongoing costs of maintaining keys and certificates, adding new clients, managing logs, upgrading applications, and fixing problems as they arise.

Service firewalls can significantly reduce both initial and ongoing management costs. First, service firewalls make it easy to set up secure communication with partners by separating security functionality from application logic. This allows the two to be tested and configured independently. Application interoperability can be established first without security, and then the functionality of the firewall can be enabled one step at a time until the message pathway is fully secure between client and firewall.

Second, a service firewall allows easy maintenance of security and services because it does not require each application to be retested after changes are made. For example, if security were built into an application, even a simple change such as allowing a new partner to send a SOAP message without a digital signature would require it to be recompiled to allow the new partner to omit the signature, and would have to undergo a full QA cycle to be requalified. By contrast, if security were performed by a service firewall, an administrator could simply make the change and deploy the new security policy in a matter of minutes because the applications are unaffected. The costs of implementing or purchasing a service firewall can be recouped through less costly management over its lifetime, especially in situations in which access control requirements or standards are constantly changing.

While the trade press and industry analysts have consistently bemoaned the state of Web services security, the service firewall offers a useful architecture that enterprises can deploy today to more easily and cost effectively secure and control their inbound and outbound Web services traffic, and extend tomorrow to stay current and remain flexible. But while attention has focused on security enforcement, enterprises require equal attention to the ability to manage security policy, monitor exceptions, and provide an audit trail that can be used by compliance and business managers alike.


Glossary of Terms
The OASIS technical committee known as the Web Services Security TC is working on standardizing and furthering the work originally done by IBM, Verisign, and Microsoft on a foundation of security services for Web services. www.oasis-open.org/committees/wss

A standard for exchanging XML-based authentication and authorization information. The specification can be applied to such varied applications as multidomain single sign on and SOAP messages. www.oasis-open.org/committees/security

Governs the process of encrypting and decrypting content, providing an XML syntax that represents both the encrypted data and pointers to help the decrypting party. It can be used to encrypt entire XML documents, or to encrypt only specific elements within XML documents. www.w3.org/Encryption/2001

Defines a syntax for encapsulating or embedding a digital signature for an XML or other digital document. The specification allows senders to attach their identity to content, and allows receivers to verify that the content has not been altered in transmission. www.w3.org/Signature

Specifies a method for simple clients to obtain key information from a Web service, or to publish key information to a repository. The specification allows easier distribution, registration, and verification of X.509 certificates. www.w3.org/2001/XKMS

Comments (2) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.

Most Recent Comments
Roboo 09/10/03 05:43:28 PM EDT
Vicki Daughtry 04/29/03 07:08:00 PM EDT

Indeed, XML firewalls like Westbridge Technology XMS and Reactivity are very useful for production deployment of XML and Web Services Networks.