Bill Dettelback's Blog

Technology: Security Archives

Entitlement Policy and The Real World

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?

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.

Securing POJOs with Spring AOP and ALES

I was pulled into a customer discussion a few weeks ago by our sales team, specifically to talk about how ALES could be used with frameworks like Spring.  We haven't done any formal engineering on a Spring integration, but I felt that in the spirit of the Spring Framework, it couldn't be that hard to find some synergies between it and the security framework in ALES.

Not being a Spring guru, I took a look at the latest version (2.0) and realized that a lot had changed since I'd last looked at it over a year ago.  One thing that caught my eye was the new AOP framework.  Clearly, when it comes to doing authorizations in your code, AOP seems like a nice apporoach, and the Spring folks seem to have made it about as simple as possible to get started with it.

Spring AOP supports aspect join points at the method level.  In plain English, this means you can dynamically inject some code either before, after, or "around" a method invocation.  This is very much the use case for authorization decisions in an application- before you execute the transferFunds() method, better make sure the user is authorized.

AOP helps to solve the problem of performing authorizations in an application without having to manually track down and intercept each method call you wish to protect.  Using AOP, you can simply have Spring do the work for you.  On the flight back from BEAWorld last week, I found myself with a full laptop battery and a desire to try this out, so...

The first thing to do is identify a Java method you want to protect.  Let's take a simple example- the buying and selling of securities:

public interface TradeService
{
   public long buy(String cusip, int amount, int price);
   public long sell(String cusip, int amount, int price);
   public int getTotalSold();
   public int getTotalBought();
}

Our primary concern is with the buy() and sell() methods.  There may be complex policies that dictate when and how a user can perform these transactions- we don't want to code these in our app- let's let ALES handle them.

Naturally, we don't want our methods to have any awareness that they are under protection by ALES.  This is a central design pattern in Spring- separation of concerns.  We should be able to test our TradeService implementation without having ALES running.  This keeps our test client fairly clean:

TradeService ts = (TradeService)context.getBean("TradeService");
System.out.println("Start buying.");
for ( int k=1; k <= 10; k++ )
   try {
      ts.buy("037833100", 900*k, 150);
   } catch (Exception e)
   { System.out.println("Purchase DENIED"); }
System.out.println("Done buying.");

System.out.println("Now selling " + ts.getTotalBought() + " shares.");
   try {
      ts.sell("037833100", ts.getTotalBought(), 160);
   } catch (Exception e)
   { System.out.println("Sale DENIED"); }
System.out.println("Done selling.");

Just a quick note on our TradeService object- with Spring you don't use the new operator, but rather let Spring get you an object reference via a label - hence the context.getBean("TradeService") call.

Now here's the magic of AOP- we can tell Spring to automagically surround our calls to buy() and sell() with calls to ALES.  If ALES says go, then we continue along as if nothing happened.  If ALES says no, then we can throw an exception.  Here is the complete Spring configuration file:

<!-- ALES Specific Beans -->
<bean id="ALES" class="com.bea.ales.examples.springaop.ALES">
   <constructor-arg value="jssm"/>
   <property name="atnHandler" ref="ATNHandler"/>
</bean>
<bean id="ATNHandler" class="com.bea.ales.examples.springaop.AuthenticationHandler">
   <constructor-arg value="system"/>
   <constructor-arg value="weblogic"/>
</bean>

<bean id="BuyAuthorizationAspect" class="com.bea.ales.examples.springaop.AuthorizationAspect">
   <property name="ales" ref="ALES"/>
   <property name="action" value="execute"/>
   <property name="clippingNode" value="pojo"/>
   <property name="context">
      <props>
         <prop key="totalBought">$1I</prop>
      </props>
   </property>
</bean>

<bean id="SellAuthorizationAspect" class="com.bea.ales.examples.springaop.AuthorizationAspect">
   <property name="ales" ref="ALES"/>
   <property name="action" value="execute"/>
   <property name="clippingNode" value="pojo"/>
   <property name="context">
   <props>
      <prop key="cusip">$0</prop>
      <prop key="price">$2I</prop>
   </props>
   </property>
