Enterprise Architecture: From Incite comes Insight...

Phil Gilbert, CTO of Lombardi Software left an interesting comment in my blog that I wanted to share and of course analyze...



Below are snippets from his comments:

With respect to security, as you know, there are two fundamental issues: who are you? and what do you have access to? In general, the OASIS SAML specification deals with the former, and the OASIS XACML specification deals with the latter.

So far we are in agreement.

Lombardi Teamworks explicitly supports SAML as a means of identifying who you are and passing that around. Very few, if any other, BPMS vendors support SAML and it's a non-trivial specification to implement. Lombardi Teamworks does support SAML and as a result, we have many very secure implementations and customers.

It is good news to hear that Lombardi Teamworks acknowledges the importance of supporting SAML and that you have a capability that doesn't exist in Intalio, Pega and others. Of course, one should ask the question of why others don't have and whether the issue in terms of implementing it should be that difficult. Many of the BPM engines run on top of J2EE containers such as BEA Weblogic Server which provide support for SAML as well as other methods for passing around identity. In the world of BEA, a product vendor needs to hook into the Identity Asserter mechanism and simply leverage.

Authorization is a bit different. Generally speaking, XACML defines (1) the mechanics of defining a central set of authorization policies, and (2) how a service accesses those policies. That is, and this is key, you want the service being accessed to be its own enforcer, based on policies set in the central policy repository.

The rationale for storing policies centrally is more than just one product needing to be its own enforcer. In an integrated world where a BPM engine needs to talk with an ECM engine, the need for these two to have the same access control policies is important.

You want the called service to ask the calling application for credentials, and you want the called service to be the one that _allows_ access based on the policies. So as we see, the XACML check is done under the covers of the web service that "houses" the resource being called.

It is good to see that XACML checks are done to protect web services but they may also be leveraged by UI components as well as access enforcement may require displaying or not displaying a particular feature/function.

BPMSs (not just Lombardi's, but all of them) don't actually house the interfaces to external services, but rather hold pointers to those services. These are held as metadata inside the process definition. For example, the service endpoint address URI is stored, but not the WSDL. Therefore, the [XACML-based] security implemented under the covers of the web service operates independent of the BPMS [or any other client].

While everyone stores metadata inside the process definition, there is no technical reason why it can't also store a pointer to an XACML PEP there as well. Minimally, there is a semantic issue around whether a process can be self-contained within a single engine or spans them.

However, in most advanced organizations it relies on the SAML (or other) assertion of who you are and what context (application) you are running within. This is why it's the SAML implementation that forms the basis for security in the BPMS world.

Could you in an upcoming blog entry explain in more detail not how things currently work today but what is the real constraint in terms of BPM engines leveraging XACML? Likewise, it would be equally interesting to understand other aspects of BPM engines such as their ability to support asymetric encryption, log management and the ability to leverage existing directory services. After all, I think many would agree that a BPM engine should store processes not users.

Hope this helps... Lombardi has invested significant R&D to insure that our systems are secure, scalable and reliable. We want to make sure the public discourse about them is accurate.

There are two dimensions to security with the first being security features which we have done a great job of talking about. The second dimension of security is one we haven't discussed yet as that is whether the design and coding of a given product is secure. I would be intrigued to learn what occurs within the walls of Lombardi Software when it comes to not just making sure a design meets the functional needs of customers, but also the often unstated security needs of your clients. Likewise, I would be even more interested in learning what tools Lombardi uses to ensure Secure Coding practices have been strictly adhered to. Do you leverage Ounce Labs, Fortify Software or others?

It is a good thing to see that CTOs are participating in the public discourse. In order to encourage others to participate, I ask that we trackback to each other. Likewise, it would be great to hear from Bruce Silver, Sandy Kelmsey and other industry analysts on their perspectives on BPM and Enterprise Security and how they should converge...