Enterprise Integration Zone is brought to you in partnership with:

As the Technical Director, Europe for Layer 7 Technologies, Francois Lascelles advises global corporations and governments in designing and implementing secure SOA and cloud based solutions. Francois joined Layer 7 in its first days back in 2002 and has been contributing ever since to the evolution of the SecureSpan SOA infrastructure product line. Francois is co-author of Prentice Hall’s upcoming SOA Security book. Layer 7 Technologies is an Enterprise SOA and Cloud infrastructure provider. Follow me on twitter http://twitter.com/flascelles Francois is a DZone MVB and is not an employee of DZone and has posted 28 posts at DZone. You can read more from them at their website. View Full User Profile

Agile, Decoupled Security for Better Service Orientation

01.12.2013
| 3166 views |
  • submit to reddit
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.

Published at DZone with permission of Francois Lascelles, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags: