Docstoc

Runtime SOA Governance

Document Sample
Runtime SOA Governance Powered By Docstoc
					Runtime SOA Governance
Defining, Enforcing & Validating Web Services Policy




                                  Layer 7 Technologies

                    White Paper
Runtime SOA Governance


Contents

                                             ................................................................................................
Introduction ................................................................                                .................................................. 3
                           ................................................................................................
Design-time SOA Governance ................................                                ....................................................... 3
                                                                                                    .....................................
Runtime SOA Governance Requirements ................................................................................................ 4
                                          ................................................................................................
   Policy ................................................................                                ......................................................... 4
                           ................................................................................................
Policy Lifecycle Management................................                                ........................................................ 4
                      ................................................................................................................................ 5
   Policy Enforcement ................................                                                                ...................................
                    ................................................................................................................................
   Policy Validation................................                                                                ........................................ 5
                                                                                                     .....................................
Overcoming Implementation Challenges ................................................................................................ 5
       Way                                                                                              ....................................
   Two-Way Trust and Federated Identity ................................................................................................ 5
                                                                                                         ....................................... 6
   Client Policies and Policy Negotiation................................................................................................
                                  ................................................................................................
   Distributed Policy Enforcement ................................                                ................................................ 6
                                        ................................................................................................
Summary ................................................................                                ....................................................... 6
                           ................................................................................................
About Layer 7 Technologies ................................                                .......................................................... 7
                             ................................................................................................
Contact Layer 7 Technologies ................................                                ....................................................... 7
                  ................................................................................................................................
Legal Information ................................                                                                .......................................... 7




                                             ogies
             Copyright © 2010 Layer 7 Technologies Inc. All rights reserved. SecureSpan and the Layer 7 Technologies design mark are
            trademarks of Layer 7 Technologies Inc. All other trademarks and copyrights are the property of their respective owners.
                                                                                yrights                                                                                 2
   Runtime SOA Governance


   Introduction
   Service Oriented Architecture (SOA) is a new integration framework that enables organizations to map IT processes
   to changing business needs. By exposing applications as reusable and dynamically composable services, new
                                         demand
   business processes can be defined on-demand to create business agility.

                                                         loosely-coupled services, one application to another. Users
   However, SOA is predicated on an ability to integrate loosely
   may or may not be involved. This creates challenges for governing how service assets get developed, provisioned
             ed.
   and invoked. For developers of service assets, governance amounts to the processes and policies describing how
   services get built, registered, changed and discovered. For operators of SOAs, governance becomes a matter of
   how service behavior gets defined, enforced and validated at runtime. This whitepaper examines the
   considerations involved in implementing an SOA governance framework at both design time and runtime, as well
                                                             validation.
   as the role of runtime policy definition, enforcement and validation


          time     Governance
   Design-time SOA Govern
          time
  Design-time SOA governance begins with control over how services (specifically service APIs) get created,
  registered, changed and discovered. In most cases, service APIs are published as a Web Service Description
                                              While
  Language (WSDL) formatted XML document. While this greatly simplifies the process of building client applications
                             that can consume a service’s business logic, it also creates security and lifecycle issues
 Design-time policy                                                                                      controls
                             since WSDL does not provide integrated access or revision management controls.
 governance starts
with control over the          To govern the service creation and lifecycle process, it is necessary to provide a
   creation, regis-                         check-in/check-out mechanism for service developers and a commensurate
                               centralized check
                               WSDL discovery and access control system for client developers. Underpinning both is a
 tration, discovery
                                                WSDLs
                               registry where WSDLs can be published to and discovered from. In most cases, the
