An Open Policy Framework for Cross-vendor Integrated Governance

An Open Policy Framework for Cross-vendor Integrated Governance White Paper Intel SOA Expressway An Open Policy Framework for Cross-vendor Integrated Governance Intel SOA Expressway delivers a pluggable SOA governance policy framework based on XML policies and logs for open integration Introduction to the Problem Consistently enforcing service policies in a Service Oriented Architecture is a key ingredient to successfully deploying software services at scale. Most organizations have multiple business and IT domains, each with their own stack of vendor technology and service taxonomy. When domains are exposed to the Enterprise at large or through the Extended Enterprise on the Internet to customers and suppliers, consistency in policies such as security, version management, and audit become important requirements. Policy Standards SOA Governance Polices (Registry/Repository) SOA Infrastructure Policies Systems Management Acceleration Intel SOA Expressway Transform Routing Governance Security App Domain 1 App Domain 2 Service Service

Table of Contents Introduction to the Problem........................................................... 1 An Architecture for a Solution................................................................ 3 The Implementation.......................................................................... 5 Key Benefits of this Approach................................................................ 7 Where to Find Out More............................................................... 7 2

Introduction to the Problem (cont.) Governance of these services from a common policy definition store and consistent runtime behavior is often difficult to achieve. Enterprises deploy or build solutions such as ERP, CRM, Web Store Front etc. from disparate vendors. Each vendor product handles the definition of service policies through service registry/repository or application configuration consoles with their own specific definition. This makes it difficult for various instances of services which become responsible for enforcing those policies and data to do so consistently on messages which pass around within the Enterprise and across the extended Enterprise. The concept of separating the centralized service registry, policy management system and the policy enforcement runtime has been wellestablished. In reality though most technology stacks implement a hard coupling between the policy definition and the runtime enforcement environment. In the case where the separation is somewhat clear in the vendor product positioning, even popular service registries/repositories solutions work best with the same vendor s intermediary or application server. In some cases the only possibility to get policy definition enforced at runtime is to use a single vendor approach. However, single sourcing the SOA policy planning, design, enforcement and management across the Enterprise is often difficult to achieve due to business environment, acquisition, or supplier relationships. Unfortunately the policy standards are still not mature enough or rich enough to provide an answer. What is needed is an open platform, and policy integration framework that allows an organization to bridge different vendor registries/repositories with various service implementations. This paper discusses the architecture and an implementation in Intel s SOA Expressway which makes this type of open and integrated governance possible. An Architecture for a Solution The key problem is that there are vast differences between the scope, structure, semantic definitions and enforcement capabilities of service policies across the major service registry/repository, enterprise service bus and other middleware component vendors. There is some modest standardization through WS-Policy framework, e.g. WS-SecurityPolicy, WS-ReliableMessagingPolicy and the like. In policy domains beyond these few, however, standards are lacking in providing a common semantic policy definition allowing the interworking of service governance and enforcement runtimes between solutions from different vendors. The other key consideration is that different policy design and governance solutions and their enforcement runtimes have proprietary ways by which to exchange the policy statements. The lack of adoption of standards such as WS-Transfer or WS-ResourceTransfer in the exchange of policy statements also introduce difficulty in the interoperability of service governance and service runtime environments. What this boils down to is a classic data interoperability problem. It requires an runtime governance platform which can: Deal with the structural and semantic variations in policy definition and allow different formats of policy to get translated into a format the governance runtime execution container can interpret. Deal with network protocol and interaction expectations of the policy design-time and service execution environment. Provide an unattended means to generate the governance runtime s application logic and configuration to execute any policy from any source. 3

To meet these requirements, Intel enhanced SOA Expressway to include two interface layers, (a) to receive policy from any service registry/ repository or application meta-data source and, (b) to send runtime service statistics and status. A picture of the overall architecture is depicted in Figure 1 below: Registry/Repositories SOAE Design and Monitoring Components Service/Policy Designer Cluster/Service Monitoring Console Vendor 1-n Option A UDDI Option A Design-time Policy Infrastructure Options: (A) SOAE or (B) Any Vendor Solution Option B UDDI Policy Design SOAE Run-time Environment Pluggable Policy Container & API Option B Standards or Proprietary Policy Open Service Monitoring Instrumentation Option B Policy Monitoring Solution: (A) SOAE or (B) Any Vendor Solution Monitoring & Management Vendor 1-n Figure 1 SOA Expressway Governance Architecture Enables Tight Coupling Between Policy Administration Point and Policy Enforcement Point for SOA Governance Vendor 1-n To implement the policy management and service monitor adapters, we leveraged the extensibility and integration features of the core Expressway platform. The architecture of the policy management adapter is included in Figure 2 below: Service Governance Policy Governance Runtime (Orchestration) Expressway Un-attended Runtime Application Builder (AAG) JMX API Normalized SOA Expressway Policy Meta-data Figure 2 Extensible Policy Management Adapter 4

