Last month (WSJ, Vol. 4, issue 2), we looked at how Web services should not depend on specific security environments and rules but should be managed as part of all of an enterprise's corporate data assets such as Web applications, ERP systems, and in-house applications.

We recommended that Web services security be integrated with the overall enterprise security infrastructure at the very beginning of the Web services deployment phase. This month, we'll look at some of those possible deployment models.

Deployment Models
There are four deployment models based on the guidelines presented in our earlier article.

Terminology
The terms used in the deployment models are defined as follows:

• Reverse proxy server: Intermediary server (e.g., a Web server) configured to filter requests coming from Internet users into the enterprise, providing security, management, and caching capabilities.
• User repository (or user store): A persistent data store that maintains user information. A user repository can be implemented in LDAP, RDBMS, Microsoft's Active Directory, and mainframe applications. Information related to a single user may be maintained in multiple, separate user stores, each of which needs to be queried for authentication and authorization purposes.
• Web Services Management Point (WSMP): Enforcement point for implementing a Web service management policy
• Web Services Security Enforcement (WSSE): Enforcement point for implementing a Web service security policy

The request for a Web service is submitted using a SOAP message that can be sent over a variety of transport protocols (HyperText Transport Protocol [HTTP], Simple Mail Transport Protocol [SMTP], File Transfer Protocol [FTP], Java Message Service [JMS], and other message queue [MQ] services). The sender's identity is expressed in transport protocol headers or in the SOAP document submitted for the request. WSSE authenticates against the submitted credentials, binds the message to an identity, and, if authorized, grants access to the Web service.

The outer network firewall ensures that resources cannot be accessed externally. The inner network firewall ensures that the enterprise resources (including the IAM security policies and the user repositories) are protected against internal attacks.

Low-level access control methods are used to ensure that only the reverse proxy server can forward requests to back-end resources. This means that back-end resources (.NET, J2EE, and legacy) require additional container-level security configuration outside the IAM policy model.

WSSE enforces security across all types of transport. It supports both inbound and outbound flows (i.e., requests received by the enterprise from a third party and requests sent by the enterprise to a third-party). WSSE communicates with the IAM security policy server for security policy decisions.

This deployment template does not include many moving parts and does not require a complex and costly implementation. On the other hand, it does not scale very well because the container of each back-end resource needs its own access management layer.

Full IAM Deployment
All of the enterprise resources are protected by a single IAM system. WSSE points for J2EE and .NET containers may be deployed in two ways:

• Interceptors (or "agents"): The agent can be integrated with a variety of Web services containers. The agent interacts with the IAM policies to provide security services.
• SOAP message handlers: Use either the Java API for XML-based remote procedure calls (JAX-RPC) or .NET pipelines. SOAP message handlers have the benefit of being transport independent.

Once a Web service requester has successfully been identified, authenticated, and authorized, the IAM platform provides the ability to leverage the user identity to personalize the behavior of the Web service.

The Web service can be bound to aspects of an identity through user entitlement information passed to the Web service by the IAM platform. For example, when a user has successfully been authenticated and authorized to access a Web service, the IAM platform can identify which entitlements should be obtained about that user, retrieve them from the user store(s), and associate them with the Web service request by binding them to the XML message.

This eliminates the need for a Web service to keep its own entitlement database and handle the retrieval of entitlements in the application logic. Thanks to the IAM platform, these entitlements can be centrally and securely managed and associated directly with a user's identity.

In some variations of this deployment model, the reverse proxy is optional.

IAM + WSM Deployment
The SOAP message is first received by the WSM enforcement point (WSMP). The WSMP makes a call to the WSSE point to ensure that the SOAP flow is secured.

WSSE authenticates the requester against IAM policies and returns security information to the WSMP. The WSMP can then enforce the WSM policy once the SOAP message is bound to a Web service consumer's identity.

The WSM platform can integrate with the IAM platform in two ways:

• The WSM platform can explicitly invoke the WSSE through the IAM application programming interface (API)
• The WSM platform can use the WSSE agent or the message handler model described above.

This deployment model allows the enterprise to leverage a corporate infrastructure for security (the IAM platform) and Web services management (the WSM platform). Both provide a layer of abstraction that relieves Web services developers from security and management tasks so that they can concentrate on the design of the Web service business functions.

Network Appliance Deployment
This is the full-blown integration including a network appliance. The network appliance is added to provide wire-speed XML processing (see Figure 4).

In this deployment model, the network appliance delivers network security services combined with an authentication service, as described last month (see Protection and Threat Prevention Layer).

Typically, the network appliance interacts with Web services flows by intercepting the incoming request as soon as it passes through the network firewall. The network appliance decrypts the request, parses the XML document, validates the document against an XML Schema, and applies transformations if required.

The network appliance may provide authentication against a user store configured with the IAM platform. The result of authentication is then communicated downstream, using SAML for example. The WSSE and WSM enforcement points can also benefit from authentication information provided by the network appliance.

Once the Web service requester is authenticated, the IAM platform can move to grant access to the Web service, and the WSM system can apply business-level management policies.

Conclusion
With a focus on security and management, a Web Services Reference Architecture can help the prevention (network security), enablement (identity and access management), and enforcement (Web services management) layers of a Web services architecture fit together.

Web services providers can focus on the design and functionality of the Web services they expose to their employees, customers, or partners, while relying on enterprise-wide security and management services that increase overall availability, scalability, interoperability, and manageability.

References