and management of              registry will be a UDDI repository with distributed synchronization for added
    Web services               redundancy and scalability (automatic with UDDI v3). Alternatively, a flat file database
                                                 synchronization can be used. The decision over whether to use a UDDI
                               with distributed synchron
   registry or database comes down to whether organizations prefer centralized WSDL pointers (UDDI) or WSDL files
                                                                                    multiple
   (database). An ideal design time solution will support either option, as well as multiple registry vendors (UDDI
                                                                                        Systinet).
   registries include those from Microsoft, IBM, Oracle/BEA, SAG’s Infravio and HP’s Systinet

                                                      check-in/check-out mechanism is required to manage service
   Once a registry decision has been made, a service check             out
                             s.                                        check-in/check-out mechanism must provide
   publication and revisions. Like source code registration tools, the check          out
   ability for service developers to designate such metadata as WSDL owner, revision history, searchable annotations
                                                             access
   and associated policy documents that describe runtime access and behavior preferences (see the next section for
   more runtime details).

                                                       check-in/check-out based on a publisher’s or requestor’s
   It must also provide approval processes for WSDL check              out
                                           check-in, there should also be a validation test to check whether a new
   identity, email request or IP range. At check
                                        WSDLs.
   WSDL conforms to older or related WSDLs

    XML gateways can                                                            check-in                  WSDLs
                                         While client developers don’t require check in mechanisms for WSDLs, they do
    provide enhanced                                        check-out controls to ensure design-time access control. These
                                         require their own check                                 time
 lifecycle management                    access controls should include the requestor’s identity, credentials, IP range,
 capabilities, including                 and/or email request/approval. To make discovery simpler for client developers,
                                         WSDLs should be searchable based on WSDL description or associated metadata
 service virtualization,
                                         like owner, revision history, annotations or policy preferences. Both Systinet and
  entitlement provision
                                         Infravio support some level of design time policy definition for describing when
 and code-free genera-                   and under what terms a particular WSDL can be accessed. Both vendors are Layer
    tion of WSDL APIs                    7 partners.

                                            ogies
            Copyright © 2010 Layer 7 Technologies Inc. All rights reserved. SecureSpan and the Layer 7 Technologies design mark are
            trademarks of Layer 7 Technologies Inc. All other trademarks and copyrights are the property of their respective owners.
                                                                                yrights                                                3
   Runtime SOA Governance

                                                           life-cycle
   Organizations looking for added security or enhanced life cycle control might want to implement an XML Gateway
                  level                            functions,                 based                 SLA
   to provide API-level control and virtualization functions such as identity-based access control, SLA-based routing
   of requests across multiple back end UDDIs and WSDL stores, and accelerated WSDL remapping so that APIs can be
                                                                                code-free
   personalized to a requestor’s entitlements. XML gateways can also provide code free generation of WSDL APIs
                 SOAP                    sub-operations
   based on non-SOAP XML schemas or sub operations inside one or more already defined services.


   Runtime SOA Governance Requirements
   Policy
   Policy description and control lies at the heart of runtime SOA governance. Policy is a prescription that describes
   when and by whom a service can be accessed, and how it is to behave after the access is granted. A runtime SOA
   policy therefore describes a service contract for regulating access to a service by a client application, as well as the
                                service’s subsequent behavior after the client invokes it. While there is currently no
   To ensure future             universally accepted standard for expressing an SOA policy, two initiatives are
  interoperability, a           endeavoring to normalize the expression of access policies specifically, and service
   SOA governance                                                Access
                                policies in general. Extensible Access Control Markup Language (XACML 2.0) defines an
 framework should                                              authorization                   information
                                XML schema for expressing authorization and entitlements information—information
 provide support for                                                                                            WS
                                required to access resources and hierarchical entities like XML documents. WS-Policy,
    the competing               currently a specification put forth by IBM, Microsoft, SAP, Oracle/BEA and Verisign,
   XACML and WS-                endeavors to describe how to express access, as well as behavior constraints and
   Policy standards             capabilities. Both initiatives contemplate policy composition from atomic policy
                                assertions, with WS-Policy also allowing for more sophisticated composition based on
   runtime inheritance, negotiation, delegation and branching. An ideal runtime for an SOA governance framework
                                                                                                          interoperability
   should accommodate both standards for describing policy. This will ensure future integration and interopera
   with existing access and application platforms.


   Policy Lifecycle Management
                                          access
   Defining SOA policy for both runtime acce and behavior control requires the ability to author policy declaratively.
   Otherwise, policy consistency and compliance can never be guaranteed. Because SOA policy must describe both
                                                                                                              behavi
   access and behavior, it must be composable from atomic assertions that express all possible access and behavior
   variables. These can include constraints and capabilities around authentication, credentialing mechanisms,
                                authorization rights, privacy and integrity requirements, data validation and threat
