Protecting ADF resources with Oracle Entitlements Server 11gR2

Many organisations are looking for a managed, centralised policy security store to manage fine grained authorisations across their application estate. 

Oracle Entitlements Server (OES) provides that centralised policy management which gives real time policy based authorisation decisions.

I want to look at getting OES policies to protect ADF resources and what options we have for integrating the two for fine grained authorisation.

As an aside, Authorisation...Authorization, potato...potato... I was brought up in England and almost all of the "zation" type words are spelled with as in "organisation". My spell check does not understand but I'll carry on regardless!

To start with, take a look at this white paper that gives a great succinct(ish!) overview of OES:

http://www.oracle.com/technetwork/middleware/oes/oes-product-white-paper-405854.pdf

The first part of this post will outline the high level, how OES can be configured to protect ADF resources. In a second post, I will provide instructions on how to set up a simple ADF application with OES fine grained authorisation.

ADF Security

We first need to understand the ADF security model, from this we can look at how OES will fit into the mix of securing ADF resources.

ADF has it's own security framework that uses Oracle OPSS (Oracle Platform Security Services) policy driven security framework to provide declarative security for ADF resources (taskflows, regions, etc.). OES also uses OPSS as it's underlying security framework, this is key to having these products working together.

Describing the ADF security model is beyond the scope of this blog, but take a look at the many great resources that give an in depth view of the ADF security framework and how ADF resources are protected via ADF policies. A good place to start is with Frank Nimphius's excellent article "Security for Everyone"

OES WebLogic Security Module Authorisation Engine

I want to explain the role of the WebLogic Security Module (SM) and it's place in securing ADF resources. The WebLogic SM is a plugin for OES that enables the WebLogic application server container to provide both Policy Decision Point (PDP) and Policy Enforcement Point (PEP) integrations into OES.  The SM acts as a local authorisation engine that caches OES policies and provides authorisation decisions in the local application server without needing to communicate back to the OES admin server for policy decisions.

NOTE - In the 11gR1 OES release, the WebLogic SM could not be installed within a server domain which had Java Required Files (JRF) enabled. An ADF application needs to be deployed into a WebLogic server domain which has JRF enabled. Due to this, we cannot deploy an 11gR1 SM into the same domain as an ADF application. (An 11gR1 SM needs to be deployed in a separate domain and integrated using REST APIs) 

OES 11gR2 allows the WebLogic SM to be deployed within a JRF domain and hence enables us to deploy the SM within the same server domain as our ADF application.

OES Background & Terminology

So, to give some context, let's outline some basic OES terminology and high level principles. The diagram below shows the high level architecture blocks that comprise Oracle Entitlements Server. I am not going to go into all of these but will give a brief description of the important parts we need in securing ADF resources.

Administrative Server

The OES administration server gives us a GUI console to (amongst other things) manage our policies, applications and distribution of the policies to the security modules.

• Provides the capability to manage authorisation policy creation, management and distribution.
• The administrative server is deployed as a J2EE application on WebLogic Server, within its own domain.

Policy Store

The policy store is the place where we store our policy that we define with the OES administration server GUI.

• The repository for OES policies.
• The policy store holds the central policy details that is written and read from the administration server.
• The policy store can be file, LDAP or DB.

Identity Store

The identity store provides us with a credential store from which we can integrate identities, groups, roles etc.

• e.g. Oracle Internet Directory Server or Active Directory
  

Authorisation Engine

The authorisation engine is used by OES to make policy decisions and apply policy enforcement on behalf of a requesting application

• The authorisation engine within the context of managing ADF applications will be a WebLogic security Module, providing the Policy Decision Point and Policy Enforcement Point.
• A WebLogic Security Module is deployed within each of the managed server nodes in a WebLogic cluster that hosts the application.
  
• The security module provides a local cache of policies distributed by the OES administrative server.

What is a PDP?

