Service orientation is about agility. Without a resulting agility, there is no point of doing SOA. Unfortunately, enterprise SOA infrastructure initiatives sometimes fail in part because its security mechanisms and processes demolish any agility that was built into the SOA itself. This happens when security is an afterthought. Simple barriers are good for security but they can easily become preventers of agility.

When security fails to maintain agility, one of following two possible consequences seems to emerge. The first is a failure of the corporate SOA initiative – without agility, the SOA fails to provide value. The second is when users of the SOA infrastructure work around the security mechanisms and processes to restore the needed agility. Holes are poked in the barriers themselves to accomplish what is needed – this is obviously dangerous and non productive.

To avoid such problems, one must implement a security that enables agility. One of the key ingredients of such an application of security is the decoupling of security from the services themselves. Consider the figure below where agility is represented on the Y axis and decoupling on the X axis. Note that I consider decoupling not as a binary ‘on-or-off’ state but rather along a scale with varying degrees.

On the left extreme, security is embedded as part of the application logic itself. There is no decoupling and therefore no agility with applying security at this level. This type of approach cannot accommodate important SOA patterns such as service compositions and global policies. Any change at this level requires potential interruptions of service and costly development phases. Moving along to the right, we come to container level security. This is a first step towards decoupling but the security is still running in process of the service implementation, very close to it and with very little added agility. Agent based solutions can offer additional decoupling in the sense that they can receive instructions from a centralized authority. However, agent based solutions are still running in process of the services themselves and have a native dependency to the container of the service implementations. There is still limited agility and a potential lock-in problem.

On the top right, you find security as a service, a security implementation that runs out of process, in a transparent way to the services themselves. Security as a service is a pattern typically implemented by gateway-based solutions – centralized policy enforcement points (PEP) and policy decision points (PDP). Security as a service requires a neutrality towards the services that they act on behalf of. This neutrality is achieved through the use of standards based mechanisms.