« September 2007 |
Main
February 2008 Archives
Bill Dettelback's Blog
William Dettelback's Homepage
Bill currently works on the AquaLogic Enterprise Security team. His focus is on customers implementing SOA Security, particularly Authorization and Entitlement solutions. Bill has been helping customers develop solutions in Financial Services, Telecommunications and Healthcare for BEA since 2002. Bill has a Bachelor's of Science in Computer Science and Master's of Science in Computer Science from New Jersey Institute of Technology.
Entitlement Policy and The Real World
Posted by BillDet on February 26, 2008 at 8:12 AM | Permalink
| Comments (0)
| TrackBack (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...
ALES 3.0- What's New?
Posted by BillDet on February 7, 2008 at 2:16 PM | Permalink
| Comments (0)
| TrackBack (0)
BEA recently released AquaLogic Enterprise Security 3.0, and I thought I'd just highlight some things we're excited about: 1. Revamped, Streamlined GUI ALES 3.0 introduces a brand new UI experience for policy management. This is a big deal because it is a customizable tool that really simplifies the process of managing users, attributes, roles, resources and policies. Going forward, we'll be using this framework for all new UI features in the product. 
2. Configurable Attribute Retrievers So many of our customers depend upon external data to drive their policies. For example, policies might need to look at an LDAP attribute for a user or query a database to get a particular value that affects a policy outcome. ALES has always had the ability to retrieve data during policy execution, however prior to 3.0 we required you hand-roll some code. Now in 3.0 we support several standards-based data sources Out Of The Box- you just tell us where to get the data and it's done. You can pull attributes from LDAP, RDBMS, or Service Data Objects (SDO). 
3. New Security Service Modules (SSMs) We just introduced two new SSMs that were requested directly from customers: Oracle RDBMS The Oracle SSM leverages the Virtual Private Database (or FGAC) feature of Oracle 9.x and 10.x such that the SSM intercepts SQL statements on the fly. You can then write policies that add "where" clauses dynamically to the query before it is executed. WebSphere App Server The WebSphere SSM plugs into the 6.1 App Server (just like our WebLogic SSM) and lets you do in-memory authorization decisions inside your J2EE application (EJBs, JSP, JMS). 4. Simpler Configuration ALES 3.0 provides a new ConfigTool utility that completely automates the task of creating an SSM configuration. This is especially welcome for customers who need to enable a WebLogic domain. If you ever hand-configured a WebLogic Server domain to use the ALES providers, you'll appreciate using this tool. Basically you just provide the parameters you want (domain name, ssm configuration id, authentication directory, etc.) and ConfigTool does the rest. 5. More Programmatic Support We now ship with a Beehive Control which allows you to make ALES call-outs from inside any Apache Beehive or WebLogic Workshop enabled application (e.g. WLI or a PageFlow). This is very useful if you want to do fine grained entitlements inside, say, a PageFlow portlet in WebLogic Portal. We're also shipping an ALBPM 6.0 Component for doing the same thing inside a BPM process. In other words, you can now use ALES to make security/routing decisions on behalf of an executing business process. 6. Expanded platform support ALES 3.0 covers the widest set of runtimes now for administration and enforcement. We now run ALES Admin Server on WebSphere, and secure WebLogic Integration 9.2. We have even expanded our supported databases for Admin. ALES 3.0 is a big release- and I'll be looking at more of these features in detail over the upcoming posts.
 |