To accommodate in-              mitigation preferences, message routing and transformation expectations, SLA terms,
dustry-specific traits,                                                                      dustry
                                transport and reliability conditions, protocol support and industry specific preferences
  as well as unique                                                        redaction,            audi
                                (such as content rights management and redaction transaction auditability and non-
business processes,             repudiation).
                                repudiation)
  policy authoring
 environments must              To allow for industry and company specificity, any policy authoring environment must
    be extensible               be extensible in the type of assertions it can support. It will also need to allow for
                                diverse composition features, including runtime inheritance (assembly from existing
                                                                       delegation
   policies and policy fragments), negotiation (runtime contracting), delegation (to external policy decision points)
   and branching (based on runtime variables and events like message content, requestor identity, SLA performance,
                                                                                                   identity
   logical condition, and so on). Other authoring features should include: personalization for identity-based
   customization, templating for easier reuse, logic validation for design time testing, import from and export to
                                                                      compliance
   external policy stores and repositories (including access systems, compliance products, management solutions,
                                                         control and collaborative workflow for managing distributed
   application platforms, and UDDI), as well as version con
   policy authoring and approval processes.




                                            ogies
            Copyright © 2010 Layer 7 Technologies Inc. All rights reserved. SecureSpan and the Layer 7 Technologies design mark are
            trademarks of Layer 7 Technologies Inc. All other trademarks and copyrights are the property of their respective owners.
                                                                                yrights                                                4
   Runtime SOA Governance

   Policy Enforcement
                                             provisioned
   Once policy is defined, it needs to be provisioned directly to enforcement and application points in an SOA, or
                                                         look-up. Policy application points are client applications that
   published to a registry alongside a WSDL for later look
                                                                         enforcement
   require policy configuration to successfully access a service. SOA enforcement points include service endpoints and
   intermediates (like XML firewalls and gateways) that respond to a client request based on the client’s rights and
   capabilities. The process of policy provisioning assumes that each of the potential SOA “actors” that depend on
                                                                  end-points),
   policy, (i.e., client applications, intermediaries and service end points), are equipped to consume and execute
                                           agent-based
   policy instructions. If they are not, agent based proxies will be needed to consume and interpret a policy on behalf
   of the underlying SOA actor.

   Today, most SOA platforms are not natively equipped to consume runtime policy instructions written in either
                     Policy.
   XACML 2.0 or WS-Policy. For that reason, most organizations contemplating deploying a runtime policy
                                    epend
   enforcement infrastructure will depend on the use of XML firewall and gateway intermediaries. These
   intermediaries can also provide a number of security, performance and change management capabilities to help
                                                                                 and
   manage the policy lifecycle, which can include staging, optimization, testing an rollback.

   Policy Validation
                                        For policy governance to be effective, it is essential that policy compliance be
   XML gateways are                                                               time
                                        validated at runtime. This requires real-time monitoring of service behavior for
quickly emerging as the                 conformance to policy. For policies related to identity, security and data structure,
     policy runtime                     monitoring data pulled from a policy enforcement product, (such as an XML
  enforcement point of                  firewall or gateway) is usually sufficient to test policy compliance. For policies that
 choice, providing real-                deal with availability and/or performance, it may also be necessary to pull health
   time monitoring of                   information from a service directly using server-side agents.
  service behavior for
 conformance to policy                gateways                                   o
                                 XML gatewa should allow administrators to define remediation policies for
                                                                                                             conditions).
                                 specific violations (i.e., create branching policies for specific violation conditions)
   Best-of-breed gateways can also check for policy violations and automatically adjust policy based on data pulled
   from Web services management agents or other policy enforcement products. The ability to define, enforce and
   monitor/report on any combination of policy, violation and remediation provides organizations total flexibility in
                       ng            rules.
   defining and enforcing governance rules


   Overcoming Implementation Challenges
       Way
   Two-Way Trust and Federated Identity
                                                                                              machine-to
   SOA governance is impossible without an effective identity and trust foundation. For machine to-machine-based
   SOA interactions, both actors in a transaction must have certifiable proof of identity to establish trust. In practical
                                                        two-way trust can be established using a Public Key Infrastructure
                                   terms, this kind of two
  Resolving the mis-               (PKI) based relationship between a digitally certified consumer and service provider.
   matched policies,               For a service to trust a client’s identity requires every service consumer to clearly
 security settings and             establish its identity in a certifiable and non-repudiating way to every service
  transport protocols              provider. Reciprocally, every service consumer will have to authenticate a service
    typical in cross-              provider’s identity by validating its certification credentials. In scenarios where the
domain Web Services-                                        service
                                   service consumer and service provider lie in the same identity domain, this task is
