Protecting ADF resources with Oracle Entitlements Server 11gR2 - Part 2
By gcolman on Jul 04, 2013
In my last post "Protecting ADF resources with Oracle Entitlements Server 11gR2" I attempted to outline the basic principles of protecting ADF resources using Oracle Entitlements Server 11gR2. In this post I will dive straight into how to configure simple ADF resources with OES policies in a step by step guide.
I need to stress that this is not an official Oracle guide or something that is supported through Oracle. The guide and any sample in this blog are my views and intended as a pointer to anyone looking to integrate OES and ADF.
So, lets configure our components....
The following steps outline the high level configuration steps for creating the WebLogic Security Module in interceptor mode and OES proxies to protect ADF resources.
The high level steps are:
1 – Create the SM Domain
2 – Configure the OES Authorisation Proxy
3 – Configure the OES Role Mapper
4 – Create the OES Application Policies
Follow the steps below to create a WebLogic SM JRF Domain.
Create an OES Authorisation Proxy as a WebLogic authorisation provider within the WebLogic SM domain’s default security realm.
OES Authorization Proxy
· Click New
· Enter a name for the provider
· Select OES Authorization Proxy from the dropdown.
Configure the OES Role Mapper
Create an OES Role mapper Proxy as a WebLogic role mapper provider within the WebLogic SM domain’s default security realm. This must be configured for the SM to be enabled as the PEP.
Security realms->myrealm->providers->role mapping
OES RoleMapper Proxy
- Select the Role Mapping ta
- Create a new Role Mapper
- Select OES RoleMapper Proxy from the dropdown
OES policies need to be created to protect the ADF resources handled by the OEA authorisation proxy.
Some points to note about the relationship between OES policies and the OPSS policy definitions that protect ADF resource.
- ADF security framework polices (as seen in the jazn-data.xml) do not map directly onto OES policies.
- ADF/OPSS policies utilise pattern matcher classes to define the resource types of the protected ADF resources.
- The ADF/OPSS resource names are generated by the JDeveloper / ADF application. These need to be translated into the OES policies.
TIP – Configure ADF security in JDeveloper, including resources to protect to get details of the resource names, pattern matching classes etc. These will be detailed in the JDeveloper jaxn-data.xml file and will serve as a reference for you to create the OES policies.
Create OES Application & Security Module
Within the OES administration console, create a new application (see later section for a reference to creating the OES policy resources)
NB* Ensure that the application name matches the deployed ADF application name.
Create Resource Types
Resource types within the OES policy are used to define the pattern match class that will be used to identify the resource type during authorisation.
1. Select New Resource Type from the home tab
2. Enter a resource type name (any name will do)
3. Create actions and attributes as required
4. Change the Evaluation Logic dropdown to “Permission Class”
5. Enter the full permission class name. This can be found in the jazn-data.xml file, if you have enabled ADF security in JDeveloper (example below)
6. Select comma for the action delimiter
Figure 8 - Resource Type
Resource types should be defined as a cross wave activity. The resource types should be common across all ADF applications and their resources that require protecting.
Create the resource
Create the OES resource as the resource name that can be found in the jazn-data.xml file if you have enabled ADF security in JDeveloper. (See example below)
Create the Authorisation Policy
Create an authorisation policy (see guidance steps in section 4.4)
Bind the application to the SM
Bind the application the Security module (see guidance steps in section 4.4)
Deploy the application
Deploy the application to the SM domain.
NB* Ensure that you select the following security configuration when deploying the application:
“Advanced: Use a custom model that you have configured on the realm's configuration page.”
When using the WebLogic Security Module purely as a PDP, (i.e. the SM is only providing authorisation decisions, but not enforcing them), then we must define the application itself to be the policy enforcement point.
The implications of this are that the application must provide programmatic enforcement of policy decisions that are being returned from the PDP. This could be implemented as a “security bean” which provides an isAuthorised() method which can be called with ADF Expression language (EL), passing the resource identifier for the resource to be protected. The Security bean interacts with the security module to obtain a policy decision based on the parameters that have been passed. ADF pages would be protected via a phase listener providing the authorisation call to the security bean.
The security bean should provide a generic interface which relies on the calling component to set the context of the application and resource to be protected.
The diagram below describes the ADF application components and their interactions with the WebLogic Security Module.
The following section gives guidance on the components and configuration required to set up an OES environment for development and testing.
The sections define the following:
- Installing the Oracle Entitlements Server product
- Creating an OES Administration Server
- Creating the domain which will contain the WebLogic security Module
- Creating a test policy to test the configuration
- Examples of integrating ADF components with OES
1 - Download the binaries for Oracle Entitlements Server 11gR2
2 - Use the following guide for installation.
The guide will take you through the download, installation and configuration of all the required components for getting the base install and configuration.
**NB - Please follow the guide provided in the following link up to and including “Installing the OES Client”
**NB – Ensure that the OES client install is created in a separate directory on the FMW home (do not take the default OES Client install location) e.g. create a OES_CLIENT directory under FMW_HOME.
3 - Use the following sections to guide you through patching and the creation of the WebLogic Security Module.
1 - The following patch should be installed
2 - Download Oracle Identity Management Suite Bundle Patch 184.108.40.206.0 from ARU/METALINK (p14760806_111200_generic.zip)
3 – Follow the instructions on the README file for the patch.
The following section is a guide to configuring the WebLogic Security Module. This has been called out separately from the above installation guide as there are a couple of additional steps that are not well documented in creating the Security Module for a JRF (Java Required Files) domain.
Step 1 - Under <OES_CLIENT_HOME>/oessm/SMConfigTool
- copy smconfig.prp to JRFsmconfig.prp
- update the following properties
- Change policystore.type to DB_ORACLE
- Change sm_name to <SECURITY_MODULE_NAME>
Step 2 - Under <OES_CLIENT_HOME>/oessm/bin
- set JAVA_HOME=<FMW_HOME>/<JDK>
- Run SMConfigTool with the following command:
config -onJRF -smType wls -onWLS -smConfigId [SECURITY_MODULE_NAME] -serverLocation <FMW_HOME>\wlserver_10.3 –prpFileName <OES_CLIENT_HOME>\oessm\SMConfigTool\JRFsmconfig.prp
3 - This will now launch the Fusion Middleware Configuration Wizard where you should follow the steps in the guide from section 3.1 in this document noting the following:
- Select Oracle Entitlements Server Weblogic Security Module on JRF 220.127.116.11
- Ensure correct JDK location, Update Listen port and SSL listen port choose ports different from any existing/previous domain.
4 - Ensure that your datasources are set up correctly in the WLS SM domain
- Start up your new SM domain.
- Create 2 datasources in the client SM domain both pointing to the DEV_OPSS schema that you configured with RCU, and specified within the OES installation. Create two separate identical datasources with the following jndi names.
** NB ** make sure that the datasource that you configure are:
- Non XA
- Have “supports global transactions” disabled
5 – Re-configure the SM to support “Distributed-Push” policy distribution
- CD <OES_CLIENT_HOME>/oes_sm_instances/<SM_NAME>/bin
- Run oessmconfig.bat -jpsconfig <SM_DOMAIN>\config\fmwconfig\jps-config.xml
- This will start up the SM configuration tool. Change the following:
- In the “SM Configuration” tab select “Controlled-Pull” as the policy distribution mode
- Select the “Policy Store” tab
- Select “Database configuration through JINDI name”
- Enter the Datasource JNDI name (“jdbc/APMDBDS”)
- Enter the “Farm Name” “cn=<OES_ADMIN_DOMAIN>” e.g. cn=oes_admin
- Enter the “Root Name” as cn=jpsroot
- Select “Save and Close”
The previous steps created the Security Module, the following steps intend to outline the steps to create a test configuration to test the security module.
The following steps are detailed in the following guide:
The following steps are outlined in the “Creating OES Administration Policies” please follow these steps exactly as defined in the document.
The high level steps in creating this policy are:
1 - Log into OES Admin
2 - Create a new Application
3 - Create a new Resource Type
4 - Create a new Resource under the Resource Type
5 - Create a new Authorization Policy
6 – Create the definition of the Security Module (SM) in OES Admin UI
7 - Bind the application to previously created SM.
8 - Distribute policy changes
If you have followed the steps above you should see the HelloOESworld application bound to the physical SM when you distribute the policy as below:
The above steps have configured the following policy:
Resource Type: MyResourceType
The following test web application will make a call to the WLS SM with the application and resource details to seek an authorization decision based on the resource and user.
1 - Deploy the application to the domain containing your SM.
2 – Run the application
- Open a browser and run the application with the following :
- The following page should be displayed
- Changing the policy details on the OES admin server (e.g. changing the userLevel string in the policy to “employee”) should result in a DENIED message. Example below:
Official Oracle OES pages.
OES whitepaper (Good technical introduction & guide)
Tutorial Guide on installing and configuring OES (NB* this is for a Security Module on a non JRF domain, so don’t use the SM config as indicated. See other docs for SM configuration on a JRF domain)