</bean>

<!-- Our Application Bean -->
<bean id="TradeService" class="com.bea.ales.examples.springaop.TradeServiceImpl"/>

<!-- Wire up authorization aspects -->
<aop:config>
   <aop:aspect ref="BuyAuthorizationAspect">
      <aop:pointcut id="BuyCutATZ"
         expression="execution(* com.bea.ales.examples.springaop.TradeService.buy(..))"/>
      <aop:around pointcut-ref="BuyCutATZ" method="authorize"/>
   </aop:aspect>
   <aop:aspect ref="SellAuthorizationAspect">
      <aop:pointcut id="SellCutATZ"
         expression="execution(* com.bea.ales.examples.springaop.TradeService.sell(..))"/>
      <aop:around pointcut-ref="SellCutATZ" method="authorize"/>
   </aop:aspect>
</aop:config>

Top to bottom, we define a series of beans (just POJOs) to encapsulate the ALES Java API and handle authentication (I ran this example from Eclipse and not in an app server).  Then we define two beans that are the actual Aspects themselves (these are just a POJO) with some properties set according to the access calls we expect them to make.

The key section is the <aop:config> bit- here we "wire up" our aspect POJO with our specific methods in our application POJO.  You can see that we've chosen the <aop:around> advice which means our aspect can inject code "around" the method call.  This is important, because it may happen that ALES says we cannot actually call the requested method and we need to be able to take alternative action.

If you think about what this is doing, we're actually setting up our Policy Enforcement Point thru configuration instead of Java code.  This is crucial- ALES acts as the Policy Decision Point (PDP) and Spring AOP acts as the Policy Enforcement Point (PEP).  Since Spring is actually calling ALES on your behalf, it's impossible for a developer to accidentally forget to make the call to the PDP.  Even more important (perhaps) is that you can take off the authorization calls with a single change to the <aop:config> section of this file and none of your code is touched.

Now the aspect code itself.  Surprisingly this is a small amount of code- basically all we need to do is call out to ALES and get back a decision.  Based upon that decision, we can proceed with the intended method call or throw an exception:

public class AuthorizationAspect
{
   private ALES ales;
   private String action;
   private String clippingNode;
   private AccessResult accessResult;
   private Properties context;
   public void setAles( ALES a ) { ales = a; }
   public void setAction( String a ) { action = a; }
   public void setClippingNode( String a ) { clippingNode = a; }
   public void setContext(Properties p) { context = p; }
   public AuthorizationAspect()
   {
      action = "execute"
      clippingNode = "pojo"
   }
   public Object authorize(ProceedingJoinPoint call) throws Throwable
   {
      try {
         String resourceName = clippingNode + "/"
                + call.getSignature().getDeclaringTypeName()
                + "." + call.getSignature().getName();
         accessResult = ales.getAtzSvc().isAccessAllowed(
                ales.getIdentity(),
                new RuntimeResource( resourceName, "exampleResource" ),
                new RuntimeAction( action, "exampleAction" ),
                createContext(call) );
      } catch (Exception e ) {
         e.printStackTrace();
         return null;
      }
      if ( accessResult.isAllowed() )
      {
         Object point = null;
         point = call.proceed();
         return point;
      }
      else {
         throw new Exception( "ATZ Denied by ALES!");
      }
   }

}

The aspect itself tries to be as generic as possible- most authorization decisions are exactly the same and all that changes are the resource name, the user identity and some context.  As you can see, I've made the resource clipping node and application context a property that can be changed in the Spring configuration itself.  This is a debatable decision because one might argue that this opens a security vulnerability.  On the other hand, hard coding it in the source makes it harder to change- so there is a trade off.

The resource name itself took some thinking- at first I was going to manually enter some logical names (e.g. /app/buy or /app/sell) and map them in as properties to my aspect.  But after thinking about it, I realized that Java already gives us a unique resource label- the fully qualified class name and method name!  To boot, Spring AOP will tell us what this is inside the aspect code itself.  This gives us the following resources (under the pojo node):

I decided to hardcode the action to be "execute".  Clearly any action will do, but it just felt right that policies enforcing method execution should use the "execute" action.

