Extending XML-based Services Beyond the Perimeter[2]

Extending XML-based Services Beyond the Perimeter Authored by Andrew Nash, Chief Technology Officer, Reactivity ABSTRACT Across leading enterprises, architects have discovered that convincing a business owner to invest in Service Oriented Architectures and XML is most efficient when the architect identifies a clear revenue-producing or cost-reducing project that would be demonstrably accelerated by these technologies. The most compelling are often those projects that entail integration between the enterprise and its business partners, suppliers or even customers. The most significant challenge to those projects is assuring security. The vast majority of IT professionals and business people agree that security is the leading concern for SOA and XML messages and most quickly realize that SSL is limited by not providing content security, auditability or reliability. Thought leaders from leading analyst firms and enterprises assert that addressing security concerns is both pragmatic and possible. In fact, many enterprises can and are extending their XML-based services beyond the perimeter with a more pragmatic and graduated approach than is required for comprehensive internal SOA. This paper will discuss how to extend SOA beyond the perimeter through high performance: 1. Service access controls 2. Deep content inspection 3. Alignment of people and processes for sustainable growth © 2006, Reactivity, Inc. WHITEPAPER Contents Expanding XML-based Services Beyond the Perimeter ��������� 3 Case Study: Aeroplan ...........................................................................3 Protecting the Enterprise when Exposing Services ..................4 SSL-Only Protection ....................................................................4 Hard Coded Protection ..............................................................4 Platform Protection .....................................................................4 Agent Protection ..........................................................................5 Gateway Protection.....................................................................5 Controlling Service Access ������������������������������������������������������� 5 Message Transport Security ...............................................................5 Service Level Security ..........................................................................6 Case Study: Carlson Marketing Group ...........................................8 Threat Mitigation����������������������������������������������������������������������� 9 Protecting from XML-Based Denials of Service ..........................9 Practice Safe SOA: Deep Message Inspection .......................... 10 Content Privacy and Compliance ������������������������������������������� 11 Aligning People and Processes for Sustainable Success ������ 12 Applying the Lessons of External Integration to Other Services Perimeters ����������������������������������������������������������������� 12 Types of Services and Associated Perimeters........................... 12 Perimeter Protection Excellence – Reactivity XML Security Gateways ���������������������������������������������������������������������������������� 13 © 2006, Reactivity, Inc. www.reactivity.com Extending XML-based Services Beyond the Perimeter | 2 WHITEPAPER XML services (XML, REST, Web Services, ebXML) continue to gain momentum as the Case Study: Aeroplan Aeroplan, a highly profitable subsidiary of ACE (ACE Aviation Holdings), whose first SOA initiative was to securely expose XML/MQ based services as Web services (SOAP/HTTPS) to third party partners so that those partners could offer goods and services in exchange for Aeroplan miles. The entire project was deployed in 38 days and the time to provision a new business partner is now less than one hour. The net result is that Aeroplan is realizing 500% growth in non-air rewards redemption, making them more profitable and their customers more satisfied (please see Aeroplan Updated Case Study for more information). Following this project, multiple business teams aligned with the SOA philosophy and the use of SOA and XML has expanded throughout Aeroplan and ACH. most efficient and flexible architecture for real-time system to system integration. The largest auto-manufacturers are finding that XML based services are a more flexible and cost effective mechanism to connect dealer networks. Financial services institutions are expanding their market reach by reducing the costs of integrating their services with employers’ portals – growing total revenues while improving their margins. Loyalty companies are enabling real-time “points-based” ecommerce to increase the value of loyalty programs and increase revenues. These are a few of the many examples of pragmatic enterprises realizing significant business gains by extending XML-based services across the perimeter – often as their first foray into XML and standards-based SOA. The virtually instantaneous, open application integration promised by XML services offers organizations the potential to respond rapidly to new business opportunities. The business benefits of connecting and automating mutual processes are clear. XML services technology advances make that goal easier to achieve than ever before. Direct connections to mission-critical functions improve business responsiveness and results, however, they also expose the enterprise to a new class of problems. To extend XML-based services beyond the enterprise, the services architect must: 1. Control service access 2. Deeply inspect content 3. Align people and processes for sustainable protection Expanding XML-based Services Beyond the Perimeter At the beginning of an SOA initiative, many architects make a design assumption that all services will be “within the firewall” and consequently have limited to no protection requirements. These projects often demonstrate integration benefits, but often have trouble getting the enthusiastic support of business teams. The exception is those services built for external consumption to drive a business goal. By focusing on services that extend outside the enterprise and generate benefits visible and quantifiable, services architects can develop a comprehensive SOA that is deployed gradually with continuous business support. To generate continuous support, the projects delivered through SOA must be faster, cheaper and as reliable as projects delivered through traditional integration technologies. With minimal initial infrastructure, services architects can deliver these benefits and be prepared for the growth that follows initial success. © 2006, Reactivity, Inc. www.reactivity.com Extending XML-based Services Beyond the Perimeter | 3 WHITEPAPER Protecting the Enterprise when Exposing Services Every services architect faces choices and trade-offs about where and how to protect the enterprise. Use of XML-based Web services removes the network safety-net because those messages will transit ports that are open for internet access (Port 80 and Port 443). Existing network defenses are mostly oblivious to XML and cannot deliver perimeter protection that has the necessary application understanding to be useful. Consequently, service architects must choose between the following alternatives to protect their multiple services perimeters: • • • • • SSL-only protection Hard coded protection Platform protection Agent protection Gateway protection XML Web services and consequently limit their benefit. As a consequence, service architects and developers seek messagelevel security measures to augment their use of SSL. Hard Coded Protection During prototype and pilot service development, many developers elect to program protection into the service itself. This is often expeditious for demonstrating the service and claiming some level of security. Some developers believe this is the only way to comply with privacy requirements, but the processing and integration cost to the service are very high and the policy control is very low. Both services and security architects recognize that it is extremely expensive to audit all programming and ensure that protections exist as specified. It is also difficult to modify this code to accommodate new use cases and new risks. Networking and operations specialists indicate that the network bandwidth consumption and the service latency quickly are unacceptable with this approach. SSL-Only Protection The logical first response to securing XML traffic crossing the Internet is to use SSL to secure the transport. This is a viable first step and is often a core element of a protection program for XML-based SOA. SSL is well-understood and broadly supported, making it an attractive alternative. But reliance on existing SSL technologies will expose the enterprise to significant deployment delays and considerable risks. SSL aggregators and accelerators expedite the SSL “handshake” so that SSL connections are formed rapidly. These technologies are optimized for “one-way” SSL connections and most services architects want to authenticate the 3rd party connection using “two-way” SSL. In addition, SSL leaves the enterprise exposed to improperly formatted or malicious XML payloads, XML Schema incompatibilities and provides no message level access control (so that every message from an authenticated connection has access to every service exposed to that connection). SSL is not designed for message debugging and service provisioning. The associated message debugging costs valuable provisioning time – reducing the business support for the initiative. These problems limit the interoperability and security of the exposed Platform Protection The next approach usually considered is to leverage the pre-coded plug-ins or toolkits within application platforms, packaged applications, MOM, EAI, EII and ESBs (all of which we will refer to as platforms). This reduces the probability of a standards implementation error and is often as easily demonstrated as hard-coding. The issue with platforms is that the policies that pertain to the service and the message traffic are hard-coded into the platform component and that the platforms have no protections for network-style risks such as denial of service. The policies programmed into the platform can not be governed, modified or optimized centrally which creates significant concerns about their efficacy. In addition, the enforcement of the policy logic occurs on the platform itself with significant performance and security implications. XML Schema, authentication, authorization, encryption and digital signing are all extremely processing intensive and performing these functions on the platform reduces the resources available for actually delivering the intended service. It is inefficient © 2006, Reactivity, Inc. www.reactivity.com Extending XML-based Services Beyond the Perimeter | 4 WHITEPAPER for the SOA to do repetitive operations on the same message as it moves between multiple services. In addition, the message is already in a position to cause damage because it is clearly within the perimeter. For the reasons of governance, performance and security, these platform implementations are rarely used independent of other infrastructures and often can be avoided entirely. Gateway Protection Gateways are network nodes that are centrally controlled for strong governance and offload the expensive processing to enforce policies. These network nodes can be centralized or distributed depending upon service and network architecture. Often, Gateways create a secure buffer between consumers and providers of services where traffic can be normalized and secured in all directions. Reactivity’s XML Gateways also provide optimizations so that policy can define if the same message requires full processing or simple validation as it moves between services. Appliance based Gateways (as opposed to software proxies) offer strong security as well as maximum throughput for traffic. In Reactivity’s case, enterprises experience reduced services latency. Agent Protection To address the governance issue and ensure service level security, many service architects consider agents that enforce policy defined in central policy controllers. This solution does provide considerable insight and control into the enforcement of policies across multiple services and traffic. The issues that the services architect must consider with an agent architecture are the platform coverage, performance impact of platformbased processing and the level of perimeter protection since the message is on the platform when the agent does its work. Platform coverage is a significant consideration with XML messages originating and flowing to diverse application development platforms (J2EE and .NET for example), packaged applications (SAP, Oracle), Middleware (Tibco, SeeBeyond, MQ Series) and legacy applications. In fact, analysts estimate that there are over 60 XML platforms in wide use with multiple versions of each. The cost of deploying and maintaining agents across so many platforms is a significant issue for most architects. The performance impact of agents is the same as platform and hard-coded alternatives – the processing costs for expensive operations come at the expense of the service itself. The inefficiency of repeat processing is also hard to address with an agent architecture. Many architects elect to deploy agents as proxies that are independent servers on the network. In this case, the agents are no longer agents, but instead have become Gateways and should be evaluated in comparison to other Gateways. Controlling Service Access Message Transport Security Much of the success of the traditional Web has been facilitated by creation of the SSL protocol by Netscape, and its subsequent broad adoption by all other browser and server providers. The maturity and availability of the technology have enabled many initial XML Web services to leverage bilateral SSL to authenticate connections and prevent against common transport attacks such as “man in the middle,” or data compromise. The term Web in Web Services misleads many into thinking of the client-server approaches based on user interactions using Web browsers. In that model there are two end points, the browser and the server, and a single transport protocol HTTP – so a simple point to point security model addressing HTTP worked well. In fact, XML Web Services operate much more like a consumer/producer processing model, in which multiple transports may be used and multiple processing steps may be © 2006, Reactivity, Inc. www.reactivity.com Extending XML-based Services Beyond the Perimeter | 5 WHITEPAPER Typical XML Web Services Transport Protocol Mediations HTTP HTTPS HTTP HTTPS MQ Series Tibco SMTP JMS Transport MQ Series Tibco SMTP JMS applied to a transaction. This creates new opportunities and challenges in creating a practical threat defense framework. For example, in addition to HTTP, transports such as the ubiquitous SMTP (email) are appropriate for asynchronous or long lived business transactions, and are growing in popularity. SSL does not provide any security support for SMTP or other store and forward or message oriented transports. To expand beyond the enterprise with XML message exchange, the services architect must design or implement mechanisms to rationalize different transports while preserving the policy-determined security of the XML messages themselves. XML based services requirements rapidly expand beyond a session oriented security approach like SSL to addressing the security of the messages or transactions directly. Ratified standards such as Web Services Security (WSS) address the broad needs of Web Services by directly securing the web service messages, dependant of the transport. Message integrity, privacy and strong authentication for trusted identities are all provided, independent of the security of the underlying transport. Service Level Security At a minimum, every service needs to ensure that only appropriate messages are accepted and processed. While SSL will provide transport level security, service level security depends upon robust authentication of messages as well as dynamic authorization to decide access to services. There are a number of challenges surrounding service level security authentication and authorization functions – determining where to do authentication and authorization, how to leverage existing logic, how to minimize network traffic and latency, and how to reconcile the use of different authentication identities by service consumers and providers. In the adoption of an SOA, enterprises will find that messages are originated by systems with different identity services and credentials. To maximize re-use and interoperability while preserving service access control, the destination service must have an efficient mechanism to validate the identity and ensure authorized access. Finally, these challenges are exacerbated in an SOA where there are likely to be multiple identity systems spanning both commercial and custom products. Application Presentation Session Transport Network Data Link Physical { SOAP Message Security Message Body Service and Message Security SSL Here • Authentication, Identity enforcement • Schema validation • Signature verification • Mediation • Encryption • Compression • Transformation • Message routing • Acceleration • XML Threat Defense © 2006, Reactivity, Inc. www.reactivity.com Extending XML-based Services Beyond the Perimeter | 6 Transport Service Provider WHITEPAPER Service Consumer XML Message ID = UserName Username Valid? The simplest authentication process is for a service to receive an XML message, parse and recognize the identity and then validate that the identity is an acceptable one for that service. The authorization process would then determine if that valid identity is allowed access to this service. This approach assumes that the service consumer will use the identity credential (in this diagram, it is username) recognized by the service provider. determine where to route the authentication request. The Accept Message services architecture needs a scalable model to integrate multiple identity management systems with multiple services. Service This model must often accommodate custom identity Provider management systems. The rationale driving this model is often the aggregation of technologies across the enterprise or Consumer the integration of technologiesID = UserName acquired through mergers. In Valid Username addition, the service consumer may use different credentials Username Valid? Accept Message Service XML Message Service Provider Service Consumer ID = UserName Username Valid? Accept Message XML Message than the service provider can accept. A significant concern Identity and for the service architect is assuring the re-use of the service Access Control providers and to ensure re-use, the service provider must have a mechanism to accept multiple types of credentials. Systems Many enterprises have invested considerably in identity control systems using LDAP, Active Directory or commercial systemsService such as CA Netegrity or RSA ClearTrust. For consistent governance and Consumer Service XML may want rapid deployment, the enterpriseMessage authentication and XML Message with X.509 Service Consumer Provider Service Consumer XML Message with USERNAME Service Provider Does service recognize credentials? Which identity processes which credential? ID = UserName Username Valid? authorization policies to reside in these identity management Service must integrate with it and after recognizing the identity Provider ID = UserName Valid systems. In order to use those systems, the service provider Username Username Valid? Accept Message credential, send a request to the identity management system Service XML Message Access for an authentication decision. This often requires multiple Control Consumer ID = UserName simultaneousUsername Valid? for authentication and authorization integrations Identity and Systems Identity and Access Control Systems with multiple calls between systems for each message. Accept Message Depending upon the service, authentication and authorization decisions can become a very complex set of policies to enforce. For example, a particular service may only be accessible to messages sent from a particular group of machines and domains. The target service may also expect all identity with USERNAME credentials to be delivered to it as SAML credentials even Reactivity not with SAML though its consumers may or Security support SAML. may XML Gateways XML Message Service Provider XML Message Service Service Consumer Provider Service Service Consumer Consumer XML Message XML Message with USERNAME Service Provider ID = UserName Valid Username Which identity processes which credential? Username Valid? Accept Message Does service recognize credentials? XML Message with X.509 Service Consumer ID = UserName Username Valid? Service XML Message The with X.509 architecture requires a mechanism to mediate services Identity and Consumer Access Control Systems between different credentials. This means that a service consumer can use X.509 certificates or username or Kerberos tickets or other identity while the service provider is assured it Access Control will only receive credentials as SAML tokens. The same process is performed in reverse. Systems Identity and There are two areas that complicate the authentication process further. First, an enterprise may have multiple Identity and Access Control Systems identity management systems and the service provider must Service Consumer XML Message with USERNAME Service Provider Service Consumer with USERNAME XML Message with X.509 Does service recognize credentials? Which identity processes which credential? XML Message © 2006, Reactivity, Inc. www.reactivity.com ID = UserName Username Valid? Extending XML-based Services Beyond the Perimeter |  XML Message with SAML Service Provider Service Consumer Reactivity XML Security Identity and Service Provider Service Consumer XML Message ID = UserName Username Valid? Valid Username Accept Message WHITEPAPER Identity and Access Control Systems Case Study: Carlson Credentials Basic Auth User Name X.509 SAML Custom Service Consumer Kerberos Basic Auth X.509 SAML Carlson Marketing Group (CMG), a subsidiary of Carlson Companies, was connecting to a major credit card company in order to offer expanded real-time rewards to credit card holders. The identity management system at Carlson Marketing Group was a customdeveloped system. CMG needed to connect to the credit card company using XML Web services (per the credit card company’s contract) and needed to validate the identity of the individual while replacing it with the identity that would be understood by CMG’s systems. CMG used Reactivity’s AccessLink SDK to integrate with their custom identity management system from the Gateway and used the DataLink SDK to transform the credentials between formats. This enabled their customer to send the credential they use and CMG to accept it without modifying any existing systems. The result was faster time to market, more satisfied clients and cost savings by minimizing back-end system changes. As a consequence, the management at CMG is expanding their use of SOA. XML Message with USERNAME Custom Service Provider Kerberos Does service recognize credentials? Which identity processes which credential? The time required for all the integration, routing and authentication decisions can often impact SLAs and serviceXML Message In addition, the volume of XML messages availability. Username Valid? either through new connections or through expanding service re-use will lead the service platform to incur significant latency and processing costs in authenticating Identity and Consumer and authorizing access. Much of the infrastructure integration and authentication Systems optimization can be most efficiently offloaded to policy-controlled gateway appliances. Access Control Service with X.509 ID = UserName Service Consumer XML Message with USERNAME XML Message with SAML Service Provider Reactivity XML Security Gateways XML Message with X.509 Service Consumer Identity and Access Control Systems Application systems composed of XML based services create additional requirements for the use of identities that can be correlated and verified to support access control, auditing and trust. The identities of principals initiating a transaction, the service components involved in processing a message, the roles or other attribute-based authorization and entitlement systems, all become important in various service implementations. Additional replay attacks and opportunities for insertion of invalid transactions or consumption of information by unauthorized users all become more significant issues in an application system or SOA. © 2006, Reactivity, Inc. www.reactivity.com Extending XML-based Services Beyond the Perimeter | 8 Credentials Marketing Group User Name WHITEPAPER Reactivity XML Security Gateways integrate natively with multiple identity systems and can enforce the authentication policies in multiple systems while mediating different formats, terminating SSL and ensuring the XML content is safe and consumable for destination services. For example, Reactivity XML Security Gateways detect authentication and authorization issues while optimizing service responsiveness by caching authentication credentials and decisions. In combination with native APIs and custom identity system integration (custom integration delivered through Reactivity’s AccessLink SDK) and credential mediation, the Reactivity XML Security Gateways provide a robust authentication and authorization enforcement network for services while ensuring that the service providers have the authentication and authorization information needed to deliver their business logic. enthusiastically can accidentally disable the service. And the relatively minimal experience of developers creating XML based services creates proven opportunities for errors such as infinite loops that will also render the service inaccessible to all traffic. Existing network or application infrastructure can neither detect nor defend XML based services from these accidental attacks. Existing network and web protectione mechanisms do not address denial of service attacks that are launched within the application level, which is the case for XML and Web Services. Ensuring the availability of these services requires a scalable approach to address these risks through heuristics and alerting to identify patterns which MAY constitute a Denial of Service attack against XML and Web services. XML Web services integrate core business applications with each other and business partners. As a consequence, a number Threat Mitigation Protecting from XML-Based Denials of Service As with any network based service, a DOS attack is a serious and commonly experienced problem. The fundamental approach used in all denial of service attacks is for the attacker to initiate a process on the service provider side that is cheap for the attacker but consumes the resources of the provider to the point where the service is inaccessible. SSL itself represents a DOS attack vector, as the overhead of mutual authentication is so high, that this could be leveraged by an attacker to consume the service compute resources. It’s relatively easy to overwhelm an XML based service. In comparison to web servers which handle 1000s and 10,000s of transactions per second, XML based services tend to handle about 10s or possibly 100s of transactions per second. A partner that simply attempts to interact with the service too of indicators that might be considered an attack are often legitimate business patterns. For example, high message arrival rates represent an overly simplistic trigger for DOS detection and avoidance in the case of Web Services. Did your business partner trigger a huge transaction load due to the availability of cheap iPods on their web site just prior to Christmas? This leads to an interesting conclusion about DOS “attacks” applied to XML based Services – some of them may be inadvertent, from trusted sources, but the result is the same. It is therefore crucial to assess denial of service metrics over configurable periods of time and apply appropriate heuristics to classify traffic patterns. M M M Internet M M M M M M M M M M M M M M © 2006, Reactivity, Inc. www.reactivity.com Extending XML-based Services Beyond the Perimeter | 9 WHITEPAPER Metrics to Detect XML Denial of Service Attacks Per Server Attack Indicators (distributed Dos) • Rate of transaction per second • Average bytes per second • Server response time and server busy errors External XML Web Services DMZ XML Web Services Aware Applications Reactivity Manager App Servers App Servers Internet Reactivity XML Security Gateway Reactivity SOA Gateway Message Busses Individual IP Attack Indicators • Overall request rate • Internal errors (schema validation failures, malicious content, invalid digital signatures) • CPU Usage • Authentication - many 401/403 errors returned • Service errors - triggered when the destination service returns high numbers of errors such as SOAP faults and HTTP 500 errors • Service latency DATA CENTER Internal XML Web Services In addition to arrival rates and flow control of messages passed to back end servers, a unique form of DOS attack vector is created by the richness and complexity of XML itself. Extremely complex schemas or expansion of recursively defined entities represent high overhead processing that ideally suits the needs of a DOS attacker. In this case a single XML message employing a technique such as recursive entity expansion may consume all the resources of a service. Alternatively, a SOAP huge attachment on a small number of messages may have a similar impact. understood issue in the HTML browser world, using techniques such as SQL command insertion. Content based attacks from trusted systems can occur as a result of a user mis-configuration or comprised security of the system initiating the transaction (e.g. infection by a virus). Specific services, applications or platforms are susceptible to a set of toxins unique to it. The service or application may have vulnerabilities unique to how it was developed. Examples of service specific vulnerabilities include how the service performs field and type checking for updating of database entries. Examples of platform specific vulnerabilities include those such as the SQL slammer virus which exploited a buffer overflow problem associated with a UDP port on a well known SQL Server. Practice Safe SOA: Deep Message Inspection XML messages and their payload are easy carriers for unintentional or malicious service toxins. This is a well © 2006, Reactivity, Inc. www.reactivity.com Extending XML-based Services Beyond the Perimeter | 10 WHITEPAPER can be identified through schema validation and detailed Internet M SQL SQL content screening filters that are specific to the service and intended connection. In addition, it’s important to ensure that the service WSDL is valid and that the external references from the WSDL are valid and available for the production service. Content Privacy and Compliance XML messages are self-describing and human readable. These Because toxins are service, application and platform specific, the content inspection must be specific to the service, application and platform. At least, the service architect must have a mechanism to ensure message well-formedness. In addition, most service architects recognize that validation of XML Schema is a crucial, albeit potentially expensive, mechanism to protect their services from toxic XML. Ideally, the service architect has a policy-controlled mechanism to define unique content screening filters applied across the enterprise as well as to messages intended for a specific service. The processing costs and delays associated with XML Schema validation as well as the ability to deeply inspect all XML content to ensure message purity is best handled by gateway appliances designed for the task. Consequently, it is important for a gateway to have the flexibility to configure new filters and/or to securely upload new filters as new vulnerabilities are discovered in standard platforms or new XML web services applications are deployed. XML Content Filtering is more analogous to text filtering than email virus filtering. For example, there are XML use cases where SQL should be accepted – just only specific commands. And there are situations where the XML may carry the words that constitute an RPC statement (assign tables) but are actually innocuous text (assign tables to Charles for set-up). Types of content-based threats include malicious RPC statements and bad WSDLs. Malicious RPC includes SQL injection attacks. Threats can come from the insertion of inappropriate content into a well-formed XML message. This attributes enable the very broad interoperability that makes XML attractive for extensive system-to-system integration for new applications. These attributes also provide opportunities for confidentiality and integrity violations that will undermine the very credibility of those applications. The mechanisms to ensure the confidentiality and integrity of XML messages are well-understood and supported for both XML and Web Services (through the WS-Security specification). For example, confidentiality can be ensured through the use of XML Encryption. This mechanism ensures confidentiality of the message regardless of transport. But this confidentiality may come at a high performance cost and increase the latency of the system beyond acceptable levels. However, integrity can be ensured through XML Digital Signatures. In this case, an entire message may be signed or key elements may be signed to ensure that the content is tamper-proof. Again, these operations come with a high performance cost and both XML Encryption and XML Digital Signatures are complex standards with numerous implementation options – creating opportunities for errors and lack of interoperability. XML Security Gateways offload and optimize these expensive operations while delivering a robust record of the confidentiality and integrity of the XML messages. That record can be used to prove compliance and to repudiate a transaction’s processing. By enabling service and message content-specific policy, XML Security Gateways can enforce granular confidentiality and integrity policies at the same level of detail as the destination service with end to end security. © 2006, Reactivity, Inc. www.reactivity.com Extending XML-based Services Beyond the Perimeter | 11 WHITEPAPER XML Security Gateways also ensures that XML based services comply with Sarbanes-Oxley 404, HIPAA, GLBA, CA 1386, EU Privacy Directive and corporate compliance and privacy standards by providing tracking of critical Web services traffic and alerting of abuses. It enables the inspection, action and reporting on data such as: • • • • User credentials and identities Company credentials and identities Services and applications accessed Requesting parties, servers, and applications to test with the policies easily exported from their environment and imported into the product environment (for the previously mentioned approvals). Finally, the technology should provide mechanisms to insure that protected services are INACCESSIBLE unless properly authenticated and screened. This last mile protection can be achieved through a variety of mechanism: using network address access control within the stack, maintaining SSL connections between the technology and the services, or inserting signed SAML assertions to every processed message with accompanying logic at the service to only accept messages so marked can be a simple mechanism to thwart insider attacks. Aligning People and Processes for Sustainable Success Finally, the best perimeter protection for XML services and SOA is meaningless if it cannot be sustained by the organization without the steady participation from services architects. There are clearly a set of practices and policies that must be codified to guide service developers regarding the perimeter protection required for their services. In addition, the technology used to protect the perimeter should enable an enterprise to implement a policy workflow model consistent with the level of controls required by business as well as compliance (legal) guidelines. Service architects must either identify, create or select technology that re-enforces the practices that protect the perimeter and evolves with expansion of service usage or new risks. For example, the technology should support a large number of configurable roles that deliver different privileges to users. In addition, the technology should provide a visual mechanism to compare proposed policy changes to existing policy so that administrators with approval and deployment rights can easily approve and deny requests as well as track a workflow of policy development, approval and deployment. Finally, the technology should have functionality that encourages its use by application developers as they create new XML based services and provision new connections to existing services. An example would be functionality that enables an isolated application development team to create services, connections and policies Applying the Lessons of External Integration to Other Services Perimeters The uses of XML-based services within the enterprise often incorporate re-use and composite services that commonly cross boundaries inside the enterprise. These boundaries may be physical such as the boundary between data centers or remote offices and headquarters. These boundaries are also virtual – between different services platforms and applications where there are different trust practices for access and data review. It is crucial that service architects have a robust view of service perimeters and recognize that any boundary crossing by definition constitutes a perimeter. Most frequently, every perimeter requires some protection if for nothing more than to ensure the availability and responsiveness of the service itself. Types of Services and Associated Perimeters Successful XML service and SOA implementations have a business driver that often shapes the type of services that are deployed and their associated perimeters. The obvious perimeter is between enterprises through third party accessible services. These services are created to drive real-time interaction with partners, suppliers and customers that drive incremental revenues. There is a clear necessity to © 2006, Reactivity, Inc. www.reactivity.com Extending XML-based Services Beyond the Perimeter | 12 WHITEPAPER protect the perimeter between the service and the 3rd party connections. Stand alone services provide central access to shared data or function – i.e. customer information store. Consequently, the perimeter for a stand alone service is the edge of the service itself. This is the closest-in perimeter possibility and often the easiest to implement for the first service and the hardest to scale with multiple services and multiple connections. Enterprise Service Busses are used to expose legacy or MOM (message oriented middleware) as services and integrate applications more efficiently. Within the ESB, the ESB ensures that every service on the bus is protected and that the messages are acceptable and compatible across the bus. That said, it is common that enterprises have multiple MOMs, EAI, EII and ESB technologies – stand alone and integrated into application platforms and packages. Consequently, there is a perimeter between multiple ESBs. In addition, there is a perimeter between ESBs and external connections to the services offered on those ESBs. Composite services are representations of a business process as a service for more efficiency and fewer errors. A composite service may be implemented using an orchestration server, ESB, EAI, EII or other technology which determines if there are one or more perimeters. If the implementation mechanism ensures the security between services in the composite, then the only perimeter is between composite services and their consumers. That said, the most loosely coupled composite applications rely upon an orchestration server (or service) to coordinate the messages between services in the composite and this introduces a perimeter between the individual services within the composite service. Eventually, the enterprise will have to address each of these perimeters with a policy controlled infrastructure that can accommodate the different practices required by each type of perimeter – just as virtual firewalls provide protection at the IP level. Perimeter Protection Excellence – Reactivity XML Security Gateways Ensuring that XML messages securely and efficiently reach their intended targets with minimal latency and comprehensive policy control requires dedicated infrastructure that understands XML messages. Gateways provide the critical protection need at each service perimeter - between un-trusted and trusted zones. Reactivity XML Gateways fit in seamlessly with other network infrastructure and can be administered by both application and operations staff. They integrate with existing infrastructure such as directories, SSO, PKI and network system management. Exposing services beyond the enterprise must take into account several different types of risks, beginning with access control, preventing denials-of-service (DOS) and deeply inspecting content. This evaluation is always application and architecture dependent, and the Reactivity XML Security Gateway adapts to ever-evolving perimeter protection needs of XML services. Finally, understanding people and process issues and their role in threat prevention will result in a better appreciation for solutions which provide valuable functions such as flexible authentication policies for users and service requestors, and role-based administration for gateway administrators. Reactivity provides the critical XML Security Gateways used by enterprises to realize the promise of XML services and SOA. Reactivity’s family of products enables businesses to secure, accelerate and integrate XML Web services efficiently with the market’s most extensive policy control and end-to-end performance. Reactivity customers accelerate their time-to-market and gain competitive advantage in their businesses through the use of secure, reliable and responsive XML based services. For more information about Reactivity, go to www.reactivity.com, +1-650551-800 or info@reactivity.com. © 2006, Reactivity, Inc. www.reactivity.com Extending XML-based Services Beyond the Perimeter | 13