Bill Dettelback's Blog

Role: Architect Archives

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.

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!