What makes enterprise architecture both difficult and fascinating is that its all about dealing with a multi-dimensional problem. Focus on one or two dimensions, and the others quickly become orthogonal considerations, usually relegated to a later time, actually never really implemented. More often than not, security is one of these dimensions that does not get the attention it deserves. Dealing with security is a little bit like cleaning your house: when its clean, nobody can really tell how much work had to be done for getting there, and only when things get dirty do people start noticing. This post from security architect James McGovern is a good summary of the problem at hand, and gives me an opportunity to answer a question that was asked following the publishing of this post on the intersection of BPM and ECM: what about security?
Among other things, a security architect is usually interested by authentication and entitlement. The first is there to ensure that you really are who you say you are, while the second gives you permission to conduct some actions upon specific resources once you have been identified and your credentials have been defined. From an architecture standpoint, authentication has been largely solved with Single Sign-On architectures. It does not mean that companies have deployed it yet, nor that Web resources are supporting it—I wish they were—it just means that the standards have been set, implementations have been developed, and best practices have been defined. Entitlement is another story altogether.
Entitlement, which is also known as authorization, is a complex problem to solve, because it covers a broad range of actions that can be conducted upon a broad range of resources. While the scale and complexity of a Single Sign-On infrastructure typically grows linearily with the number of systems and users having access to them, the scale and complexity of an entitlement infrastructure grows exponentially with the number of resources and services it is controlling access to. Because of such inherent complexity, standards for entitlement or authorization are fairly complex too. For some time, one of the references in the space was the Role Based Access Control model developed by the National Institute of Standards and Technology (NIST). Eventually, it got superseded by the eXtensible Access Control Markup Language (XACML) developed by OASIS, which is one of the most complex specifications I ever came across.
From an architecture standpoint, I believe that XACML is using the right model to solve the problem at hand. As James explains in his post, it defines several components such as a Policy Administration Point (PAP) which allows for centralized administration, Policy Decision Point (PDP) which defines how rules/conflicts are resolved and the Policy Enforcement Point (PEP) which is responsible for the actual enforcement of all policies. The technology is good, but the challenge has been in getting multiple vendors to adopt it. If history is any indication, what happened for authentication will happen again for entitlement. Because vendors of enterprise systems and applications had different ways of authenticating users and did not agree on a common standard, other vendors had to step in and provide generic solutions that could connect to a variety of existing systems. For authentication, such solutions came from traditional security vendors such as RSA. For entitlement, I believe that solutions will come from ESB vendors, for SOA is providing a compelling event for their deployment. They might also come from BPM vendors, for business processes provide the right set of scenarios for defining meaningful entitlement policies.
This brings us back to the original question, which is to understand how the security model used by an ESB will mesh with the one adopted by a BPM system. Security, alongside discoverability and resusability, is one of the services that should be offered by a good ESB, and entitlement is one of its critical elements. XACML is quite a good fit for the ESB model, in the sense that it would allow service owners to specificy rules and policies for granting access to services managed by the ESB. Things get a little bit more complex for a BPM system, for the reason that entitlement can be implicitely defined and transparently enforced when using the right process modeling methodology and notation. In this respect, the BPMS acts as some kind of process firewall.
The idea for a process firewall is pretty simple: model your process in BPMN using multiple swimlanes—one for each participant, be it a human being, an external system, or another process. The very action of breaking your process down into participants implicitely defines who can do what, which is also called authorization, or entitlement. Essentially, entitlement definition becomes a simple by-product of process design, and it’s one that comes out for free, with the right level of granularity. If you adopt this approach and make the assumption that all your services will only be consumed by processes deployed on the BPMS, setting up your ESB for policy enforcement becomes trivial: no service can be used by any other system than the BPMS, and let the BPMS do whatever it wants. With such a model, the BPMS becomes your PAP, your PDP, and your PEP, all in one. Pretty cool, isnt it?
Of course, this model is overly simplistic, and most real-world deployments would include services that are used by many other systems than the BPMS. In this case, the ESB becomes the primary PAP, PDP, and PEP, and is extended by the BPMS, which acts as a secondary PAP, PDP, and PEP. If you adopt such a model, two options become available to you: one is to use the BPMS to circumvent the entitlement rules defined by the ESB, the other is to use the BPMS to refine them. According to the first option, a given role might not be able to perform a certain action upon a given resource based on the rules defined in the ESB, but would be allowed to perform it within the context of a specific process managed by the BPMS. According to the second option, the ESB might define broad entitlement rules for a set of resources, and let the BPMS define narrower scenarios whereby particular roles perform some actions upon a subset of these resources, again within the context of a specific process. The first could be characterized as an exception definition mechanism, while the second is a specialization technique for the definition of fine-grain entitlement rules. I believe that both could be used side by side, and that there would be significant benefits in so doing.
The way an ECM system would fit into this picture is quite interesting as well. Access control is a critical feature of any ECM to be deployed within an enterprise environment, and sharing the same entitlement architecture with the BPMS and the ESB would provide significant benefits. For documents that would be attached to process instances, the entitlement architecture would define who gets to do what with the document, at different points in the process execution, which is something that is very difficult to do with a standalone ECM that has no notion of process context. Also, using the ECMs native access control infrastructure would allow the definition of proper entitlement rules for the manipulation of process artifacts, such as process models, service definitions, or user interfaces, while coupling it to the BPMS process deployment infrastructure would allow the definition of rules that are directly related to different points in the process lifecycle, such as development, testing, deployment, or update. For more on the intersection between BPM and ECM, you can refer to this article.
As far as I know, no BPM vendor has ever adopted such a model in combination with an ECM and an ESB. Nevertheless, the technology exists today for building such a thing, and all we need is enough customer interest for getting it done. This is something that Intalio is actively pursuing today, and I would expect that we will be in a position to announce interesting developments in this area sometime this year.
In the meantime, I wish you all a very good week-end.