Todd Biske: Outside the Box

One term that you may have run across from some of the marketing efforts of vendors touting SOA governance solutions is policy. They may even go so far to claim that governance is about policy enforcement. Technically, policing is probably more about policy enforcement is you think of governance in the municipal sense. Your local government collects taxes, makes laws (policy), and the police enforce those laws. But, that’s not the point of this entry because policy is actually a very important concept to understand.

Practitioners in the security space will frequently use the terms Policy Enforcement Point or PEP, Policy Management Point or PMP (also referred to as Policy Administration Point), Policy Information Point or PIP, and sometimes Policy Decision Point or PDP. Simply put, a policy enforcement point is the place where the determination is made that a policy needs to be enforced. A policy management point is where policies are defined or administered. A policy information point is the source of information necessary to enforce the policy, potentially including the policy itself, and a policy decision point is where the actual decision regarding the policy is made. Take your basic web access control product. A request shows up at your web server, the policy enforcement point. That request is intercepted, credentials extracted, and a call is made to the policy decision point asking, “Can the user named todd access the URL http://www.biske.com/blog?” The policy decision point accesses a policy information point (e.g. LDAP) to determine the allowed roles for that URL and the roles assigned to user todd, and returns a yes or a no. If an administrator has used the policy management point to assign allowed roles to the URL and assigned roles to user todd, everything works.

So what does this have to do with anything outside of the security domain? It comes back to policy. A policy is something that is declared. Container managed code was about externalizing concerns and declaring them in a configuration file. In other words, establishing policy. If you think about infrastructure today, all of them have a configuration file, or some management interface that allows it to be configured. Take your typical application server. It probably has some XML file that contains entries that specify what .ear or .war files will be executed. Hmm… this sounds like a policy information file. Clearly, the application server itself is an enforcement point. The policy is “load and execute this .ear file” and it does it. How do these policies get established? Well, while most enterprises probably manipulate the configuration file directly, that application server certainly has a management console (policy management point) that will manipulate the configuration file for you. Is this starting to become clear?

Now let’s look at the domain of the service intermediary, whether its an ESB, an XML appliance, a WSM gateway or agent, or anything else. What does the intermediary do? It enforces security policy. It enforces routing policy. It enforces transformation policy. It enforces logging policy. It enforces availability policy. Your intermediary of choice certainly has a management console, and it likely creates a config file somewhere where all these policies are stored. So, what’s the problem? Well, the problem is that security policy is governed by information security. Availability and routing policy by operations. Transformation policy may be the domain of the development team. Logging policy may be tied to compliance. Yet, we have one management console. To match the way policies are set, policy management must be externalized from policy enforcement. Furthermore, policies must be independent of policy enforcement points, because they may be heterogeneous. One security policy may be enforced by a Java EE server, another by an XML gateway, and a third by a .NET server. So, the most flexible scenario is one where policy management, policy enforcement, and policy information are all separated. Well, what do we have going on in the SOA space? AmberPoint recently announced agentless management, claiming that they will manage your enforcement points, whatever they may be. HP/Mercury/Systinet and webMethods/Infravio have both touted the role of the registry/repository as a policy information point. We’re getting there folks. I’m not implying that a mutli-vendor solution, is necessary, either. Certainly, SOA Software’s Closed Loop Infrastructure is showing this same separation of concerns. The world I envision has policy management points that are tailored toward the type of policy being established and the groups that do so, a distributed network of enforcement points capable of handling multiple policy domains at once (i.e. avoid having one enforcement point for security, another for routing, another for transformations, etc.), and information points capable of storing many types of policies.

My recommendation to allow of you when you’re off talking to these vendors, especially the ones offering enforcement points, is to ask them about policy. Do they even understand that they are a policy enforcement point? Can policies span multiple services? Can they be managed by an external entity? Can they be stored externally? If they don’t understand this, then be prepared for a conceptual mismatch in trying to use them.

Disclaimer: I personally have no relationship with any of the vendors listed, although I’ve certainly had conversations with them at conferences, follow their blogs, etc. I used them here only to illustrate the concepts, not as any kind of endorsement.