The key line in the aspect is where we conditionally do point = call.proceed().  This is the heart of the aspect- we are either moving forward with the intended call or rejecting it based upon what ALES comes back with.

Finally, let's look at the policies:

As you can see, we are only allowed to buy if the total amount bought is less than 5000 shares, and we can only sell for a particular cusip when the price is under $170.

Overall, I'm pretty satisfied with the ability to use ALES and Spring AOP together.  I think that with some elbow grease we could create a fully generic aspect class that handles not only dynamic context setting but also dynamic handling of the response context from ALES (using policy responses to filter SQL queries anyone?).

If only the flight home from BEAWorld had been just a bit longer...

Flattening the Treacherous Journey

Andy Dornan has a good bird's-eye look at the SOA Security landscape in his recent article, "SOA Security: One Treacherous Journey".  I like how his argument is laid out that these are (at best) confusing times for enterprises who want to open up their services to partners outside of their existing trust domains.

After I read the article, I was of mixed feelings.  Is it really that hard?  Have we software vendors really let down our customers with standards implementations that are incomplete, incompatible and downright hard to use?  Working for a software company, it's easy to get into a mindset that your hammer is the solution to everyone's problem.  I talk to a lot of customers and I'll freely admit there have been times when I had to bite my tongue rather than blurt out a hasty answer before they got done telling me their problem.

So after I thought about it, I had to agree with Mr. Dornan- it is hard right now for our customers.  The SOA Security landscape is incredibly fragmented, inconsistent and hard to understand.  Sure, it will get better over time, as standards evolve, implementations harden and adoption grows.  So what can we do to shorten the treacherous journey that Mr. Dornan has outlined?

Something wasn't sitting right with me when I considered his arguments.  He has identified message level security and federated identity as two of the harder SOA Security problems to grapple with.  But I think he's missed another one- access control.  To Mr. Dornan's credit, he does mention authorization in passing, as part of a WS-Security discussion.  But the problems he's talking about are all plumbing issues, e.g. how do we make sure your partner's connector fits into your receptacle correctly and securely?

There is another leg to the treacherous journey just around the corner- entitlement policies.  After all, once you've verified identity, and correctly decoded the message, who's to say this person has any business at all using this service in the first place (WS-Policy notwithstanding)?  Even worse, how can the service know how to make finer grained decisions based upon identity and message payload once it's started executing?

I believe that once we get the SOA Security plumbing issues all ironed out (someday), we're in for another crop of issues around federated entitlements policy.  Standards like XACML are helping to establish the format for how we can share an entitlement rule.  But I wonder how we're going to make it easy to share policy semantics between organizations.  When you mention an invoice in your policy, do you mean exactly the same thing that I do?  I can foresee a time when a company might not just need to securely share their services, but also share their access control policies.  Share my sensitive security policies with strangers?  Why in the world would I do that?

Currently, I'm reading Thomas Friedman's book, The World Is Flat.  His premise is that the global playing field has been leveled by multiple recent forces (I'll let you read the book to find out what they are). He says we must recognize that countries like India and China are now providing so many services for US companies that we all exist in a much flatter global structure.  But it's not just leveraging low-cost labor.  One of his most striking examples is how so many companies today are actually running their business via strategic partnerships with other firms- he cites United Parcel Service performing laptop repair for Toshiba (in addition to picking up and delivering your fixed machine) as an example.  Think about that- a major electronics manufacturer outsourcing logistics and technical repair services to a company we typically think of as an alternative to the post office.  Imagine the trust relationship you need in that sort of arrangement!  Now giving your repair work to a partner is one thing, what about outsourcing your billing, or inventory management?

In the truly flat world, there is literally nothing you can't outsource to a strategic partner.  What sort of security policy collaboration and exchange needs to take place when that happens?  If we think the federated identity challenges are big now, just wait.

I advise everyone to take a look at Friedman's book (it's readily available in paperback- I picked mine up at Costco for $9).  I even want to start reading it to my 10 year old son at night to prepare him for the world in which he's going to be employed.  But that's another story...

How To Become The Big Cheese

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.

