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.
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.
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.
Here:
Manager of the Front Officeis 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.
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 :
Focus on Oracle API Gateway main features in the scope of this use-case
Focus on Oracle Entitlements Server main features in the scope of this use-case
