×

IDMWORKS Blog

Oracle Entitlement Server Obligation


There are times when a policy is more effective when returning a piece of information back to the end user.   To setup the basis for obligation we will cover the basics of OES Authorization policy.  When modeling policy in OES they are split up as either static or dynamic.   Policy also takes on behaviors of role-based  and/or attribute-based access.

If an authorization policy is configured with fixed elements, at design time we are pretty much sure of the static final decision.  Dynamic policy are ones that need additional information that is presented at runtime or provided in an external repository.

Policy
The simple Oracle Entitlement Server policy consists of an Effect(Permit/Deny), Principal (user which could equate to a group or role), Resource (the object that you are trying to secure) and an Action (the event you are trying to apply to the Resource).  Example “Permit customer to withdraw from customer checking account”.   Effect is Permit, customer is the Principal, bank account is the Resource, withdraw is the Action.   This is a very static policy.

The policy is deployed and suddenly you have restrictions.   How much money does the customer want to withdraw?   “Permit customer to withdraw from customer checking account in the amount of $100”.  Now the policy takes on conditions.  During the evaluation it will be necessary for the policy to have access to external data to determine if you have the funds available to withdraw. View Figure 1

Figure 1

Backend policy can be constructed with functions and attributes.   Once the policy is evaluated, in the event the policy is denied we want to return a piece of information associated to the denial, this is a good reason to use obligation.   It is used to return information to the end user. “You have insufficient funds in your account”.

Obligations
Obligations in OES are name/value pairs.   You can essentially return more than one obligation.   Obligations are clearly the most complex and need to be used sparingly. OES is providing a grant or a deny on a request.

Examples of using Obligation would be to return a textual error message if you have a deny on a request.   Obligation could be used to provide a redaction where clause for a database sql call.

Obligation should not be used to return large sets of data as there are limitations on size of returns in the OES call.   If you are returning additional conditions as part of the obligation, then you are shifting the burden of the authorization to your end application.

When using OES the key is to ensure that OES is providing the policy decision.  This way if the policy changes it only requires the policy to be modified and not the application.   The application is enforcing the decision it receives.  When deciding to use obligation the rule to follow should be:

If the application is impacted and requires change by a modified policy then you are not using OES correctly.

Questions, comments or concerns? Feel free to reach out to us below, or email us at IDMWORKS to learn more about how you can protect your organization and customers.

Leave a Reply

Your email address will not be published. Required fields are marked *