Entitlement Policy and The Real World

Bookmark Blog Post

	del.icio.us
	Digg
	DZone
	Furl
	Reddit

Bill Dettelback's Blog | February 26, 2008   8:12 AM | Comments (0)

When you externalize your application's entitlement policies using a product like ALES, it quickly becomes clear that you need to be able to take into account the real world.  This is typically the case when a policy needs to access some information that is sitting in another application, service or database.

Let's take a really simple example.  Say that you have an application that is controlling access to rooms in a complex through doors that are protected by  badge readers.  Every time someone enters or exits the room they must scan their badge to get the door to open.  There is a policy that states that only valid employees are allowed in these rooms, and another policy that states that only certain employees can use data center doors after hours.

Using ALES to manage these entitlements is quite simple (putting aside the messy details of integrating with the badge reader application).  We can construct a resource tree with a separate node for each door in our complex:

We can establish an overall policy that states that only users who are valid Employees can access the Door resource.  By placing the policy in the parent node we can protect all child nodes with a single policy.  So how do we know someone is a valid Employee?  We need a role mapping policy that checks the individual asking for authorization (e.g. scanning their badge) has a valid employment status in their corporate profile:

But how do we get this employment status into ALES?

ALES Attribute Retrievers come to the rescue.  In ALES 3.0 we support three types of Attribute Retrievers:

• LDAP
• RDBMS
• Service Data Objects (for example, AquaLogic Data Services Platform)

We can configure the SSM protecting the Badge Reader application with an Attribute Retriever that knows how to access our corporate directory (in this case we'll use an RDBMS directly but for a real enterprise you'd probably have a service layer instead).  If we assume we're using the Web Services SSM, we'll do this directly through the ALES Administration Console:

Now we can define an Attribute in ALES called emp_status which corresponds to the value in the EMPLOYMENT_STATUS column of our fictional EMPLOYEES table.  The Attribute is defined using a simple SQL statement using the user's login name (let's assume we've already established how to map the badge number read by the door scanner into a username):

Now we can write the following policy to make sure Doors are only available to valid Employees:

The highlighted policy reads, "Grant the action 'open' for the resource 'Doors' to anyone in the role 'Employee' if their emp_status is 'valid'.  If someone swipes their badge and isn't mapped into the role Employee, then this policy will not apply and the door will not open.

But what about our policy that states only certain users can access the data center after hours?  This will be a combination approach- we will set up an attribute retriever to get our job code and use ALES' built in time functions to constraint the hours of day for the policy (let's assume the data center is available to folks with Job Code 'ABC123'  between the hours of 6 pm and 7 am).

Notice that our first policy granting access to all Employees for Door resources is inherited by the DataCenter resource.  This means that we actually need to write our policy to deny access after hours unless you happen to be in the correct Job Code.  If you find yourself writing a lot of deny policies it sometimes makes sense to rethink the grant policies that you've established higher up in the resource tree.

So you can see how simple it is to construct ALES policies that refer to data sitting in "the real world".  The configurable Attribute Retriever feature in ALES makes it possible to pull in data sitting in LDAP, an RDBMS or even SDO data source without writing a line of code.

Now we just need to get cracking on that integration with badge reader systems...

Comments