Page 2 of 2   « previous page

Again, supposing that ACME is deploying more and more Web services, each of these Web services may have its own trust requirement. Some may be for internal use only, some may allow for Partner to consume, others for Partner B, and other Web services may authorize a combination of partners depending on the operation being invoked.

Using an XML gateway to manage and enforce the different Web services security requirements not only allows for flexibility of trust over time, but also provides a centralized policy enforcement point that enables a global view of security across the enterprise. Perhaps one of the mandates of the security manager is to ensure consistency of the security policies across all Web services exposed outside of the enterprise. If an XML gateway becomes the central entry point for all services, this becomes a lot easier to manage.

Securing the Last Mile
A concern that often arises when trust and authentication are delegated to an XML gateway is that it does not address the security between the gateway and the Web service itself. Some may argue that the added flexibility comes at the expense of end-to-end security. Although this is a valid concern that warrants close attention, securing the last mile between an XML gateway and a Web service is fairly straightforward. In fact, the ideal situation is one where security is dynamic up to the XML gateway (to reflect ever-changing security requirements), and static from the XML gateway down to the Web service (to minimize the Web service's maintenance). The following constitute a number of strategies to that effect.

A typical motivation for introducing an XML gateway in front of a Web service is to avoid the complexities of coding message-level security as part of the Web service. For this reason, transport-level security can be the solution of choice for securing the last mile. Presuming the Web service is being deployed over HTTP, transport-level security is well supported by most containers. The HTTP container is configured to only accepts requests through SSL (with client certificate), and to only accept the client certificate of the XML gateway. The administrator of the XML gateway simply configures the policy so that messages are routed over SSL using the gateway certificate as part of the SSL handshake. This provides confidentiality (transport-level encryption), as well as authorization (the Web service container requires proof of possession of the gateway's private key). Similarly, the XML gateway is configured to trust the SSL certificate of the Web service's container.

A static security solution for the last mile that involves message-level security could be as simple as instructing the XML gateway to sign and encrypt all messages before routing to the endpoint. The Web service would only accept messages signed by the XML gateway, and the gateway would only accept responses signed by the endpoint service.

Although it typically poses administrative issues, it sometimes is possible to simply isolate the Web service from a network perspective so that the only way in is through the XML gateway. I would not recommend relying on this alone to secure the last mile, but this can be used in conjunction with other strategies.

Federation of Security Beyond the Textbook Scenario
Standards such as SAML and WS-Trust enable message-level solutions to federated-identity problems that arise when Web services span across multiple identity domains. By delegating these security aspects of a Web service to a manageable policy enforcement point, companies minimize the risk and the cost inherent to software maintenance. Further, this empowers the security administrator by providing enterprise-wide control of security policies.

The ACME/Partner scenario described here is simple and perhaps even cliché. However, SAML-based security tokens may very well add value to your application even if your application does not cross multiple corporate boundaries.

Web services promise to connect different computing environments and applications written in different languages. This heterogeneity by nature makes it difficult to find acceptable common security denominators. In transactions where multiple Web services are involved, SAML security tokens enable single sign-on (SSO) scenarios that remove the annoyance of having each transactional point implementing its own authentication. XML gateways can further connect disparate systems by bridging traditional Web and Web service SSO technologies (think "transport level to message level" and vice versa).

In the same way that SAML authentication statements facilitate SSO in Web services, SAML Authorization Decisions Statements can be carried alongside SOAP messages through multiple transaction points, thus relieving each Web service from having to manage its own authorization rules.

Page 2 of 2   « previous page