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"/>





Reassigning Leaver tasks in OIM11g

The use case

OIM11g allows arbitrarily complex approval rules to be defined via it's integration with SOA BPEL workflow.  It also allows the management of user lifecycle, for example the classic joiner-mover-leaver cycle.

So what happens to a user's outstanding approvals if the user leaves the company or for example enters a disabled state for some reason ?  Failure to address this point leaves end-user requests stalled, waiting on an approver who may never respond.

The solution

Using a combination of OIM11g's event handlers to detect an event and the SOA Workflow Services API one can easily address this by reassigning leaver tasks to some agreed user.

This JDeveloper project implements an OIM11g scheduled task that scans for user's in a Locked state and reassigns their outstanding approval tasks to their manager.  The MDS data for the scheduled task is included in the config directory.  The scheduled task can be loaded to OIM as described here.  One can use the same technique in an event handler to do the reassignment at the moment where the user enters a Locked or Disabled state.  Note that once the user is Disabled one cannot reassign the approval tasks...so we have to make the reassignment action before the user is disabled.

The task scans all users matching the regular expression parameter to the scheduled task.  For each such user it uses the Workflow Services API to recover any tasks assigned to that user that are in the IWorkflowConstants.TASK_STATE_ASSIGNED or IWorkflowConstants.TASK_STATE_INFO_REQUESTED states--we are only interested in reassigning currently active tasks.  See the getTasksForUser() method.  OIM can recover the parameters (username, password, SOA URL) to talk to SOA using the following code:

  BPELConfig bpelConfig = Platform.getConfiguration().getBPELConfig();

For each task currently assigned to a target user we use the reassignTask() method to reassign the task to the user's manager, or to a hardcoded user if no manager is configured.  The key call to the Workflow Services API is this one, where wfCtx is the Workflow context and taskSvc is a reference to the task service:

  taskSvc.reassignTask(wfCtx, t.getSystemAttributes().getTaskId(),  newAssignee);

In the sample code one can see how to go from the BPEL Config object to recovering a task service and workflow context objects that can be used to do this reassignment.

Conclusion

OIM11g allows us to detect and responds to user-lifecycle events in a agile way, ensuring that any business processes in flight are kept moving in the face of user's entering locked, disabled or deleted states.

References

  • SOA Workflow Services Developers Guide: examples of using the Worklist API
  • Jar files required for the WorkList Services API.  These jar files are available with JDeveloper: Use the Help->Check For Updates menu to install the SOA Extension:
    • soa/modules/oracle.soa.fabric_11.1.1/bpm-infra.jar
    • soa/modules/oracle.soa.fabric_11.1.1/fabric-runtime.jar
    • soa/modules/oracle.soa.workflow_11.1.1/bpm-services.jar
    • oracle_common/modules/oracle.xdk_11.1.0/xml.jar
    • oracle_common/modules/oracle.xdk_11.1.0/xmlparserv2.jar
  • SOA Workflow Services API Javadoc




Monday Oct 17, 2011

OIA: Entitlements outside roles in BI Publisher

My colleague Rene has some great postings explaining the importance of keeping an eye on entitlements that fall outside roles whilst developing an RBAC model and how to achieve that within OIA.

In this posting I just add another example report which will expose entitlements falling outside roles but this time formatted for use with BI Publisher.  This will be useful to customers wishing to use BI Publisher as a reporting tool.

When loaded into BI Publisher the report will generate a listing by Business Unit, by Resource, by user for all the user's entitlements that fall outside the role model.  You can specify a Business Unit and Resource as parameters to the report.  This report will only include attributes flagged as minable to allow it to avoid including attributes that are unimportant from an entitlement  point of view (like Firstname, for example).

 The two BI Publisher files which define this report--the.xdo file which contains the SQL definition and the .rtf formatting file--are available here.

About

user12587121

Search

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