Let's examine some of the security challenges that plague the world of Web services, and discuss solutions. It's important to recognize that each of these solution mechanisms offers specific security services catering to certain security policy requirements. Any multitier, multidomain security solution would include a combination of one or more of these security mechanisms with additional mechanisms to provide unified security.

Transport Security
Transport security provides privacy and data integrity for data transported between two communicating applications, as well as authentication of the communicating end points. The most commonly used transport security model on the Internet is a combination of HTTP Basic Authentication and SSL. HTTP Basic Authentication requires a user ID and password to visit Web sites that are protected using this mechanism. SSL is a protocol for transmitting data securely using encryption methods.

Is transport security alone enough?
Basic authentication is useful, but on its own not secure enough because the user ID and password are virtually unprotected. With SSL, it is possible to address a combination of server authentication and basic authentication to achieve authentication, confidentiality, and integrity.

Depending on requirements, this level of transport security is usually not enough. Basic authentication may not fit all situations and there may be a need for certificate-based or smart-card authentication because of inherent weaknesses in password-based mechanisms.

SSL is useful for ensuring confidentiality between service requester and service provider. However, at least two problems remain in the context of Web services messaging:

1.   SOAP messages can include third-party intermediaries that might need to read all or part of the message. Inherently, SSL assumes that communication occurs only directly between two parties.

2.   Because SSL encrypts the entire message, individual parts of a message cannot be encrypted or decrypted. SOAP security using encryption helps to partially solve this problem.

Message Security
Message security focuses on two critical security concerns: first, protecting message content from being disclosed to unauthorized individuals (confidentiality); and second, preventing illegal modification of message content (integrity).

With respect to the exchange of XML messages between two parties, the XML Digital Signature provides a means to identify the sending party (identification), and to demonstrate that the message has not been modified (integrity). The SOAP Digital Signature specification defines how to embed the signature element of XML Digital Signature in a SOAP message as a header entry.

XML Encryption defines how to encrypt data and represent the result as XML. The SOAP Encryption specification defines how to embed these elements in a SOAP message (header and body). The entire SOAP message or parts of a SOAP message can be encrypted to ensure confidentiality of the message contents when the message is sent to SOAP intermediaries.

Is message security alone enough?
Message security can be considered complementary to transport security. However, it deals with a smaller subset of the security issues for Web services. Although it covers identification, confidentiality, and integrity, it fails to address other important requirements, such as propagation of asserted identity across domains audit, etc. These requirements cannot be met by SOAP security alone, but by a combination of SOAP extensions and bindings to third-party security services (if necessary).

Firewall Security
Firewalls are used at the trust boundaries of enterprise networks. Firewall security enforces an access-control policy between two networks by blocking certain types of traffic and permitting others.

In the early days of firewalls, a few well-known protocols, such as HTTP, Telnet, and FTP, required support. With the advent of newer protocols the demand arose for firewall policies to permit these protocols, an approach that was not recommended. To avoid making changes to firewall policies, "tunneling" was used to transport proprietary protocols over common protocols.

Is firewall security alone enough?
The rise of SOAP as the basis of Web services meant that HTTP tunneling could be increasingly common. However, the current generation of firewalls provides protection only at the network level, with minimal application awareness. Security for Web services requires the addition of application-level firewalls that inspect SOAP data content to protect against external attacks, as well as limit the effects of malicious software being transferred unintentionally among business partners.

Component Security
The advent of Web services has created a far greater challenge to the effectiveness and completeness of security services in the area of components. Ironically, security models within existing enterprise components - considered fairly recent adoptions within the enterprise business frameworks - have already been tagged as "legacy" in terms of what they can offer.

Typically in a Web service, requests/ invocations are delegated to well-defined endpoints hosting the request-processing service. For example, in the J2EE platform, these endpoints typically tend to be enterprise business components like J2EE EJBs, servlets, JSP, Java Web Services (JWS), portals, or Remote Portlet Web Services. It would seem logical to use the security provided by these existing components, such as J2EE Role-Based Access Control and/or JAAS. Such a security mechanism could be programmatic or declarative.

Is component security alone enough?
The inherent security model of components (such as in J2EE) generally provides minimal security, such as coarse-grained access control (through roles). Often, once these applications have been Web services-enabled, additional security demands are placed on them in terms of complex, fine-grained access control and the portability of security information. Depending on component securities alone could lead to a single point of failure if compromised, as security is a cooperative effort among layers of protection.

Existing Security Approaches for Web Services Security Integration
Web services solutions in transport and message security have existed for a while and have been quite widely adopted by the Web services vendor community. But there are other parts of the Web services framework with security needs that have yet to be addressed for a standards-based solution. Hence, vendors of Web services environments (developer toolkits, runtime environments) are providing their own security mechanisms for access to registry, service, components, etc.

