In a recent post, enterprise architect James McGovern wondered whether BPM products, like Lombardi's, support XACML.

So I replied with a comment discussing BPM and security mechanisms:

With respect to security 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.

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.

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.

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.

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]. 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.

James reflected on this in a subsequent post, and in that post he raised a few more questions... so let's continue the conversation...

1) When the BPMS is the service provider (not the consumer)

James says "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."

Yep, I agree. I didn't make reference to it in my post, but of course for any services you expose from a BPMS (or ECM, or ERP or other platform) you should be able to author them so that the centrally defined policies govern who has access to that service. I suspect that all BPMS allow for this.

2) User interfaces, security policies and the BPMS

James says "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."

Having UI's call the central policy server for presentation-layer rules on what aspects of a UI to show would be an interesting thing to debate. I'm not sure I'd agree with that as a good mechanism. It would be better for the presentation to drive itself based on the types of data that were presented to it (in the same way that device-dependent presentations are derived). That is, you don't want the presentation layer figuring out the security because that assumes the presentation layer has access to everything to begin with. So I guess I would take issue with the premise.

If, however, you want to drive your presentation-layer in this manner, you probably also want the presentation layer up and outside the BPMS. So while in Lombardi's BPMS (Teamworks) you can author UIs, we also give you the ability to easily plug in your own UIs for particular steps in the process. This would be the mechanism to separate the UI from the process definition, and also allow you to drive the particular UI from centrally-defined policies.

3) On BPMSs storing their own users

James says "I think many would agree that a BPM engine should store processes not users."

Yes, I agree. At Lombardi, you don't have to manage users in our store, if you manage them elsewhere (like LDAP or AD). I would say, though, that in the real world we've found that there are attributes you want to use in a process-context that aren't present in your corporate systems. These may be user attributes (like skill level for a particular job) or they may be role-related (a person's relationships to others change depending on the process context).

So in Teamworks, you have the ability to not only use the central user store, but, if you desire, you can also extend the attributes for a user (or role) without mastering that user... sort of a hybrid system. Again, if you manage the attributes centrally then the BPMS will pick them up. It's a matter of choice, and, to some degree, practicality.

We also think this "relationship" issue is bigger than LDAP and AD. Of course, matrix'd organizations have existed for a long time, and these basically reflect that my relationship to people around me change depending on context. For example, the CIO of Company X reports to the CEO of Company X for operational issues, but may also report to the CIO of ParentCompany Y for other things (like use of standard technologies).

As companies begin to measure more of themselves using process as the normalization, then these numbers of "matrix organizations" expands. So we think that organization modeling is part and parcel of the larger BPM discussion... and that these models will integrate with [LDAP or AD], but provide more extensive information. This is an area that I think will really change and expand in the coming decade, as the convergence of increasing security along with increased decentralization of computing resources gets mainstream emphasis.

Conclusion

Securing distributed systems has been long overlooked due to real-world needs to get technology out the door. But this aspect of enterprise architecture is critical to successfully embracing not just distributed technologies like BPMSs, but also important so-called social computing platforms like wiki's. Without good guidelines and well thought out policies, companies just won't embrace these critical technologies. And as a big company, it is critical you be able to embrace these because your smaller competitors are, and they are stealing your most profitable customer and product segments.

Thanks, James, for a good forum to have this conversation.

Technorati Tags: James McGovern, Security, SOA