Just-In-Time Versus Asynchronous Provisioning

There are multiple options for getting identities into and out of external service providers (SP).  This is often dependent on what the SP supports.  Some SPs support Just-in-Time (JIT) Provisioning, which means that the service provider will consume SAML attributes upon login and either create the user if he/she doesn't already exist in the SP's user store, or update the local account if any of the attributes differ from what is sent in the assertion.  This is secured by the inherent trust of the SAML authentication.  The downsides of JIT provisioning are that you typically cannot de-provision a user.

Asynchronous provisioning utilizes some kind of scheduled job or user interactive method of synchronizing identities from one or more sources to the service provider.  This typically involves a polling of the authoritative user store and pushing any adds, deletes, inactivates, changes, etc. into the target.  The target service provider must provide some kind of provisioning service in order for this to work.   Many of the provisioning vendors have implemented connectors/adapters for SPs like Google, WebEx and SalesForce using their respective APIs.  Each of these are one-off implementations and most SPs don't provide any kind of public provisioning hooks today.

An Oasis standard called SPML for provisioning was created over 10 years ago, but has lacked in adaption (so much so that I won't bother to even spell out the acronym).  Its failure was likely in its lack of granularity for updating profiles and the general complexity of implementing a SOAP-based service.  Simple Cloud Identity Management (SCIM) is a likely successor for SPML.  Plenty of information on SCIM at http://www.simplecloud.info, but SCIM's use of REST and the timely need for it with the proliferation of cloud service providers will drive higher adaption.

This matters because the natural progression of these cloud providers will be the aggregation of these services into packaged offerings.  Identity propagation will be key to enabling these aggregations and you can't propagate identity easily without having an account at the SP.  Thus, end-to-end user lifecycle will require that accounts are provisioned and de-provisioned from the SPs from that 3rd party aggregator.   SCIM enablement will be a big land grab for provisioning vendors going forward.

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).