Why can't we all just get along? We can- with XACML!

A few weeks ago, at the Burton Catalyst Conference, we participated in the first XACML Interop event, sponsored by OASIS.  It was an interesting experience attempting to prove that independently created vendor products could actually deliver what the standard promises.  BEA was in attendance, as were our friends at Securent, IBM, CA, Oracle, RedHat, Jericho and Symlabs.  The idea of the demo was to show that one vendor's Policy Enforcement Point (PEP) could work with another vendor's Policy Decision Point (PDP) using XACML.   The use cases were based upon a fictitious stock trading application:

1. Authorization decisions- when the trader sends a trade, things like his trading limit and available credit are checked.  The PDP will takes these factors into account when returning the grant/deny for the trade.

2. Policy exchange- making a change to the policy inside the PDP, exporting it as a XACML file and re-importing it into another vendor's PDP.

I'm happy to report that ALES was able to show both use cases and in the process we got some valuable interoperability testing that is going to help a future version of the product.  I'll also take my hat off to our peers at the other companies- there was definitely a team spirit at work and none of the issues you might imagine when so many competitors all get into the same room.  The event was well attended (we counted almost 400 people who came thru the door!) and overall the interest level was very high in XACML and how it can solve the problem of fine grained authorization.

I was curious what was driving most folks to the interop event (besides the free food), and it seemed like most of them were just interested to learn what XACML was all about.  I was expecting to hear questions about what made our XACML implementation better than the others, but no one asked.  I was also expecting to hear folks talk about how XACML is providing a level of investment insulation for their policies- but again it didn't come up.  For the most part, it seemed like less of a statement on cross-vendor interoperability and more of a statement that XACML is real and ready today to be used.  While it's sometimes hard to get into a deep discussion during these sorts of venues, there was a common lack of surprise in the interoperability itself.  I find that interesting- it doesn't seem all that long ago that a J2EE web service being used by a .Net client was a rare sight.  What does that say about the maturity of not only XML standards but also the software infrastructures behind them?

So- is XACML figuring into your Entitlements Management solution?  Do you see XACML providing investment protection, interoperability, or just another standard to track?  Let me know!

Desperately Seeking Identity Services

I've been out in San Francisco this week at the Burton Catalyst Conference, listening to the sessions, meeting interesting people and participating in the OASIS XACML Interop demo event (more on that in a future blog).

Yesterday I was given the opportunity to be part of a panel discussion on Identity Services.  Mark Diodati from the Burton Group spent some time prior to moderating our panel talking about Identity Services and why they are needed by the enterprise.   His thesis is that identity standards such as SAML, SPML and XACML don't go far enough towards making identity-focused services accessible to developers and end-users.  He drew parallels between the "good old days" of Web Access Management that began with custom ISAPI filters and evolved into a mature SSO market compared to the custom authorization solutions of today and the emerging market for Entitlement Management solutions.

He outlined the types of Identity Services that he's thinking of:

• Authorization (the primary identity service being built today)
• Authentication/Credentialing (mostly credential transformation)
• Provisioning (classic identity provisioning)
• Attribute/Profile (which may be tied to or part of the Auth service)

When I looked at his list I had to smile- it is almost exactly how we've laid out the security framework inside many BEA products (including ALES).  Way back in WebLogic Server 7.0 we (quietly) introduced this pluggable infrastructure for Authentication, Authorization, Role Mapping, Credential Mapping, and Auditing that let WLS interoperate with third party or custom providers of these capabilities.  Today, this framework is utilized by many BEA products and this lets us plug in ALES as the Authorization and Role Mapping provider for WebLogic Portal, Integration, AquaLogic Service Bus and AquaLogic Data Service Platform.  During the panel discussion, it occurred to me that in a small sense, BEA has been leveraging the idea of Identity Services within our own products for years.

But Mark wanted to go deeper on this idea- what exactly makes an Identity Service different from other types of services?  Well, certainly there are specific schemas and protocols we can rely upon (at a very basic level you have things like LDAP and SAML).  But how are organizations going to use an Identity Service?  Should we have a single Identity Service that performs the full gamut of Authentication, Authorization, Attribute retrieval and so forth, or should we have discreet services for each concern?  What sort of service binding is most appropriate- SOAP, REST, XML/HTTP, RMI?  How about performance- can we expect Identity Services to scale to the thousands or hundreds of thousands of users?

