Friday Apr 06, 2012

Securing an ADF Application using OES11g: Part 1

Future releases of the Oracle stack should allow ADF applications to be secured natively with Oracle Entitlements Server (OES).

In a sequence of postings here I explore one way to achive this with the current technology, namely OES 11.1.1.5 and ADF 11.1.1.6.

ADF Security Basics

ADF Bascis

The Application Development Framework (ADF) is Oracle’s preferred technology for developing GUI based Java applications.  It can be used to develop a UI for Swing applications or, more typically in the Oracle stack, for Web and J2EE applications.  ADF is based on and extends the Java Server Faces (JSF) technology.  To get an idea, Oracle provides an online demo to showcase ADF components.

ADF can be used to develop just the UI part of an application, where, for example, the data access layer is implemented using some custom Java beans or EJBs.  However ADF also has it’s own data access layer, ADF Business Components (ADF BC) that will allow rapid integration of data from data bases and Webservice interfaces to the ADF UI component.   In this way ADF helps implement the MVC  approach to building applications with UI and data components.

The canonical tutorial for ADF is to open JDeveloper, define a connection to a database, drag and drop a table from the database view to a UI page, build and deploy.  One has an application up and running very quickly with the ability to quickly integrate changes to, for example, the DB schema.

ADF allows web pages to be created graphically and components like tables, forms, text fields, graphs and so on to be easily added to a page.  On top of JSF Oracle have added drag and drop tooling with JDeveloper and declarative binding of the UI to the data layer, be it database, WebService or Java beans.  An important addition is the bounded task flow which is a reusable set of pages and transitions.   ADF adds some steps to the page lifecycle defined in JSF and adds extra widgets including powerful visualizations.

It is worth pointing out that the Oracle Web Center product (portal, content management and so on) is based on and extends ADF.

ADF Security

ADF comes with it’s own security mechanism that is exposed by JDeveloper at development time and in the WLS Console and Enterprise Manager (EM) at run time.

The security elements that need to be addressed in an ADF application are: authentication, authorization of access to web pages, task-flows, components within the pages and data being returned from the model layer.

One  typically relies on WLS to handle authentication and because of this users and groups will also be handled by WLS.  Typically in a Dev environment, users and groups are stored in the WLS embedded LDAP server.

One has a choice when enabling ADF security (Application->Secure->Configure ADF Security) about whether to turn on ADF authorization checking or not:

In the case where authorization is enabled for ADF one defines a set of roles in which we place users and then we grant access to these roles to the different ADF elements (pages or task flows or elements in a page).

An important notion here is the difference between Enterprise Roles and Application Roles. The idea behind an enterprise role is that is defined in terms of users and LDAP groups from the WLS identity store.  “Enterprise” in the sense that these are things available for use to all applications that use that store.  The other kind of role is an Application Role and the idea is that  a given application will make use of Enterprise roles and users to build up a set of roles for it’s own use.  These application roles will be available only to that application.   The general idea here is that the enterprise roles are relatively static (for example an Employees group in the LDAP directory) while application roles are more dynamic, possibly depending on time, location, accessed resource and so on.  One of the things that OES adds that is that we can define these dynamic membership conditions in Role Mapping Policies.

To make this concrete, here is how, at design time in Jdeveloper, one assigns these rights in Jdeveloper, which puts them into a file called jazn-data.xml:


When the ADF app is deployed to a WLS this JAZN security data is pushed to the system-jazn-data.xml file of the WLS deployment for the policies and application roles and to the WLS backing LDAP for the users and enterprise roles.  Note the difference here: after deploying the application we will see the users and enterprise roles show up in the WLS LDAP server.  But the policies and application roles are defined in the system-jazn-data.xml file. 

Consult the embedded WLS LDAP server to manage users and enterprise roles by going to the domain console and then Security Realms->myrealm->Users and Groups:


For production environments (or in future to share this data with OES) one would then perform the operation of “reassociating” this security policy and application role data to a DB schema (or an LDAP).  This is done in the EM console by reassociating the Security Provider.  This blog posting has more explanations and references on this reassociation process.

If ADF Authentication and Authorization are enabled then the Security Policies for a deployed application can be managed in EM.  Our goal is to be able to manage security policies for the applicaiton rather via OES and it's console.

Security Requirements for an ADF Application

With this package tour of ADF security we can see that to secure an ADF application with we would expect to be able to take care of at least the following items:

  1. Authentication, including a user and user-group store
  2. Authorization for page access
  3. Authorization for bounded Task Flow access.  A bounded task flow has only one point of entry and so if we protect that entry point by calling to OES then all the pages in the flow are protected. 
  4. Authorization for viewing data coming from the data access layer

In the next posting we will describe a sample ADF application and required security policies.

References

  1. ADF Dev Guide: Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework: Enabling ADF Security in a Fusion Web Application
  2. Oracle tutorial on securing a sample ADF application, appears to require ADF 11.1.2
  3. Now, securely deploying your secured ADF application

Monday Oct 24, 2011

Using OES11g from the Oracle Database

Future versions of the Oracle database may include integration with Oracle Entitlement Server for fine grained authorization configuration.  However with the current versions (11g, 10g for example) any such integration is not available out of the box.

How then might we use OES to protect data in an Oracle database ?

As an example, consider a stored procedure querying and returning values from some database tables.  We can use OES to provide authorization on this data in the following way: we ask OES for an authorization decision and if the decision is allow we interpret any obligations as additional where clauses that we use to constrain the queries.

