May 2007 Archives

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.

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!

June 2007

Search this blog:

Archives

June 2007
May 2007

Recent Entries

Moving Beyond WS-*