I think this is an interesting set of questions- and I certainly don't claim to have the answers.  But what I find most interesting is that the "Identity" folks are now asking the same sorts of questions that the "Application" folks were asking about services in general few years ago.  I'd argue that while Identity Services provide a very specific set of capabilities in your SOA they don't necessarily have to be architected or thought of any differently than your business or data services.   If your SOA needs a single, coarse grained Identity Service, then you can certainly compose it from finer grained services via a service bus proxy model.  If you need greater scalability then it's possible to load balance and distribute Identity Service implementations across multiple physical domains.  In other words, the software side of Identity Services is pretty straightforward to solve.

What really makes Identity Services an interesting challenge is how we can make them standard and dynamically understandable no matter who is using or creating them.  Because Identity Services are so focused on a few narrow concerns it should be possible to come to an agreement on how they "should" be structured.  This will open up a lot of opportunity for users of Identity Services to reduce costs when they need to interoperate with other user's services.  Think of financial institutions that are constantly merging and acquiring smaller banks- if they could simply re-direct the acquired applications to their own Identity Services this would cut out a huge amount of work integrating systems.  We can even toss around the idea of dynamically discoverable and understandable Identity Services where you don't need an architect to explain the subtle semantics of how his Auth service works.

All good stuff for a panel discussion- and by no means are we there yet.  What do you think- are you building Identity Services today?  What do they look like?  Do you think that in 5 years you'll be ripping them out for a COTS solution?  I'm interested in what you think.

SOA and Data Security

One topic that keeps on coming up over and over as I talk with customers implementing SOA is the concern over data privacy.  The typically use case looks like this- multiple groups need access to the same database but for legal or organizational reasons cannot view each other's information.  For example, HR is a treasure trove of sensitive information the rest of the organization shouldn't see, as is Sales forecasts, Manufacturing quotas, and corporate growth projections.  Lots of data is sitting in databases with no more security than basic authentication and private views/tables for each application group.

The problem is exacerbated by SOA- when you start service-enabling data, how do you make sure that consumers of the data can only see exactly what they're entitled to.  A brute-force solution would simply shut off those services you're not allowed to see.  But that tends to cause service creep, since you'll have to create a new service for each new consumer.  So the problem is really how to enforce security policy against data oriented services without writing lots of custom service proxies that are secured at the endpoint level?

AquaLogic Enterprise Security provides a fine grained entitlement policy engine which can describe how to grant or deny access down to the individual value of a row of data.  We've done some interesting integrations between ALES and our AquaLogic Data Services Platform (ALDSP) in our latest release so that you can actually provide XQuery statements as part of policy definitions.  This means that you can call an ALDSP service to get some data and automatically have ALES apply an XQuery "narrowing" filter as part of the security check.

For example, say you have a data service that retrieves a list of investment funds:

If you haven't seen an ALDSP service before in Workshop- the data service method is "getFunds" (on the left) and the shape of the returned data is shown in the middle (FUND).  The data service itself is coded in XQuery- and ALDSP does the "magic" behind the scenes to translate this into the appropriate SQL.  What's important for this conversation is the shape of the result set- notice we have an element called "FUND_TYPE" which could be "EQTY", or "BOND", or "FX", etc.

Now say that your Fund Managers are segmented in groups according to fund type, Equity, Bond, etc...  In ALES we can express a set of policies that provide a data redaction filter in XQuery so only those funds of a certain type are returned:

We can read these policies to say, "grant access to the DataServices/Invest/FUND.ds/getFunds method for group equity_fund_manager, returning aldsp_xquery_expression "./FUND_TYPE = 'EQTY'".  There is a different policy for each fund type, and the policies will be enforced depending upon what group the user is part of.

There are a few benefits to this approach:

1. The data redaction policy is completely independent from the data service definition.  All users call the same getFunds method and behind the scenes ALES removes those rows they can't see.  The security policy can evolve independent of the service definition itself.