Security by vendor extensions
A common pattern in vendor-provided message security has been to place the security extensions in the SOAP header, in accordance with SOAP Header Extension Mechanism. The extensions may contain additional data to allow modular addition of features and services like transaction management, conversation state management, digital signatures, user credentials, and message routing (e.g., specifying the recipient). In this way, the message context information can be propagated along the process chain of invocation.

Another pattern among vendor-provided Web services security approaches has been to make the security extensions part of the configuration information (XML file) for the Web services environment (container). Yet another pattern is to state security policies as tag extensions (similar to those used for javadocs) in the source code of the Web service implementations. Examples of such extensions include the authentication type to be used for the Web services, the delegation model (impersonation, etc.), and permissions for authorization based on roles.

Are security-by-vendor extensions alone enough?
When examined closely, we see that vendor-security extension has both pros and cons. Since this security is integrated with the deployment and runtime environment of Web services, it is readily available. However, configuration extensions are linked with the environment configuration, not the Web service definition, and thus lose portability across various deployment environments. Tag extensions (such as ones within source code) could lead to security policy inconsistencies, nonreusability, and maintainability issues.

Additionally, integration with third-party security products may become essential depending on the complexity of security required and the reuse of existing security harnesses deployed within the enterprise. However, vendor-provided security may not support such integration. The W3C has a Web Service Description Group working on enhancing Web services description information to include (among other things) security. This could not only improve runtime security, but also provide accurate access control at the time of publishing and brokering at the service registry.

Web Services Registry Security
With Web services, two kinds of service registries are planned. The global business registry disseminates service descriptions to the public. Private registries may be more selective and could restrict access and content.

Security concerns for all registries include prevention of unauthorized modification of registry content. Responsibility for administration of registry contents should rest with the content provider, who should be able to modify or delete content. Some security requirements for private registries include:

Registry security has yet to be addressed by a standards-based solution. For now, registry hosts and vendors provide their own security solutions, sometimes simply relying on underlying OS security. Given the potential diversity of possible registries, a framework-based multidomain approach seems to be required to ensure registry security.

Recommended Approach: Unified Security
From the preceding analysis of the shortfalls of existing Web services security solutions, it is apparent that transport, message, firewall, vendor, or component security alone may be insufficient to secure an entire system. Existing security requirements and any unaddressed residual security issues demand a specific framework-based approach - one that brings together various security services and solutions throughout a Web services environment, unifying security and making it ubiquitous.

What Is Unified Security?
Unified security means integrating existing and planned security technologies and products across the perimeter, middle, and legacy tiers, providing seamless, end-to-end security for your enterprise

The Need for EASI
Just as enterprise application integration (EAI) technologies addressed the problems of data access and resource management across the enterprise by integrating applications and business processes into a single, virtual "business engine," companies now need a set of easy-to-use tools and technologies to control access to those same applications and processes. Today, a new class of technology, Enterprise Application Security Integration (EASI), is emerging to ensure that the distributed enterprise is protected.

The EASI Security Framework
The Enterprise Application Security Integration Framework is a standards-based, vendor-neutral security framework approach to unify the patchwork of security products and services deployed within the enterprise. The framework secures Web services traffic between .NET and J2EE environments, and integrates security across multitiered Web applications. It dynamically brokers security interactions across a range of security products, enterprise applications, application platforms, and Web services platforms at a transaction level. It supports all categories of security products for authentication, authorization, accountability, administration, and cryptography.

By linking multiple security technologies and creating a common security infrastructure, the EASI Framework enables organizations to avoid potentially less secure and far more costly custom-built security solutions. It represents a cost-effective solution for unified security that is flexible, scalable, highly available, and reliable, positioning the enterprise-wide security infrastructure for future growth and change.

We have seen that we cannot buy "partial security" when it comes to deploying Web services. Traditional firewall security can't peek into the message envelope and decipher XML traffic. Content inspection is critical for improved Web services security.

SOAP Content Inspection
Within SOAP-based Web services environments, a key service of the EASI framework is SOAP Content Inspection (see Figure 1). This flexible, standards-based solution secures SOAP-based transactions for a range of enterprise B2B applications.

SOAP Content Inspection acts as an application-level firewall capable of inspecting the contents of communication. It provides a new layer of security for Web services - one that sits above transport or session layer security and examines the XML data itself. This XML data may be security or authentication information, such as an XML Signature or a SAML Assertion that could be evaluated using a security policy, or it could be a rogue Web service request designed to attack the service.

SOAP Content Inspection addresses the challenges of Web services security by: