Runtime SOA Governance

Report as inappropriate Your report has been received

Shared by: Layer7Tech

Stats

views:: 15
posted:: 8/19/2010
language:: English
pages:: 7

Attribution-NonCommercial

Document Sample

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.

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.

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.

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