There is a common topic that many of you ask me about and it’s about how to implement security with the TIBCO BW processes. I explained in different post how to implement a basic security policy using the capabilities that the TIBCO BW tool gives us to do that kind of task. You can rembember these posts: Applying Security in Web Service with TIBCO BW and Invoking a Secured Web Service from TIBCO BW
But, that’s a not good practice to an overall architecture and that’s because if you are doing this kind of task you are linking the “life” of the security policy with the “life” of your developments, and that’s not correct. But, let to dig a little more about that philosophical debate.
Supose that you are in charge of the integration layer in your company, in charge of every TIBCO BW development your company has to do. Will you be in charge to define the security policy of your company as well? Probably not, it is not possible that you could have these two areas at once because the security policies has a more scope than the integration or EAI layer, and if is this is true, Why are linking these two concepts?
If you link these two artifacts when you change your security policy you have to develop and deploy a new version of your TIBCO BW processes? How much is it all that effort? How many risk you are affording for a new deployment that has no business value?
With that idea on mind, start one kind of products known as Security Gateways or Security Proxies you could call it whatever you want, but the idea is the same:
- These tools follows a declarative approach: You define the policy, the kind of checks what you want to perform for any request.
- These tools deploy an agent that act before the request comes to the real engine and perform the checks defined before and if the checks are passed, the request comes “as normal” to the BW engine. The agent act as an interceptor.
Well, TIBCO AMX Policy Director is one of these tools and to say all the truth it is not the only TIBCO product related to that capability. We also have the new product TIBCO API Exchange Gateway to enable this behavior, but today there is no room for TIBCO API Exchange.
TIBCO AMX Policy Director is a tool that have been across a long path in its very short existence as a TIBCO product. It was born as an evolution of the deprecated product TIBCO Policy Manager to be compatible with the new TIBCO AMX platform and more specifically with the TIBCO AMX Service Bus / Service Grid product. That was the 1.0 and 1.1 version and we wait so long for another release that had been go out last year 2.0 version to implement compatiblity with the new TIBCO BW 6.X series.
To define a policy using the TIBCO AMX Policy Director you will have to complete the following tasks:
- Define the Governance Control: The governance control is where you define the kind of check you want to do. In other words it the definition of your policy. (If you want perform authentication using Basic Auth or WSS:Username Token, if you want check for integrity or encryption.. these kind of things)
- Define the Object Group: The object group is the set of endpoing where you are going to apply a Governance Control. Is the set of services which are going to be enabled using that policy.
- Define the dependant resources: If you governance control needs any resource like LDAP Connection or X509 Certificate you need to create this kind of resources.
And that’s all,after that you can deploy your policy and enable and disable it at run-time without any need to modify or touch anything of your processes and unlinking these two different concepts.