OEG11gR2 integration with OES11gR2 Authorization with condition

Introduction

This OES use-case has been defined originally by Subbu Devulapalli (http://accessmanagement.wordpress.com/). 

Based on this OES museum use-case, I have developed the OEG11gR2 policy able to deal with the OES authorization with condition. From an OEG point of view, the way to deal with OES condition is to provide with the OES request some Environmental / Context Attributes.  

Museum Use-Case 

All painting in the museum have security sensors, an alarm goes off when a person comes too close a painting. The employee designated for maintenance needs to use their ID and disable the alarm before maintenance.

You are the Security Administrator for the museum and you have been tasked with creating authorization policies to manage authorization for different paintings. Your first task is to understand how paintings are organized. Asking around, you are surprised to see that there isno formal process in place, so you need to start from scratch. the museum tracks the following attributes for each painting

1. Name of the work

2. Painter

3. Condition (good/poor)

4. Cost

You compile the list of paintings

Being a software geek who doesn’t (yet) understand art, you feel that price(or insurance price) of a painting is the most important criteria. So you feel that based on years-of-experience employees can be tasked with maintaining different paintings. You decide that paintings worth over 50 cost should be only handled by employees with over 20 years of experience and employees with less than 10 years of experience should not handle any painting.

Lets us start with policy modeling. All paintings have a common set of attributes and actions, so it will be good to have them under a single Resource Type. Based on this resource type we will create the actual resources.

So our high level model is:

1) Resource Type: Painting which has action manage and the following four attributes

a) Name of the work

b) Painter

c) Condition (good/poor)

d) Cost

2) To keep things simple lets use painting name for Resource name (in real world you will try to use some identifier which is unique, because in future we may end up with more than one painting which has the same name.)

3) Create Resources based on the previous table

4) Create an identity attribute Experience (Integer)

5) Create the following authorization policies

a) Allow employees with over 20 years experience to access all paintings

b) Allow employees with 10 – 20 years of experience to access painting which cost less than 50

c) Deny access to all paintings for employees with less than 10 year of experience

OES Authorization Configuration

We do need to create 2 authorization policies with specific conditions

a) Allow employees with over 20 years experience to access all paintings

b) Allow employees with 10 – 20 years of experience to access painting which cost less than 50

c) Deny access to all paintings for employees with less than 10 year of experience

We don’t need an explicit policy for Deny access to all paintings for employees with less than 10 year of experience, because Oracle Entitlements Server will automatically deny if there is no matching policy.

Testing the OES Authtorization

You can either test the OES Authorization policies with a Java application or with the following WebApp :

OEG Policy

The OEG policy looks like the following

The 11g Authorization filter configuration is similar to : 

The ${PAINTING_NAME} and ${USER_EXPERIENCE} variables are initialized by the "Retrieve from the HTTP header" filters for testing purpose.

That's to say, under Service Explorer, we need to provide 2 attributes "Experience" & "Painting" following the OES 11g Authorization filter described above.