Example of Context-Based Authorization Reducing Number of Policies

Access control requirements have morphed from URL to group-based policy to an attribute/risk/role-based object and data model.   Objects in portals no longer have unique URLs (WebParts in Sharepoint for instance).  Policy enforcement of web services, REST and data are becoming more prevalent as requirements.  A platform that only does HTTP cannot be centralized if it doesn’t have a story for these other protocols.  

Trying to model authorization with a traditional Web Access Management (WAM) product is tedious, especially if it can't accept contextual attributes from the calling component or Policy Enforcement Point (PEP).

Let's say you have a financial institution that has a number of reports:  Summary and Detailed, each with multiple regional (East and West) and content (Stocks and Bonds).  2x2x2=8 different reports.  Let's pretend we have the following actors:

Name	Type	Level	Region	Qualified
Charlie Gild	Customer	Gold
Chad Silva	Customer	Silver
Ed Easton	Employee-Broker	N/A	East	Stocks
Ender Wiggins	Employee-Broker	N/A	West	[Stocks, Bonds]
Paul	Partner	N/A

The institutions have the following policies:

• Employee-Brokers can only view account reports within their own region and what they are qualified to trade (stocks, bonds, or both)
• Gold-level customers can view detailed and summary account and can transfer funds up to 20K
• Silver customers can only see summary account info and can transfer funds up to 10K

In order to implement this with a URL-structure today, one would need a large number of policies:

PERMIT:
/summary/bonds/east -> [employees.region=east AND employees.qualified=bonds | both ] OR partners OR customers
/summary/stocks/west -> [ employees.region=west AND employees.qualified=stocks | both ] OR partners OR customers
/summary/stocks/east -> ...
/summary/stocks/west -> ...
/detailed/bonds/east -> [ employees.region=east  AND employees.qualified=bonds | both ] OR customers.level=gold
/detailed/bonds/west -> ...
/detailed/stocks/east -> …
...

Contrast this with context aware authorization:

PERMIT (view, Employees, Reports) if Report.Type IN [Subject.Qualified] AND Report.Region = Subject.Region
PERMIT (view, Customers, Detailed) if Subject.Level=gold
PERMIT (view, [Customers, Partners] , Summary)
PERMIT (transfer, Customers, Funds) if amount < 10K
PERMIT (transfer, Customers, Funds) if Customer.level = gold AND amount < 20K

Dynamic context-based policies are must more dynamic and easier to manage.  These policies assume that the PDP can:

1) Accept context from the PEP that can be used in the policy.  The Report.Region is an example of the context attribute which is known by the content management system that holds the report as metadata.

2) Lookup attributes at decision time from a PIP.  Customer.level is an example of a persisted entitlement for the Customer.

3) Evaluate a hierarchy of resources.  Detailed and Summary would inherit from 'Reports' in the first policy above.

Let's put it to the test:  Let's say Ed Easton requests a detailed east region bonds report.  The first policy would by most applicable.  The last part of the constrain would return true as the Report.Region (East) matches what Ed has in the directory (East).  However, the Report.Type (Bonds) is not in the list of equities he is qualified for.  Ed is denied access to that report.  

These examples are a little contrived, but hopefully they help illustrate the point.

Comparing OES 10g with OES 11gR2

Oracle Entitlements Server has been through more name changes and re-writes than any other product in history.  Okay, that's probably a reach, but it's had its fair share.  The most recent release is OES 11gR2 (11.1.2).  Most implementations of OES are version 10g, which is based on the BEA implementation.  Oracle set out with some ambitious goals for OES and have met a number of milestones in this rev.  This post outlines some of the differences. Documentation home for 11gR2 is here.

Conceptually, OES 11gR2 is the same:  You have a standalone Policy Decision Point (PDP) that handles authorization requests from web service and RMI client (language agnostic) and a Java-based embedded PDP/PEP (The 'E' being Enforcement) API for any Java container.  Both models can take context in the form of attributes from applications and use the context values in policy decisioning.  Both models can pull attributes from Policy Information Points (PIP) like Database and LDAP, usually querying on Subject.

Implementation of this policy engine differs significantly, however.  Some of my favorite improvements:

• Constraint editor: Where in 10g, you had a free-form text box where you had to know the various expression language and functions, in 11gR2 you have an editor that gives you list operations, drop-down boxes for type-specific expressions, and lists of available attributes.
• Policies can be written directly against external groups and users:  In 10g, you basically had to replicate users and groups in the OES 10g Identity Store in order to compose policy against these entities.  In 11gR2, you can browse external directories and write policy against external users & groups.
• Improved runtime and management APIs: The PEP API in 11gR2 has been greatly simplified, without sacrificing functionality.  The BLM API in 10g was simply a mess, versus the 11gR2 Management API, which is intuitive.

Some potential reasons for not moving to 11gR2:

• The 10g Policy Administration Point (PAP) ran on Tomcat (though it wasn't a pure Java EE solution) as well as WebLogic, where 11gR2 is only WebLogic today.  You could use a number of non-Oracle databases as well, where 11gR2 only supports Derby and Oracle.  
• The WebLogic authorization story changed significantly in 11gR2.  Instead of leveraging the Authorization and Role Mapping providers in WebLogic, OES plugs in at the JPS/OPSS layer.  For those using OES for WebLogic container authorization, this could be a challenge (not that it was frictionless before).  Long-term, the 11gR2 solution is better, with auto-deployment of applications into OPSS automatically being managed by OES when they share the same policy store.  

Oracle has definitely left its fingerprint on this revision of OES, with probably little of the CrossLogix & BEA codebase remaining.  Where some other Oracle ADF consoles can be pretty clunky, the Authorization Policy Management (APM) console for OES is fairly good, IMO.

While the initial 11gR1 (11.1.1.5) release had some missing pieces from 10g such as Policy Simulation and SharePoint support, the 11gR2 release has tidied up those deficiencies.  My wish list going forward is better tooling for development, especially in the area of data security (handling multiple predicates in an obligation on the client side).