Friday, October 25, 2013

About Oracle EntitleMentServer OES11gR2



OES Background & Terminology

There are tons of pages documents on the OES servers, I have summarised the concepts in simple two page document for better understanding for beginners...

 Oracle Entitlements Server (OES) is a standards-based, policy-driven security solution that provides real time fine-grained authorization in Application, Service-Oriented Architecture (SOA) and Database environments.

Oracle Entitlements Server is an entitlements system that supports the centralized definition of complex application entitlements and the distributed runtime enforcement of those entitlements. It allows you to externalize entitlements – remove security decisions from the application. It provides the means to define application resources and application businesses objects, represent those objects in hierarchical relationships, and write policies that describes which users, groups and roles can access those objects.
You can write policies that control access to both application software components as well as arbitrary business objects in the application. Oracle Entitlements Server also includes a security integration framework that provides an easy way to integrate with existing authentication, Web SSO, identity management, and user provisioning systems. 







The Administration Server is the Policy Administration Point (PAP). It manages the storage of policy data in the database and the transactional distribution of policies to the SSMs. The user interacts with the Administration Server through two browser-based administration console where roles, policies, and application resources are defined and managed. The information can also be managed programmatically through the Java management APIs or through Web Service calls.
Runtime enforcement in the application container is accomplished through a set of Security Service Modules. The SSMs are the Policy Decision Points (PDPs) and can be deployed in one of two ways:
  • As a centralized entitlements server that can be invoked via Web Services, RMI, or through the XACML 2.0 request/response protocol.
  • As a distributed set of PDPs which are embedded in the application container. In the distributed deployment model, policy is evaluated and enforced locally in the application container.
The SSMs can make use of application context that may be required to make a policy decision. Additionally, the SSMs can integrate with a number of Policy Information Points (PIPs). These PIPs can be user or application directories or databases that contain information that is required to make an access decision. Such information includes user, group, and resource attributes (e.g. user profile information, account balances and limits, etc.). These attributes can then be used in the policies which control access.
 

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




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

Authorization 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.




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 





The figure above outlines the components and authorisation flow when using the WebLogic Security module as a policy decision point.

No comments:

Post a Comment