How To Become The Big Cheese

Bookmark Blog Post

	del.icio.us
	Digg
	DZone
	Furl
	Reddit

Bill Dettelback's Blog | July 24, 2007   1:19 PM | Comments (0)

I was talking recently with a colleague of mine about this emerging space of Enterprise Role Management.  It seems like the idea of rationalizing the use of roles across the organization is a top priority for those folks who spend their time thinking about Identity Management issues.  Our conversation got me thinking about a role management problem a customer posed to me a while back.

This company is a huge entity that is essentially run by a hierarchy of 35 top executives.  When any one of these individuals makes a request for information, the IT organization drops everything and jumps.  This particular IT group was working on a large effort to streamline how data flows throughout their operations, and naturally executive dashboards were a big part of the equation (and funding model!).  So their challenge was this- how do they identify these 35 executives in such a way that they can provide fine grained access to highly strategic (and sensitive) corporate data quickly and cost effectively.  At first this sounds pretty simple, since you just need to make an ACL with the 35 executives and you're done.  But the problem gets harder.  There is little to no corporate directory information that identifies these individuals as being part of this elite group, and the universe of services and applications that need to know their status as a top executive will be constantly changing.

What is needed is a way to create a single role called "Big Cheese" that we can assign the executives into and provide a way for applications and services to leverage this role no matter where they are.  ALES makes this easy.  Because role assignment is inherently dynamic, we can create some quick policy to either manually place users into the Big Cheese role or leverage whatever user attributes we can find in the corporate directory.  For example:

grant (//role/BigCheese, //app/policy/ExecutiveDashboard, //ldap/Jack);

grant(//role/BigCheese, //app/policy/ExecutiveDashboard/RevenuePortlet, //sgrp/Finance) if SalaryGrade > 6;

The two policies above read, "Place the user named Jack into the role of Big Cheese for anything under the Executive Dashboard", and "Place anyone in the Finance group into the role of Big Cheese for the Revenue Portlet under the Executive Dashboard if their salary grade is more than 6." 

The first policy can be used when we have really no identifying attributes for a user but still need to place them into a role during policy evaluation.  The second policy can be used when we have enough information about a user community to place them into a role.

What's compelling about this approach isn't so much that we are dynamically assigning to roles, but rather that with ALES these same role mapping policies can be used by any number of portals, service busses, data services, business processes, etc.   Just a few simple policy statements can quickly establish role membership that can then be leveraged across the enterprise.  ALES provides a very straightforward API (used internally by many BEA products) that can answer the question, "what roles does this authenticated subject have?".

What happens when Jack finds greener pastures with another company?  Or what happens when you need to tighten up the access to Revenue numbers?  Just change the policies.  Centralized policies are a beautiful thing when it comes to handling change.

Comments