Gaps in the IBM SOA Security Reference Architecture - Part II
|
|
Why do we need different Architectural Building Blocks to specifically address SOA Security? Should the best practice of “Independent Chain of Command” be part of SOA Reference Architecture? These are some of the questions and comments, I have been asked in response to the first part of this series. SOA Security must handle the highly composite nature of today’s and emerging SOA Applications, and this ability to handle composite, frequently changing, dynamic applications is a critical requirement for managing security in SOA environment. Maintaining Security Accountability in the context of composite applications that cut across IT business unit, Enterprise Application, databases is a key challenge for SOA Security. |
|
"Composite applications are also eroding the definition of what an application is. In a SOA world, an application’s features, composition, location, and communications are no longer predetermined or even well-known. Instead, an application becomes a changeable collection of dynamic software services, with transaction paths that are determined on the fly from business rules created by business managers." (Jasmine Noel in Software magazine) For example, a composite Customer Dispute Resolution Application may combine customer data from three CRM Systems in an enterprise, clean the data with an external WebService like Trillium , and then join the cleaned data with a legacy enterprise database. Who is responsible for SOA Security in this composite application? |
|
|
Composite SOA Applications are a key to realizing the Business Agility and IT Flexibility promised by a mature SOA Stack. The diagram above shows a Business Process Composite Application. (Source: ClearApp) |
|
|
Each of the 3 CRM systems and the legacy database have the respective administrators as security gatekeepers. But extending this paradigm to the Composite application will lead to unclear authority and diffuse accountability. This is why it is critical to have an “Independent Chain of Command” to enforce security policy. Since the “Security Policy Group” cannot administer security on a day-to-day basis, the architecture also has to provide ways by which the Security Authority can be delegated (and revoked) to the IT or Business Unit groups. |
|
|
In the next entry, I will describe the Architecture Building blocks needed to implement a centralized Security Policy Administration group. Further Architecture Building blocks, can demonstrate delegation of security authority to IT and Business groups. (Troubleshooting and administering Composite SOA applications can also be a challenge. ClearApp has an interesting solution, but that is a subject for another entry. ) |
|