SOA Expressway can either poll or receive a message push from one or many policy sources using SOA Expressway s enhanced ability to receive policy information over any protocol and in any data formats. Then the source policy document is translated into a normalized policy meta-model that Expressway can interpret. A visual representation of those artifacts is included here: SOAE Application A simple example of the orchestration looks like this: WSS, AAA, & Attack Policy Workflow WSDL Application Specification File Custom Java App XSLT Schema Other Support Files Application Deployment File Figure 4 SOAE Application constructs allows automatic policy and service generation, update and deployment The Auto Application Generator (AAG) builds these artifacts dynamically from the normalized policy meta-model and packages the artifacts automatically into a SOA Expressway package referred to as bundle. The AAG also deploys the application bundle into the SOA Expressway runtime container via JMX and automatically activates the application bundle. These application bundles are versioned and when upgrading to a newer version due to policy updated, and critical to a large Enterprise, in-flight message traffic is not lost. This component is transparent to the service consumers and producers. Figure 3 Sample Policy Orchestration This meta-model provided by Expressway is designed to be flexible in order to support various use cases such as security policies, monitoring policies, message routing / service versioning policies, etc. It clearly separates the notion of on-the-wire conformance policy and policies pertaining locally to the enforcement point. Once the normalized policy meta-data is generated the process proceeds to calls a component referred to as the Auto Application Generator (AAG), to generate the SOAE specific policy containing several artifacts that allow the runtime to enforce the policy. Security Token Meta-data: The Security Token Metadata is a collection of security tokens that are needed in the SOA Expressway for the WS-Security and authentication processing. This specification is based on WS-AddressingAndIdentity, XML-Signature and XML- Encryption and their proper extensions. The Implementation The key to the implementation is the structure of the normalized policy meta-model and the logic implemented in the AAG component of SOA Expressway. These components are standardized, so Expressway can integrate with any source of service policy. Most commonly these will be security and monitoring policies based on knowledge from existing deployments, but if the source of the data can represent it, the policy can be more than these categories. Normalized Policy Meta-Model: The normalized policy meta-model consists of three main document types: The Application Meta-Data, Local Policy Definition, and Security Token Meta-Data. Descriptions of these models include: Application Meta-Data: The Application Metadata is based on WSMetadataExchange. It largely consists of WS-MetadataExchange 5

