Writing managable policies in OES

I've been meaning to write this down for quite a while and never had the time to do the subject justice. I'm not sure that I have the time now, or that I've done the subject justice, but this is my attempt to describe the most common mistakes made by new users of OES.

Creating policies in OES is easy. Creating a manageable set of policies is easy too, but it usually requires a bit of forethought.

When you write a Authorization policy in OES you pick from a menu of options to fill in 5 boxes:

1. Effect - one of Grant/Deny/Delegate
   
2. Privilege AKA Action
   
3. Resource
   
4. Subject - user(s), group(s) or Role(s) or some combination thereof
   
5. Constraint
   

The first thing new users of OES do is create a few users in OES' database and then start writing policies directly on those users. Something like

• grant Alice access to Report123
  
• grant Alice access to Report124
  
• grant Alice access to Report125
  
• grant Alice access to Report126
  
• grant Alice access to Report127
  
• grant Bob access to Report123
  
• grant Bob access to Report124
  
• grant Charlie access to Report123

OES supports this sort of deployment and there's nothing actually wrong with using OES with this model.

Well nothing except that it's unmanageable.

Why?

Why shouldn't Charlie have access to Report124? When Charlie gets that big promotion which additional reports does he need permission to access? When we hire Dave which reports does he need to access?

It's much better to write your policies on Roles:

1. grant SupportReps access to Report123
   
2. grant TealLeads access to everything that SupportReps have
   
3. grant TeamLeads access to Report124
   
4. grant SupportManagers access to everything that TeamLeads have
   
5. grant SupportManagers access to Report125, Report126 and Report127
   

If you do things The Right Way these roles are hierarchical - the SupportRep role is below TeamLead which is in turn below SupportManager. This means that rule #2 and #4 go away.

Then you create policies to grant the SupportRep role access to the resources that a support rep needs, etc.

And that's the standard pitch for Role Based Access Control (RBAC)


Once you get your head around RBAC the next logical question is "Is there a standard way to automatically load/maintain users in OES?" (an actual question posted to OTN forums).

The answer is you probably don't need to do that.

Really.

The only things you need to put in OES' user database are those that you want to directly use in an OES policy.

If you have all of your users in an LDAP directory or an existing database then why would you want to replicate all of that into another database? Even with provisioning it's an unnecessary complication since an OES Security Module can be configured to use your existing directory or database simply by configuring the appropriate Authenticator. When a user actually logs in the Authentication Provider will go to your user directory, authenticate the user and gather up all of their group memberships. That information gets stored in the JAAS subject as a list of Principals, and at authorization time the JAAS subject is where OES gets the information it needs about the user.

So in our example if you wanted to create a policy to grant the SupportManager Role to everyone in a group named "SupportManagerGroup" in your LDAP directory then you would need to create a group with the same name in OES' database. You do not need to create the users in the OES GUI or through OES' management APIs. And you certainly don't need to maintain group memberships in OES' policy database.

Actually granting that Role to the existing group of users is trivial - go to the Roles tab in OES click New to create a new Role policy and pick the group off the list.

Doing all of that gets us down to

• grant Alice the SupportManagers Role
  
• grant Bob the TeamLead Role
  
• grant Charlie the SupportRep Role
  
• grant SupportReps access to Report123

grant TeamLeads access to Report124

grant SupportMangers access to Report125, Report126, Report127

But we're not done yet because there's one further simplification possible.

So far we've been talking about Report123, Report124, Report125, Report126, and Report127 as named objects in OES. OES allows you to do that and again there's often absolutely nothing wrong with creating all of those objects in OES directly. If you have a small number of objects or don't add and remove objects often this is perfectly reasonable and easily manageable. But if you have hundreds or thousands of objects or you add and remove objects frequently this can quickly become troublesome.

Objects in the actual application, like Reports, almost always have some metadata. In this example they might contain a Region and Department number. Further let's assume that a user has a single department, and is associated with one or more regions.

A simpler way to express the authorization policy might then simply be to say:

• A user may see reports associated with their department and one of their regions

When you write the policy in OES you pick off the menus

Effect: Grant

Action: view

Resource: //Reports

Subject: Role/SupportRep

and then you enter a constraint that compares the department on the report with the user's department and compares the region on the report with the list of regions associated with the user.

In OES this represented with the syntax:

grant( view, //Reports, //Roles/SupportRep ) if reportDepartment = userDepartment and reportRegion in [userRegions]

So all told we went from eight hard to understand policies to four policies - three to grant roles and one for authorization. And when we hire, fire, promote, demote or do anything else with users we don't have to touch OES.