CA SOA Security Manager

CA SOA SM is an identity-centric Service Oriented Architecture/Web services (SOA/WS) security software product that secures access to services by inspecting the security informa - tion contained in the XML documents submitted by the service consumers. Leveraging a core set of SOA/WS standards; CA SOA SM uses centralized security policies bound to user identities to provide XML threat prevention, authentication, authorization, federation, session management and security auditing services. CA SOA SM fits into a heterogeneous SOA/WS deployment by providing both agent and proxy server-based policy enforcement points (PEPs) controlled and managed by centralized policy decision points (PDPs) known as policy servers. It is estimated that the majority of large organizations around the world have either started to use SOA/WS or are planning to do so in the near future. The attraction of SOA/WS largely rests on its ability to increase application development, deployment speed and flexibility while reducing IT costs. By leveraging traditional Web portal and Web applications, SOA/WS takes the model of cross-domain applications focused on serving human users, and generalizes this concept to computer-driven applications, that may or may not be acting under the direct control of a person. SOA/WS directly leverage the benefits of the Internet and internet technology to provide application integration flexibility no matter whether the service consumer resides inside or outside of the enterprise. As such the SOA/WS approach both eases internal application integration while leveraging standards to open up the same services to the world at large, whether they are customers, partners, or other third party organizations. However, just as with the first arrival of secured Web applications and portals in the 1990s, the arrival of SOA/WS-based applications creates a number of IT and security management challenges that must be addressed before SOA/WS can be deployed at scale. For instance, as with traditional Web applications, SOA/WS can be deployed for internal use, external use, or a mix of both. And just as “who gets access to what” matters for most enterprise Web appli - cations, the same issue must be managed and controlled for SOA/WS. In short SOA/WS need the equivalent security functionality that has become standard with web sites — namely those security services that are now commonly provided by Web access management systems (WAM). In addition, as more SOA/WS are exposed outside an organization’s boundaries, the risk of malware threats go up dramatically. Just as in the traditional Web portal and Web application world organizations need to both secure against SOA/WS threats while simultaneously uniquely controlling access for separate SOA/WS client applications and organizations. To make security matters more challenging, making access decisions based on what is coming from “inside” the organization and what is coming from the “outside” is an outdated approach that can’t be relied upon given the inherently porous nature of today’s enterprise. The reality, given a key purpose of SOA/WS is service reuse, is that a single service might simultaneously be both part of externally facing applications as well as internally facing ones.