Gaps in the IBM SOA Security Reference Architecture - Part III
Is it necessary to have an advanced and mature SOA Stack in order to have centralized security policy creation and enforcement? If a SOA Stack is not at a stage where Composite Applications are proliferating, is centralized security still required?
You need centralized security policy creation and enforcementet quite early in your SOA program. The first step in your SOA initiative will be to decide what level of granularity your services should be at. It is very easy to create webservices using built-in wizards found in many IDEs as well as wizards offered in products like databases and portals.
This leads to service proliferation, leading to a “Forest of Services”. The best practice therefore is to create coarse grained services, with the service mapping to an enterprise level entity like “Customer” or “Supplier”.
This immediately creates a security issue.
If all of the customer information, including sensitive private information is in the same XML object, how can I enforce security? How can I enforce role based security? Where should role and enterprise policy based security be administered from?
For example, you may say that only people “Sales Manager” and above, are authorized to view past customer purchase information. Only “Customer Support Manager- Level III” and above, can see customer private information. Remember, this is not about encryption but “View Privelege”.
It is possible to enforce this in custom code at the service level, but that would be a maintenance nightmare. If you want to change policy and give access to Customer Private Information to all “Customer Support Manager- Level II”, it would require a code, or at least a XML configuration file change, and service redeployment, with all its problems(Finding a maintenance window everyone can agree on, Obtaining builds before the Maintenance window in order to test them)
Changing policies at the centralized level is much simpler.
Does IBM have solutions to help with this?
Yes, IBM as well as other vendors, have solutions to protect XML data at the field level. This is not about encryption of the data, but about granting the privilege of accessing the data at the field level, based on organizational role and enterprise security policy. For example: Forum Systems , IBM DataPower Layer 7 have appliances that can protect data at the field level.
XML Security can also be implemented using ESB level mediation in application servers such as Websphere.
What about Database level security that is role or Enterprise rule based?
Oracle has a product called “Oracle Virtual Private Database” that can enforce database security at the Enterprise level. DB2 has “Label based Access Control” which does not appear to be as flexible as Oracle VPD. These products need to be integrated into the SOA Security Reference Architecture.
So where is the gap in the IBM SOA Security Reference Architecture?
The gap is that the Security Reference Architecture does not provide a way to leverage the technologies above. Additional Architecture Building Blogs are needed to create a scalable, Performant, maintainable, extensible and standards based way of administering Enterprise Security in the SOA Context. It should support central administration with security policy delegation.
Why can I not use Tivoli Federated Security?
Tivoli Federated Security allows you to do single-sign on onto multiple systems. It does not provide a way of enforcing security policies at the enterprise level, or to delegation.
In the next blog entry, I will describe the missing Architecture Building Blocks in greater detail, with a Visio based diagram.