A PDP (Policy Decision Point) is a component of OES that interacts with the OES policy store to provide a policy decision. For example, given a the details of a resource to protect, principle and other attributes, the PDP will return a DENY or PERMIT decision based on the configured policies.

What is a PEP?

Whereas a PDP will return a PERMIT or DENY response to a resource request, the PEP (Policy Enforcement Point) will actually enforce the decision to allow or deny access to the resource. For example, a PEP may be a web application that takes the PDP response and blocks a user from accessing a page that has returned a DENY from the PDP.

WebLogic Security Module as a combined PDP and PEP

The OES WebLogic Security (SM) module can act as both a PDP and a PEP. Both returning policy decisions and also enforcing them. The security module operating in this way is called interceptor mode.

The WebLogic Security Module plugs directly into the application server that contains the deployed application which is to be protected. The SM intercepts authorisation requests makes the decision and also enforces the decision.
The figure below outlines the role of the SM as a PDP and PEP.

The main customer use case for operating in interceptor mode is to enforce both course and fine grained ADF application entitlements through OES policies. This moves the authorisation policies from application defined ADF Security Framework into policies defined centrally by OES.

 For further details on this configuration refer to http://docs.oracle.com/cd/E21764_01/doc.1111/e14096/intro.htm#sthref11

WebLogic Security Module as a PDP

Certain use cases cannot be met through the use of the SM in interceptor mode. Examples of these are, custom code requests that do not use the WebLogic container for authorisation or providing authorisation for certain ADF components (e.g show an ADF button)
To satisfy these use cases, we need the SM to act as a PDP only, and delegate the enforcement to the calling application.

The figure above outlines the components and authorisation flow when using the WebLogic Security module as a policy decision point.
The ADF application will act as the PEP but delegate the authorisation decision to the security module PDP.
When a Security Module acts purely as a PDP, its only functionality is decision making. It receives an authorisation request and returns its decision to the PEP that originally made the authorization call. With the Security Module acting solely as the PDP, an external entity must act as the PEP - make the authorization call (using the Oracle Entitlements Server authorisation API) and enforce the returned decision.

The above figure outlines the high level integration of ADF components with the WebLogic Security Module.

• The ADF application implements authorisation API calls where required:
• Phase listeners
• Backing Beans
• ADF component expressions.
• API authorisation request made to SM
• SM queries local policy cache to return a permit/deny response to the application

Integrating OES and ADF

The following section outlines the high level integration design for integrating ADF components with OES authorisations using two SM modes:

• WebLogic SM in interceptor mode
• WebLogic SM as PDP

WebLogic SM in Interceptor Mode

The WebLogic SM can be used to provide container based course grained authentication. The SM, in interceptor mode can be used to automatically protect ADF pages, taskflows, regions and other ADF components via OES policies.

The OES Authorisation Proxy is configured as an authorisation provider within the application server and performs container based authorisation and enforces policy decisions.

The following diagram outlines the WebLogic OES Proxy function

1. Web browser (user) requests another web page
2. WLS container examines Browser Cookie and knows the user was previously authenticated. It retrieves the user’s authenticated identity from cache. Then, the container uses the authenticated identity and makes an authorization request for the web page.
3. OPSS-CSS makes the corresponding call to WLS OOTB authorization provider
4. The authorization provider sends the response (permit/deny)back to OPSS-CSS framework
5. OPSS-CSS framework then calls into the OES Authorization Proxy
6. OES Authorization Proxy forwards the authorization request to OES PDP
7. OES PDP computes the authorization decision (permit/deny) and sends back the response
8. OES Authorization Proxy sends the response (permit/deny) back to OPSS-CSS framework
9. OPSS-CSS framework combines the individual authorization results (permit/deny) from WebLogic Authorization Provider and OES Authorization Proxy and sends the final response (permit/deny) to the WLS container.
10. The container requests the web page from the web application
11. The application returns the web page to the container
12. The container sends the response to the web browser

In my next post (which will appear very shortly) I will provide some step by step instructions on how to configure protection for ADF resources using the WebLogic SM as a PEP.