IT Security and SOA

Service Oriented Architecture (SOA) has begun to capture the imagination of both businessmen and IT Departments. A combination of advances in software technology and standardization, that goes by the name of SOA, is making it possible to build business applications by assembling parts of other applications. The development process is fast and thus if an organization chooses to build the right business applications, the benefits come quickly.

As its name suggests, this approach to software building is indeed an architecture and implementing SOA foundations is neither a trivial nor simple matter. Nevertheless the IT industry is now thoroughly committed to this approach and we can expect most organizations to adopt it in time. It is important, therefore, to have an understanding of what it will mean.

This is particularly the case as regards IT security. SOA presents a more complex scenario than what went before. Previously, companies built or bought applications and secure access to applications was simply a matter of linking valid users to the applications; providing local access rights, authentication and authorization. SOA is about threading multiple applications together, but only using the functionality you need. To achieve this, SOA abstracts the business functionality of specific applications allowing them to be discovered and used by other applications.

Unfortunately, this presents an IT security problem. In most organizations some of the business applications involved in any SOA-based application will have different identity mechanisms and security policies. Users will most likley have different privileges for different applications, and thus they will need to be authenticated for each of the applications that are used by the SOA application.

The problem is exacerbated by the way that SOA works. Linking between applications occurs through an abstraction layer that does not provide access to local user identity validation in the applications that are accessed – unless the application itself provides such access, which is unlikely to be the case.

To consider a simple example, a SOA application might access an order entry capability within the order entry system, but the order entry system is unlikely to know whether the connecting application is authorized and has no means of directly checking it.

The underlying problem is that even when organizations have implemented fairly comprehensive access security, it is fragmented. To provide IT security for SOA requires an end-to-end Identity Management capability one that is able to determine access rights for every application involved. Ultimately this means every application that the business runs. Even organizations that have invested heavily in Identity Management will still be some way from achieving that.

It follows that IT Security will probably act as a brake on SOA implementations. IT security has often been an afterthought in the implementation of new technology. In recent years, for example, we have witnessed Internet capabilities and wireless capabilities being delivered with inadequate security, often with woeful consequences. Businesses are less likely to be so carefree with SOA, not just because IT security issues are better appreciated, but because SOA will link together the most important systems that organizations run.

In the long term, SOA will connect systems between multiple organizations up and down supply chains. When that happens, the IT security situation becomes even more complex and more problematic. Businesses will not only need to have their own IT Security act in order. They will also need to have confidence in the Identity Management infrastucture of suppliers and customers. The commercial motivation to build such SOA capabilities to streamline the supply chain is there. But the Identity Management services that could make such systems secure are yet to be built.