2. Only one data service is needed for all users- there is no need to build a separate getEquityFunds, getBondFunds, getFXFunds... service for each user type.

3. The redaction happens before ALDSP returns the results to the caller- so there is no performance penalty if we have a million fund records but only care about three Bond records.

4. The redaction is fully audited by ALES, so we can keep track of how many times the service was invoked and if an unauthorized user attempted to see rows he shouldn't.

5. Absolutely no code is written to get this behavior- the data service is created visually in Workshop, and the ALES policy is constructed visually thru the Administration Console.  The only code required is the service consumer (which we can even streamline considerably using the ALDSP Service Control).

Moving Beyond WS-*

A big part of my role here at BEA is to work with customers implementing solutions with AquaLogic Enterprise Security (ALES).  ALES is BEA’s product for Fine Grained Entitlements and is starting to gain traction with organizations seeking to secure their Service Oriented Architecture.  This blog will be a place to discuss the topic of entitlements and SOA Security, particularly in regards to ALES.

One topic that comes up again and again with customers embarking on an SOA journey is, of course, security.  Most of the conventional wisdom around security in an SOA involves how to secure the messages and endpoints themselves.  This makes sense at some level, since traditional web services are the technological entry ramp onto SOA.  And while I won’t attempt to debate how relevant or adoptable the WS-* standards are for the real world, I think it’s safe to say that aside from WS-Security they haven’t seen a massive uptake in adoption.  Which leads me to start thinking that there are a few possible reasons for this: 1) web services aren’t being widely implemented, 2) web services aren’t being used in situations where security is really necessary, or 3) WS-* doesn’t really solve the security problem with SOA.  Obviously #1 is a false assumption, and I believe #2 has a fair amount of reality associated with it.  #3, of course, takes us to a topic I want to really focus on.

About a year ago, I was working with a large financial institution that had a huge initiative underway to increase revenues through more efficient IT operations.  This company is in what is typically considered a fairly slow-moving industry, and was seeing incredible competitive pressure from another company.  This competitor was taking the industry by storm in large part because they were just plain easier to work with over the web and phone channels.  SOA was seen as a way by my customer to gain back some competitive edge by removing complexity and human error from their processes.  They were kind enough to spend some time reviewing their SOA reference architecture that had already been paying for itself in reduced IT costs.  As we looked at the model together, it was clear they had spent considerable time thinking about how their systems worked and what types of services made sense for their many organizations.  But there was one glaring omission as far as we could see: security.  Yes, they had the right boxes on the model to denote transport and message encryption, and there were ample authentication mechanisms in place.  What was missing was a way to express security policy for common roles across disparate service implementations.  For example, it was not possible to define that a user with role “A” could use two operations from one set of services and three operations from another set of services, but none of the operations from another set of services.  Each individual service provider was responsible for denoting access control.  For certain siloed areas of service (e.g. general ledger in the Finance department) this makes sense, but there was a lost opportunity for sharing access control policies across functionally similar organizations.  Adding insult to injury, the same policies were needed across different organizational boundaries.

Now to be fair, I think this company was way ahead of most large financial institutions when it came to SOA vision and ability to execute.  But I think that this does point to a trend in SOA: distributed security (particularly policy management) shouldn’t be an afterthought.  SOA is a tough thing to get right- there simply aren’t enough large scale successes to look at yet.   While the message and transport level security is a pretty established part of the technical solution, there still exists a big set of questions about how security policy should be managed and enforced in SOA.

This is a big reason why BEA has brought ALES to the market- there are a lot of our customers who have dipped their toes into the SOA pool and are starting to seriously leverage SOA concepts in developing applications.  Just as they no longer are creating monolithic applications in isolation of each other, they are no longer enforcing security policies in isolation of “the big picture”.   There is an emerging need for these customers to be able to enforce security policy at and inside their service endpoints while still managing those policies in a central place.

A useful blog is one where a dialogue (not a soapbox) can be found.  I’d be very interested in comments on this- does this ring true with your experiences?  Are you wrestling with distributed security policies in SOA?  Let me know!