To describe security as an important part of SOA Governance is bit like describing water as an important part of the lives of fish, which is to say, it's an obvious point. Like everything else in SOA governance, security is a multifaceted issue. But SOA security boils down to knowing the answer to one simple question: Who is using your stuff?
Each service deployed within your SOA represents a significant investment, and significant potential ROI. One of the fundamental goals of SOA governance, of course, is to insure that the use of each service generates the expected return. Key to realizing that return is controlling who has access to those services, and controlling how those who have access actually use those services. In order to do that you want security measures that are more effective than the guy in the photo.
The control of access to services relates directly to the issue of the balance between governance and agility, an issue discussed in this blog and elsewhere. Agility, of course, is one of the primary objectives of SOA. The ability to mix and match services in response to business requirements is one of SOA's defining characteristics. But that ability, the freedom to access services and combine them in innovative ways, doesn't require throwing open the doors to the enterprise service portfolio.
In SOA -- as in anything else -- trust is a two-way street. While those who might use a particular service in a development project need assurance that the service will perform as expected, those responsible for creating and maintaining that service in the first place need assurance that the service will be used as intended. Overarching those concerns is the fundamental issue of architectural integrity. The appropriate security measures will insure that who does what with what within the SOA is in direct alignment with architectural guidelines and standards.
By assigning the appropriate privileges to the appropriate users, teams, or roles, administrators can restrict access to services to the right people, providing the assurance that those services will be used in the intended manner, and in line with business objectives.
Access, however, isn't necessarily a binary yes/no issue. Since visibility is such a key issue in maintaining a healthy SOA, security measures must take into account the value of allowing restricted access to certain assets by certain users.
For instance, inadvertent redundant development can be eliminated by restricting a development team to access to a limited spectrum of metadata about a particular service, as opposed to the service itself. Access to that information tells the team that the functionality provided by the service in question is already available, so there's no need to reinvent the wheel. That kind of security can go a long way toward preventing service sprawl and keeping your SOA as limber and agile as a yoga instructor.
For SOA security, the better analogy, perhaps, is the big, intimidating security guy who controls the velvet rope outside a really hip, popular nightclub. His job is to let only the right people into the club. Your SOA security measures must be capable of sorting out who gets to dance with the valuable stuff in your service portfolio.
For a deeper dive into security and SOA, check out the blogs by security experts Dave Garrison and Bill Dettelback.
Also see: BEA AquaLogic Enterprise Security
Previous posts in the SOA Governance@Work series:
For information on BEA's SOA Governance solution, visit the SOA Governance Resource Center.
]]>