18.2  Decoupling Policy from Applications

through the URI [2]; this identifier is relatively unambiguous, visible, and inexpensive to parse within the HTTP. HTTP offers few options for identity claims and SSL provides a decoupled security layer protecting transmission. The high degree of constraint and rigor that defines the Web allows policy to consist of little more than confidentiality and integrity, authentication, authorization, and some audit – all elements that promote a clear separation between Web application and policy enforcement.

Web architecture is the basis of Web services. However, in contrast to its foundation, Web services are less constrained, vastly more complex, and suffer from an approach to standardization that is highly distributed. The basic processing and security models offer a breadth of scope that leaves considerable underspecification [17]. This has made implementation in application servers complex and prone to issues with interoperability.

In the SOA community, one approach to these challenges has been to separate security and monitoring functions into a PEP decoupled from the application services themselves. Policy, which is a concrete language for asserting the requirements that constitute the run time governance of services, is the logical place to accommodate the more diverse needs of Web services and to articulate a strict message-processing model for enforcement points. Policy enforcement thus takes on a much more significant role in facilitating service-oriented communications than for the conventional Web.

The canonical model for decoupled policy enforcement promotes a separation of concerns between the system entity responsible for enforcement, the Policy Enforcement Point (PEP), and the system entity responsible for decision-making, the Policy Decision Point (PDP), recognizing that the latter is often a centralized resource shared among many lightweight enforcement instances [30]. This has been well described in the context of Web applications [16], but the model is of similar value when applied to Web services transactions.

18.2.1  Overlap of Concerns Between the PEP and PDP

The essential tension in this model is between the desire to have centralized, authoritative decision-making and the practical need for distributed enforcement. The PDP requires visibility of key elements of a transaction to render decisions effectively; the PEP has full visibility, but it cannot practically relay this entire context to the PDP. Identity-centric PDPs should be in proximity to directories and serve as unambiguous authority for decision-making. To meet performance, security, and reliability demands, PEPs should reside with applications. The communication between PEPs and PDPs must reflect an optimization of data necessary to render an effective decision without significantly degrading transactional throughput. This has ramifications for cloud deployment.

In the conventional Web, the policy model segments cleanly because of the limited scope of policy in the architecture. Web PEPs are responsible for enforcing privacy and integrity expectations of policy locally; to escalate an access control

decision, the PEP simply bundles identity claims, intended actions, and target URI and relays this to a PDP.

Web services transactions, in contrast, blur the distinction between these system entities because a lot of the decision-making demands additional message context that is not practical for a PEP to relay to a central PDP. Thus, SOA PEPs retain considerable internal decision-making responsibility. This independence is a crucial factor when deploying into cloud-based environments, where communication with a centralized PDP (which may reside on-premises instead of within the cloud) could be impractical for reasons of security or latency. Distribution of authority comes at a cost of increased policy management and provisioning.

18.2.2  Patterns for Binding PEPs to Services

There are two common deployment patterns for PEPs: as agents, which integrate directly into the application container and as intermediaries, which are independent of the application container and often reside on a separate physical or virtual host. There are tradeoffs associated with each approach that have particular ramifications in the context of cloud deployment. The important consideration here is how to secure the point of interface between the PEP and the relying party service (which in general resides inside an application server container). This defines the trust model between these entities.

18.2.3  Agents

The agent-based model of PEP deployment uses a plug-in that integrates directly into the execution model of the application container. The point of interface is an application server API.

There are a number of reasons that make this strategy attractive. The tight binding between the PEP and the application server execution context means that validated identity claims can be propagated directly into the application, using technologies such as JAAS in Java application servers or thread impersonation in systems supporting a high degree of integration between OS and application server (such as Microsoft environments). Collapsing this into a single execution context trivially provides security and establishes trust across the last mile – the hop between the PEP and the application. Agents distribute security processing along with applications, thereby benefiting from scalability strategies associated with the application and avoiding potential security bottlenecks.

However, there are issues with this approach. The tight, code-level binding between PEP and application server has its own challenges. With the exception of the Java servlet filter API, there are no standardized and widely adopted interfaces to application server execution context. This implication is that organizations with a large number

of heterogeneous systems (including simple version and patch differences between like-servers) find agent-based PEPs difficult to deploy broadly and consistently.

In practice, this leads to a lowest-common-denominator approach to functionality in agents. For simple Web application agents, requiring little more from policy than authentication, authorization, and audit, this is sufficient; however, it has limited agent applicability for Web services PEPs, as these require advanced policy processing capabilities. Furthermore, introducing third-party code into application servers injects manageability risks. This has fostered a pejorative association with agents in the commercial marketplace, leading some vendors to explicitly promote their “agent-less” architecture.

The colocation of a PEP and an application server may be concealing other potential risks. Binding the PEP to a generalized application server install makes this critical security layer subject to the integrity of the underlying OS. Hardening modern operating systems is a complex and highly specialized task, and the best practices may be compromised to accommodate server needs or simply from a lack of appreciation of their importance. If an attacker successfully compromises the OS, the entire security model collapses, rendering the PEP superfluous.

Agents have been widely successful in conventional Web servers, both onpremise, in SaaS applications, and in generalized cloud deployment of Web applications. In these cases, HTTP servers tend to be monocultures, de-emphasizing diversity issues with the agent interface. The limited demands of Web policy also allow Web agents to be lightweight and simpler to package with server installations.

18.2.4  Intermediaries

The intermediary model delegates PEP processing to an independent unit that can simultaneously serve one or more downstream relying parties. It operates as a policy-driven reverse-proxy to these applications. The point of interface here consists of basic network (e.g. TCP) and application layer (e.g. HTTP) protocols. These of course benefit from standardization and widespread support – this maturity makes deployment essentially universal.

The conventional on-premise SOA deployment of PEP intermediaries consists of hardened, performance-optimized appliances that are physically separate from application servers. This model invests PEPs with a high degree of trust; they serve as an independent policy layer that fully gates all communications to and from less policy capable internal services. PEPs are tuned for high-performance processing of common traffic profiles, particularly XML-based transactions where significant benefit is realized by leveraging purpose-built acceleration chips for essential operations such as schema validation, transform, and query. Intermediary PEPs are rarely a performance bottleneck because of the vertical scalability benefits of such optimizations and the horizontal scalability potential that comes from placing additional units in parallel.