Fine Grained Authorization with OAG11gR2 & OES11gR2

Dealing with Fine Grained Authorization

It is a common use-case, when having access to citizen, customer or patient information by numerous users with different roles to allow or deny access to specific piece of information. So basically the solution needs to address the following requirements :

  • we need to protect the citizen, customer or patient information from unauthenticated or unauthorized access

  • even authenticated/authorized users don't need necessarily to have access to the same level or detailed information. According to your role you are granted to, the users have access to ALL or a PART of the information. In other world, some pieces of information need to be removed, obfuscated or encrypted according to your role

  • the policy modeling should be easy to understand, flexible enough to accommodate unforeseen changes.

It could be an issue with a lack of flexibility to implement this behavior at the service level it self. What's happen it there is a need to change very quickly the access authorization following new rules published by the security officer or authority.

As a recap, the solution we are looking for needs to address the key features listed here below :

  • protect information access from unauthenticated and unauthorized user : this is exactly the scope of Oracle Entitlements Server able to deal with Fine Grained Authorization

  • modify through different mechanisms (subtract, encryption...) the response payload of the requested service : this one is the scope of Oracle API Gateway.

In following tutorial, we are considering a BankService domain and we will enlighten the way to implement fine grained authorization policies with Oracle API Gateway and Oracle Entitlements Server.

1. BankingService Use-case overview

The IT manager of the “ACME-OneLine” bank needs to implement a set of new Authorization policies to protect customers banking information. Obviously, the new policies need to be revisited & updated on a regular basis. This not an option to implement these policies in the SOA layer.

  • The bank employees belonging to the “BankManager” profile may have access to all the customer's information and are able to perform all types of operation {Update, Create, Delete, Read, Lock}

  • The bank employees belonging to the “BankClerk” profile may have access to the customer's information except the CreditCard detailed information and are able to perform only the {Read} operation

  • The other bank employee are not able to gain access to the customer's information.

Furthermore, as the “ACME-OneLine” bank plans also to externalize on the Cloud a subset of the bank services, it is also required to be able to re-enforce the security aspects with some advanced XML Threat protection.

Having in mind the constraints to be addressed by the IT manager, we can easily think of OAG and OES as key components to be deployed in the new security architecture of the “ACME-OneLine”. Let's have a look how these 2 products combined together address the very common scenario.

2. OES Policy Model

A simple Oracle Entitlements Server policy consists of Effect (Permit/Deny), Principal (user who is trying to access your system), Resource (the object you are trying to secure) and an Action (the Action they user is trying to perform).

For example, “The Manager of the Front Office wants to consult the Banking information of M. Joe Doe.


Manager of the Front Office is the principal,

Banking information of M. Joe Doe is the resource

consult is the action.

Oracle Entitlements Server offers as well a very nice concept of “obligation” associated to an authorization policy.

As a short introduction, we can describe an OES obligation as :

There are times when a policy has to return a piece of information back to the caller. For e.g. as part of policy evaluation we want to send a message back to user about why the request was denied or maybe display a phone number where they can talk to a support person and get some help. A more advanced use case is where PDP cannot make a conclusive decision and needs external help to satisfy the authorization policy. For example, if Oracle Entitlements Server is being used authorize information sent to partners over web services. You might want to have a policy that depending on the partner, customers’ credit card numbers need to be encrypted with a special key. Oracle Entitlements Server in itself cannot encrypt Web Services; rather it can work with other products such as XML Gateway to encrypt the message. In this case when XML Gateway gets a SOAP message, it calls into Oracle Entitlements Server for an authorization decision. Oracle Entitlements Server gives a Permit but add an obligation that XML Gateway needs to encrypt the message before sending the SOAP payload to the partner.

3. Architecture

In order to implement the fine grained authorization policies described above we can easily combine Oracle API Gateway (OAG) and Oracle Entitlements Server :

The following sequence diagram is also an easy way to understand the interaction of the sub-systems of this solution :

4. OES Authorization Configuration

In this example, we do need to create 2 authorization policies respectively for the BankManager and BankClerk with specific obligations.

a) Allow BankManager to access all the customer banking information

For this one we don't need to define any obligation because we just want to forward to the client application ALL the data returned by the Legacy Record Customer Application.

b) Allow BankClerk to have a limited access to the customer banking information

For this one, obviously an obligation is required. We have an obligation ClerkReadCustomerInformation with an attribute Obligation4ReadCustomerInformation. At last, the value of this attribute is HideCustomerCardInformation. Later on with OAG, once we have retrieved the obligation from the OES authorization reply, we will test the value of this attribute to remove some data returned by the Legacy Record Customer Application.

c) Deny access to BankEmployee

We don’t need an explicit policy for Deny access to BankEmployee, because Oracle Entitlements Server will automatically deny if there is no matching policy.

5. Testing the OES Autorization

You can either test the OES Authorization policies with a Java application, a web app or the simulator utility embedded into the OES Admin console

a) Test of the OES authorization for the BankClerk with the webapp

b) Test of the OES authorization for the BankClerk with the OES simulator



6. OAG Policy

The main point of this policy is to use a switch filter to test the obligation's attribute value returned eventually by OES :

OES returns ONLY an obligation when the is BankClerk

If this attribute is HideCustomerCardInformation a specific policy is called to remove a couple of XML node with some Xpath expressions

7. Focus on Oracle API Gateway main features in the scope of this use-case

8. Focus on Oracle Entitlements Server main features  in the scope of this use-case


Post a Comment:
  • HTML Syntax: NOT allowed

This blog is about Software How-to & Best Practices


« July 2016