The intermediary model has the benefit of a network hop to clearly define layering between policy and service. However, in the cloud, the underlying networks are inherently untrustworthy; this adds considerable complication to the security model between the PEP and relying party, demanding that it becomes more explicitly protected than with agents. The following table describes this:

The commercial sector markets intermediaries for Web servers as Web application firewalls. Despite their advantages, this product category sees less deployment than agents-based solutions, primarily because of the ease with which agents can handle the more limited policy requirements of the Web.

Intermediaries, in contrast, are the dominant solution for SOA Web services. Here, the lack of definition and constraints on the architecture demand much greater functionality from policy and thus greater sophistication from PEPs than the limited operating environment of an agent can uniformly support. Web services is fundamentally an approach to integration – an insight that implies a potential diversity of service provider hosts that make agent integration impractical.

18.3  PEP Deployment Patterns in the Cloud

The term cloud computing suffers greatly from industry hype, ambiguity, and overload of meaning. NIST offers a reasonably comprehensive definition that characterizes cloud in terms of essential characteristics, service, and deployment models [18]. NIST acknowledges that community debate is continually refining our understanding of the term, and they have updated their paper in response to evolving perception.

There is wide acceptance of the three cloud service models NIST describes. These can be characterized not just in terms of functionality offered to customers, but also by where the boundary of control lies in the stack between customer-managed and provider-managed elements (where the stack defines layers including host and network infrastructure, operating systems, applications, data, etc.). The opportunities

for deployment of SOA PEPs into the cloud are largely a function of where these control boundaries lie. Cloud-based PEPs are virtual appliances that consist of a policy execution engine operating under a security-hardened and performanceoptimized operating system. Thus, deployment of virtual PEPs in the cloud requires a customer-accessible hypervisor execution environment.

18.3.1  Software-as-a-Service Deployment

Software-as-a-Service (SaaS) offers no real opportunities for SOA PEP deployment. SaaS implementations are thin-client Web applications operated entirely by the provider, but open to minor configuration by the customer, such as Salesforce.com or Google GMail. Policy enforcement for Web applications, by virtue of its limited scope (the security model simply consists of basic authentication, sometimes SAML SSO and federation, and SSL/TLS transport protection), is generally integral to the host application servers and is therefore under complete control of the provider.

SOA PEPs, however, do have a role to play in securing access of on-premise services by SaaS applications. This is a conventional, edge-of-network PEP deployment in the on-premise DMZ, implemented using either hardware or virtualized SOA PEPs.

18.3.2  Platform-as-a-Service Deployment

Like SaaS, Platform-as-a-Service (PaaS) offers no current opportunity for deployment of virtual PEP appliances. Although PaaS relaxes the boundaries of control to offer customers access to an application deployment environment, the container-based execution model – such as Google’s AppEngine – is generally too restricted to support the diverse connectivity and operating requirements of a mature SOA PEP code base.

18.3.3  Infrastructure-as-a-Service Deployment

Infrastructure-as-a-Service (IaaS), in contrast to SaaS and PaaS, offers the greatest degrees of freedom of control to the customer, and thereby an opportunity for virtualized PEP deployment. IaaS offerings such as Amazon’s Elastic Compute Cloud (EC2) shift the boundaries of customer control to an abstracted hypervisor, which can host a virtualized PEP and virtualized, subordinate SOA services under PEP management. By providing finely grained, policy-based control over all communications to or from a cloud-resident service, the PEP allows a cloud customer to reassert control over IaaS-resident applications. This higher level of visibility and control serves to offset the loss of lower-level, physical controls necessarily surrendered to the cloud provider. This deployment model is the focus of this chapter (Fig. 18.1).

Fig. 18.1  Virtual PEPs deployed in the cloud provide security and management for applications in the cloud. When paired with on-premise PEPs, they can create a secure tunnel between application in the internal network and cloud instances

18.3.4  Alternative Approaches to IaaS Policy Enforcement

There is a number of existing approaches to securing services in IaaS clouds. Both simple Web security and VPNs offer the advantage of simplicity, generality and familiarity. However, both suffer from significant limitations in their scope that make virtual PEPs, which consolidate a broader range of capabilities under policy control, a much more attractive choice.

18.3.5  Basic Web Application Security

Simple security models – consisting of basic credentials in HTTP, interface to conventional LDAP directories for authentication and authorization, and SSL for confidentiality and integrity – are widely supported in application servers hosting rich Web services. But application servers do not uniformly or consistently support more sophisticated message-based security models, SLAs, threat detection, orchestration, content-based routing, load distribution, etc. – all valuable functions in SOA messaging environments with diverse service consumers and producers.