constructs and uses WS-MetadataExchange dialects plus SOA Expressway specific dialect extensions. WS-MetadataExchange allows three mechanisms to include a metadata unit in the MetadataSection: MetadataReference, metadata Location and direct embedding of the metadata unit. In this Application Metadata specification, only the direct embedding mechanism is supported. The other two mechanisms are for future consideration. Application Metadata Actionflow (am:application-actionflow) WSDL w/policy Attachment or Reference (wsdl:definitions) Public Policy Attachments (wsp:policyattachment) Schema (xs:schema) XML Stylesheet (xslt:stylesheet) Local Policy Attachments (wsp:policyattachment) Security Token (am:security-token) The structure of the Application Metadata (with component dialect in parenthesis) and dependence relations are depicted in Figure 5. The basic metadata dialects required by SOA Expressway Application Metadata include: Action-flow Specification: specifies an implementation of runtime policy enforcement that Expressway provides to the service consumers. For example, in a WS-Security proxy usage model, the SOA Expressway runtime performs WS-Security and Authentication, Authorization and Auditing processing of the service requests acting as a service proxy and forwards the processed request (often after verifying and stripping off WS-Security artifacts) to the service container where the service is hosted. WSDL: defines the public services the SOA Expressway runtime provides to the service requesters. It also defines the supporting service interfaces that the SOA Expressway relies on in order to implement the services it provides. Both the public and supporting WSDLs may contain WS-Policy attachments. However, the policy attachments in the public service definitions (WSDLs) should only include the policy assertions both service consumers and service providers (the SOA Expressway) must adhere to in order to communicate with each other. In this sense, the policy assertions in these attachments are public. Similarly the policy attachments in the supporting WSDLs should only contains policy assertions both service consumer (the SOA Expressway) and the service providers must adhere to in order to communicate with each other. In both cases, policy assertions concerning implementations local to the SOA Expressway in terms of how to enforce the policy in its public service interfaces and how to conform to the policy in its supporting service interfaces should not be included in these WSDLs. An example of these local policy assertions includes the mechanism in the SOA Expressway to authenticate a service client, whether it should use local keystore or LDAP server. These local policy assertions should be described in a separate local policy metadata unit and apply to the subjects in the WSDLs using WS-PolicyAttachement s External Policy Attachment mechanism. This approach of separating public and local policy assertions in different metadata units is for maintaining data consistency and allowing directly publishing public service WSDLs without modifications. XML Schema: as required by the WSDLs or/and the Actionflows XML Stylesheet: as required by the Actionflows. WS-SecurityPolicy: as required by WS-SecurityPolicy assertions embedded in WSDLs as policy attachments or as policy references. WS-PolicyAttachment: as required by standard WS-Policy or Expressway specific policy assertions. Security Token: as required by enforcing WS-Security policies and Authentication assertions. Local Policy Definition: The local policy metadata serves as a container for policy statements that are pertinent to the local implementation in enforcing other policies. Policies defined here typically should not affect the wire format of the message being exchanged. An example of a local policy is that for specifying the means for carrying out an authentication of a user request. The policy subjects these policy statements apply to are defined through the WS-PolicyAttachment external policy attachment method so that no reference to these policy statements will be present in the WSDLs or other public policy attachment files. Security Token Meta-data: The Security Token Metadata is a collection of security tokens that are needed in the SOA Expressway for the WS-Security and authentication processing. This specification is based on WS-AddressingAndIdentity, XML-Signature and XMLEncryption and their proper extensions. 6

Key benefits of this approach There are a number of important benefits of Intel SOA Expressway s approach to integrated full lifecycle governance. They include: An open, standards based architecture which supports integration with any computable source of policy Supports many types of policy (security, monitoring, versioning, routing, etc.) Allows on site integration and does not require expensive resources or vendor software releases to support integration with a deployment unique product, technology or configuration Delivers the means to consistently enforce policy across services, domains, a and technology sets when Expressway is used as a service proxy across service implementations Closes the gaps between needs for integrated governance and the state of standards and service registry/repository runtime intermediaries Where To Find Out More About SOA Expressway SOA Expressway is a soft-appliance deployed to address common XML and SOA problem areas such as acceleration, security, service mediation and service governance. SOA Expressway is available for any organization deploying services (SOA), hosted services (SaaS) or Web 2.0 (RIA). SOA Expressway is available for standard operating systems such as Windows* and Linux* and requires no special custom hardware other than standard OEM servers. For more product information: http://www.intel.com/software/soae For more comparison information and to register for Webinars: www.comparedatapower.com Contact us by phone Americas 1-630-627-3370 UK and Ireland: 44 (0)7919 303 236 All other Geographies: 1-905-681-8768 Contact us by email E-mail: intelsoainfo@intel.com Performance tests and ratings are measured using specifi c computer systems and/or components and refl ect the approximate performance of Intel products as measured by those tests. Any difference in system hardware or software design or confi guration may affect actual performance. Buyers should consult other sources of information to evaluate the performance of systems or components they are considering purchasing. For more information on performance tests and on the performance of Intel products, visit http://www.intel.com/performance/resources/limits.htm. Dates and plans are preliminary and subject to change without notice Intel may make changes to specifi cations, release dates and product descriptions at any time, without notice. For processors with HT Technology, performance and functionality will vary depending on (i) the specifi c hardware and software you use and (ii) the feature enabling/system confi guration by your system vendor. See www.intel.com/products/ht/hyperthreading_more.htm for information on HT Technology or consult your system vendor for more information. For more information go to: http://www.spec.org/spec/trademarks.html 2009 Intel Corporation. Intel, Intel logo, Intel Inside logo, and Core are trademarks or registered trademarks of Intel Corporation, or its subsidiaries in the United States and other countries. * Other names and brands may be claimed as the property of others. Printed in USA Please Recycle SOAE Governance Policy White Paper 7