Agile, Decoupled Security for Better Service Orientation
Agile, Decoupled Security for Better Service Orientation
Join the DZone community and get the full member experience.
Join For FreeHow to Transform Your Business in the Digital Age: Learn how organizations are re-architecting their integration strategy with data-driven app integration for true digital transformation.
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.
Build and deploy API integrations 7x faster. Try the Cloud Elements 100% RESTful platform for 30 days free. Access your trial here.
Published at DZone with permission of Francois Lascelles , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
{{ parent.title || parent.header.title}}
{{ parent.tldr }}
{{ parent.linkDescription }}
{{ parent.urlSource.name }}