based integrations re-             typically simplified by a common identity directory that validates credentials.
   mains problematic               However, in scenarios where service consumers and providers lie in different identity
                                   domains, this task is complicated by the fact that no common identity store exists. In
   these scenarios, an SOA governance framework must be able to establish trust across identity domains so that an
   identity certified in one domain can be trusted in another. This kind of transitive trust depends in practice on the
   ability of a service provider to establish trust with an identity validation intermediate that lies in the consumer’s
   domain, and for that intermediate to be able to electronically vouch for the identity of the consumer.
                                            ogies
            Copyright © 2010 Layer 7 Technologies Inc. All rights reserved. SecureSpan and the Layer 7 Technologies design mark are
            trademarks of Layer 7 Technologies Inc. All other trademarks and copyrights are the property of their respective owners.
                                                                                yrights                                                5
  Runtime SOA Governance



  Therefore, any framework for governing trust between an SOA consumer and provider must include not only a
  mechanism for certifying and authenticating an i identity inside a single domain, but also between federated
                                                    (STS)
  domains. While PKI and Security Token Services (STS) can help establish trust, problems arise when policies,
  security settings, transports, etc. diverge between domains.

  Client Policies and Policy Negotiation
  When SOA governance must be administered across organizational boundaries, the problem of how to
                                   side
  accommodate divergent client-side policies sometimes arises. Different security or administrative domains may
  adhere to different sets of rules under which their applications are allowed to operate. In the case of client
  applications, these rules prescribe how clients can behave when accessing a service.

  These policies may prescribe what standards can be supported; which cryptographic settings are required; which
                                                                                         examples).
  transports are available, or what transactional responses are expected (to give some examples). When these
  settings diverge from policies prescribed on the service, there is only one mechanism available to reconcile
  differences: policy negotiation. Therefore, SOA actors or their proxies will need the ability to support runtime
                                       cross-organization                                            browser
  policy negotiation to accommodate cross organization transactions. Using traditional VPN and browser-server
  negotiation as a model, what’s required is an XML VPN client that has the capability to negotiate security and
                                                               the
  policy settings with an XML gateway. When combined with the XML gateway’s ability to establish trust and
  reconcile identity differences, the VPN client enables data exchange across domains requiring different security
  clearance levels.

  Distributed Policy Enforcement
                                                                                                    for
                                  In many instances, SOA intermediaries will share responsibility for policy enforcement
 An XML VPN client                          Web
                                  with the W service. For example, an intermediary such as an XML gateway may be
    can negotiate                 responsible for certain security and data operations (including data translation, schema
 security and policy                                          protection),              stream
                                  validation and XML threat protection while down-stream services may retain
  settings with its                                                      authorization.
                                  responsibility for authentication and authorization. Or an XML gateway may perform
                                        level
                                  first-level authentication on the identity of a requestor, with a downstream service
corresponding XML
                                                                             role-based definition in a Security Assertion
                                  responsible for authentication using the role
  gateway across
                                  Markup Language (                                 stance,
                                                      (SAML) attribute. In either instance, there will be a requirement for
domains in a manner                                                                    points
                                  coordinating policy operations across service end-points and intermediaries to ensure
 similar to VPN and               key policy operations are performed in a secure sequence, and to avoid unnecessary
   browser/server                                                                                      points
                                  redundancy. Effective policy enforcement across distributed end-points will therefore
     negotiation                  require coordination of policy provisioning, enforcement and tracking across multiple,
                                               end-points.
                                  distributed end


  Summary
  SOA Governance requires processes and products for controlling service assets at both design time and runtime.
                                                developer-centric
  While several tools exist for regimenting the developer centric process of governing a service asset at design time,
  the runtime problem is complicated by the distributed and federated nature of SOA. XML gateways are emerging
                   ry
  as the intermediary of choice for enforcing policy instructions on behalf of services and clients, as well as for
  providing a compliance reporting and testing environment for validating correct policy execution. The result is a
  complete environment for defining, enforcing and validating runtime SOA Governance policy.




                                           ogies
           Copyright © 2010 Layer 7 Technologies Inc. All rights reserved. SecureSpan and the Layer 7 Technologies design mark are
           trademarks of Layer 7 Technologies Inc. All other trademarks and copyrights are the property of their respective owners.
                                                                               yrights                                                6
Runtime SOA Governance


About Layer 7 Technologies
With offices in San Mateo, California; New York, New York; and Vancouver, British Columbia, Canada; Layer 7
                                                      cost-effective business integration using XML and Web
Technologies helps enterprises accomplish secure and cost
services. Layer 7 Technologies’ SecureSpan™ Solution is the first technology that addresses security and
governance across a Web services integration without expensive and inflexible programming. With the
SecureSpan™ Solution, customers realize lowered integration costs, increased security reliability, and the ability to
future-proof their Web services investments. Contact Layer 7 Technologies or visit www.layer7tech.com for more
information.


                Technologies
Contact Layer 7 Technologi
Layer 7 Technologies welcomes your questions, comments, and general feedback.

Email:
info@layer7tech.com

Web Site:
www.layer7tech.com

Phone:
604-681-9377
1-800-681-9377 (toll free)

Fax:
604-681-9387

Address:
US Office
1200 G Street, NW, Suite 800
Washington, DC 20005

Canada Office
Suite 405-1100 Melville Street
Vancouver, BC
V6E 4A6 Canada


Legal Information
Copyright © 2010 by Layer 7 Technologies, Inc. (www.layer7tech.com). Contents confidential. All rights reserved.
SecureSpan™ is a registered trademark of Layer 7 Technologies, Inc. All other mentioned trade names and/or
                                                owners.
trademarks are the property of their respective owne




                                         ogies
         Copyright © 2010 Layer 7 Technologies Inc. All rights reserved. SecureSpan and the Layer 7 Technologies design mark are
         trademarks of Layer 7 Technologies Inc. All other trademarks and copyrights are the property of their respective owners.
                                                                             yrights                                                7