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.