7 Deploying the Policy Decision Point
This chapter discusses why and how the Policy Decision Point (PDP) is deployed. It contains the following sections.
7.1 Understanding the PDP Deployment Models
Oracle Entitlements Server supports deployment models that differ in the placement of the Policy Decision Point (PDP), depending on where the request for access will be evaluated. Java clients, for example, have the option of making a local call to the Security Module embedded with the application, or making remote calls to a Remote Method Invocation (RMI) or Web Services Security Module via a proxy. These models are not mutually exclusive; any combination of them is possible.
The PDP can be embedded locally with the application or it can be installed elsewhere (outside the application) for remote communication. Real time or near real time applications (stock trading or banking applications, respectively) would typically use the embedded model (where Security Modules are distributed) for a good response time. It should also be used if the application needs to work offline (no connectivity to the back end). A remote PDP (where one central Security Module commodities with multiple clients) can be used when there is a need to minimize the number of PDPs or if security concerns prevent deploying the PDP next to the application (like in a DMZ). Additionally, it can be used if overhead related to remote invocation is acceptable or if the PDP is invoked from an application written in a programming language other than Java (C, C++, C#).
Note:
Proxy Mode is used to configure a Security Module to send authorization requests to a remote PDP. It provides the ability to issue a request for access and receive the decision of GRANT or DENY. See Section 7.2, "Using the Security Module Proxy Mode."The following sections have additional information.
7.1.1 Embedding the PDP Locally
In the distributed deployment model, the Security Module/PDP is embedded in the protected application's container and runs in the same process. Policies are distributed to the Security Module and authorization decisions are made and cached locally so no network calls to a central server are needed. Additionally, no changes to the application itself are required. A typical embedded PDP deployment is illustrated in Figure 7-1.
7.1.2 Locating the PDP Remotely
In the centralized deployment model, the PDP runs in a process that is separate from the protected application and is hosted in a location that is remote from the protected resources. The central PDP (Oracle Entitlements Server or a Security Module) receives authorization requests from multiple clients and then evaluates the applicable policies, returning the authorization decision (GRANT or DENY) to the PEP to enforce. Figure 7-2 illustrates this centralized deployment model.
The centralized PDP is invoked using the XACML Gateway, RMI, or SOAP. It maintains local caches of roles, policies, policy decisions and attributes which can be updated on demand or at startup.
7.2 Using the Security Module Proxy Mode
Oracle Entitlements Server supports a Proxy Mode that allow clients to invoke authorization services remotely. When the Oracle Entitlements Server PEP API are used by an application to make authorization calls, a proxy can be set up on the application's host to communicate with the remote Security Module (on another machine) for access decisions. Web services or Remote Method Invocation (RMI) are the proxy's communication options. Figure 7-3 illustrates this topology.
The Oracle Entitlements Server PEP API can be called from an application regardless of whether that application is calling an embedded PDP or a remote PDP. Proxy Mode can be configured to provide security services locally (including authorization caching, logging and failover) and can communicate with the PDP using RMI or SOAP.
7.3 Using the XACML Gateway
The XACML Gateway is a SOAP endpoint that uses web services functionality and provides for communication using the XACML request/response protocol. The XACML Gateway is with the PDP (not the client) and is available with the instantiation of the Web Services Security Module. No special configuration is required to use the XACML Gateway. The Web Services Security Module will use a web services call when instantiated locally with the client. If it sees a SOAP envelope at its endpoint, it uses the XACML Gateway. Figure 7-4 illustrates a XACML Gateway deployment.
Note:
If the application is using the XACML request/response protocol, it is not using the PEP API.