With OES performance is best if we can make the call from a Java SM client as we can then benefit from local copies of the authorization policies This reduces the overhead of the call to OES to the microsecond level.  So in the case of our stored procedure, if it is being invoked from Java, then it would be best to call OES from Java and pass in any constraints to the stored procedure as parameters.  However this may not always be possible.

In this case we can use the facility of the Oracle database to load java classes and to call them from stored procedures.  As OES offers a webservice XACML interface one could load some Java code that would call out to OES. Another technique would be to use the OES gateway from my previous posting, calling it using a very simple Java class that does a HTTP GET for the appropriate URL.

This set of scripts and SQL demonstrate how to load such a Java class to the Oracle database and configure a database function to allow the Java class to be called from a sample SQL script. If one is using Oracle 10g database then as it has a 1.4 JDK one must compile the class with JDK 1.4.  Oracle Database 11g has a 1.5 JDK so JDK 1.5 can be used in that case.

 The steps to prepare the example are:

  • compile the Java class with the appropriate JDK (use the mk.sh script)
  • load the java classes to the data base (use the oes-loadjava.sh script)
  • run the database preparation script to define a function to interface to the Java class and allow the database user appropriate permissions to execute Java code.  The example assumes the user SYSTEM is being used.
  • run the SQL script to show the usage of the call to OES.  It runs a raw query on the scott.emp table with no constraints and then it calls the Java class which will call the OES Gateway to recover an authorization from OES.  If there are obligations returned the procedure looks for an obligation key of scott.emp and if it finds one it uses the value--for example (sal<2000)-- as a constraint when querying the table.

References



A RESTful interface to Oracle Entitlements Server 11g

OES's job is to provide authorization decisions to clients.  Clients may use a Java API implementing the OpenLiberty OpenAZ PEP API interface as well as an XACML web service interface.

However it may be easier for some clients to query OES over a REST style API.  This applies particularly to old Java or non-Java clients or to clients running in more restricted environments such as smart phones or other embedded devices.  Another example would be a stored procedure running in a database.  The ability to query a server using the REST style--essentially using HTTP URLs--simplifies the client by reducing dependencies and simplifying the interface.

In this posting I demonstrate a gateway to OES that that presents a natural REST style interface accessing the OES client PEP API.

The PEP API

 Firstly, recall the OpenAZ PEP API.  A typical call to the Java client API would look something as follows:

  contextMap.put("level","5);
  contextMap.put("speciality","Energy");
  PepResponse response =
    PepRequestFactoryImpl.getPepRequestFactory().newPepRequest(
      "glen.byrne",                             //subject
      "execute",                                //_action,
      "TradingApp/Options/BlackScholes/UK-Gas", //resource
      contextMap).decide();                     //attributes map
  System.out.println("Response from OES for request: {" + user + ", " +
    action + ", " + resource + "} \nResult: " + response.allowed());
  Map obligations = response.getObligations();

The request asks whether a given subject (with a context Map of attribute value pairs) has the right to carry out an action on a specific resource.  The so called obligations are a list of key/value pairs, returned with an allowed decision, which the client may interpret as refinements to the authorization decision.  For example, they might provide a where clause to allow a database client to provide which rows of a table a user is allowed to see.

Ầ la REST

A natural way to encode such a query as an HTTP request would be to issue an HTP GET for a URL such as the following:

http://<machine>:<port>://<context root/TradingApp/Options/BlackScholes/UK-Gas/execute?user=glen.byrne&level=5&speciality=Energy

So we are mapping the resource to a URL and the user and context map are passed as query parameters.

This small JDeveloper project implements a gateway to OES which provides such an interface to OES.

To deploy the gateway you must deploy it to a Weblogic 10.3.5 domain which has been prepared as a WLS SM with the OES 11g Client.  This is a standard operation to configure a WLS domain to support Web applications calling to OES.  Once deployed you may test the gateway by accessing the URL htp://localhost:7001/oesgateway/sayHello.  This will return the string 'Hello World!'

Once you have configured OES with an Application, Resource Type, Resource and Authorization policy you can then query OES via the gateway by accessing URLs as shown in the example above.  The general pattern is that all context attributes are passed as query parameters and you access a URL of this form: http://localhost:7001/oesgateway/<resource string>/<action>/?user=<user name>.

A web browser can be used to access the URLs from the gateway.  A client program accessing the gateway is included in the project and a very simple Java program directly executing a HTTP get is available here.

The gateway depends on the Jersey 1.2 API and the OES 11g 11.1.1.5 Client API.

Note that in order for the resolution of user groups to work you need to ensure that the jps-config.xml file where the Gateway is deployed has it's identity store configured--look for the following elements in that file:

  • <serviceProvider type="IDENTITY_STORE" name="idstore.ldap.provider" class="oracle.security.jps.internal.idstore.ldap.LdapIdentityStoreProvider">
                 <description>LDAP-based IdentityStore Provider</description>
      </serviceProvider>
  • <serviceInstance name="idstore.ldap" provider="idstore.ldap.provider">
                 <property name="idstore.config.provider" value="oracle.security.jps.wls.internal.idstore.WlsLdapIdStoreConfigProvider"/>
                 <property name="CONNECTION_POOL_CLASS" value="oracle.security.idm.providers.stdldap.JNDIPool"/>
    </serviceInstance>
  • <serviceInstanceRef ref="idstore.ldap"/>





About

user12587121

Search

Categories
Archives
« July 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
  
       
Today