Your Federal Quarterly Tax Payments are due April 15th Get Help Now >>

SOA Governance by NiceTime




Runtime SOA Governance

Runtime SOA Governance

Table of Contents 

Executive Summary ................................................................................ 3
Design‐time SOA Governance ............................................................. 3
Runtime SOA Governance Requirements ......................................... 4
Policy .................................................................................................................... 4
Policy Lifecycle Management ........................................................................... 5
Overcoming Implementation Challenges with SecureSpan.......... 7
2‐Way Trust and Federated Identity................................................................ 7
Client Policies and Policy Negotiation ............................................................ 7
Distributed Policy Enforcement Across Intermediaries and Services ........ 8
SOA governance, A Summary.............................................................. 8 

                                                                                                                                Page 2 of 8
Runtime SOA Governance


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 business processes can be defined, on‐demand to create business agility.    
However,  SOA  is  predicated  on  an  ability  to  integrate,  just‐in‐time,  loosely‐coupled  services,  one 
application to another. Users may or may not be involved. This creates challenges for governing how 
service  assets  get  developed,  provisioned  and  invoked.  For  developers  of  service  assets,  governance 
amounts  to  the  process  and  policy  describing  how  services  get  built,  registered,  changed  and 
discovered.  For  operators  of  SOAs,  governance  becomes  a  matter  of  how  policies  describing  how  a 
service  behaves  when  it  is  called  gets  defined,  enforced  and  validated  at  runtime.  This  Whitepaper 
examines  the  considerations  involved  in  implementing  a  SOA  governance  framework  at  both  design 
time and runtime and the role of runtime policy definition, enforcement and validation products from 
Layer 7. 

Design‐time  SOA  governance  begins  with  control  over  how  services  (specifically  service  APIs)  get 
created,  registered,  changed  and  discovered.  In  most  cases  service  API’s  are  published  as  a  WSDL 
(Web  Service  Description  Language)  formatted  XML  document.  While  this  greatly  simplifyies  the 
process  of  building  client  applicatons  that  can  consume  a  service’s  business  logic,  it  also  creates 
security  and  lifecycle  issues  since  WSDL  does  not  provide  integrated  access  or  revision  management 
To  govern  the  developer‐centric  service  creation  and  lifecycle  process,  it  is  necessary  to  provide  a 
centralized  check‐in,  check‐out  mechanism  for  service  developers  and  a  commensurate  WSDL 
discovery  and    access  control  system  for  client  developers.  Underpinning  both  is  a  registry  where 
WSDL’s can be published to and discovered from. In most cases the registry will be a UDDI repository 
with  distributed  sychronization  for  added  redundancy  and  scalability  (automatic  with  UDDI  v3). 
Altenratively  a  flat  file  database  with  distributed  synchronization  can  be  used.  The  decision  over 
whether  to  use  a  UDDI  registry  or  database  comes  down  to  whether  the  end‐users  prefers 
centralization  of  WSDL  pointers  (UDDI)  or  WSDL  files  (database).  An  ideal  design  time  SOA 
governance  solution  will  support  either  option  and  multiple  vendors  of  registry  (UDDI  registries  are 
available  from  vendors  like  Microsoft,  IBM,  Oracle,  BEA,  Infravio  and  Mercury  Interactive’s  Systinet 
Once a registry decision has been made, a service check‐in, check‐out mechansim is required to manage 
service  publication  and  revisions.  Like  source  code  registration  tools,  the  check‐in,  check‐out 
mechansim  must  provide  an  ability  for  service  developer  to  designate  metadata  like  WSDL  owner, 
revision  history,  searcheable  annotations  and  associated  policy  document  (describing  runtime  access 

                                                                                                      Page 3 of 8
Runtime SOA Governance

and behavior preferences – see next section). It must also provide approval processes for WSDL check‐
out and check‐in based on a publisher’s or requestor’s identity, email request or IP range. At check‐in 
there  should  also  be  a  conformance  checker  to  test  a  new  WSDL’s  conformance  with  old  or  related 
While  client  developers  don’t  require  check‐in  mechanisms  for  WSDL’s  they  do  require  their  own 
check‐out controls to ensure design‐time access control. These access controls should include requstor’s 
identity,  credentials, IP range,  and /  or  email  request  /  approval.  To  make disovery  simpler  for client 
developers,  WSDLs  should  be  searcheable  based  on  WSDL  description  or  associated  metadata  like 
owner,  revision  history,  annotations  or  policy  preferences.  Service  registry  vendors  Systinet  and 
Infravio  registry  support  some  level  of  design  time  policy  definition  for  describing  when  and  under 
what terms a particular WSDL can be accessed. Both vendors are Layer 7 partners. 
For end‐users looking for added security or enhanced life‐cycle control an XML Gateway product like 
Layer  7’s  SecureSpan  Gateway  can  be  employed.  The  SecureSpan  Gateway  can  provide  API  level 
control  and  virtualization  functions  like  identity  based  access  control,  SLA  based  routing  of  requests 
across multiple backend UDDI’s and WSDL stores and accelerated WSDL  remapping so that API’s can 
be  personalized  to  a  requestor’s  entitlements.  The  SecureSpan  Gateway  also  allows  code‐free 
generation of  WSDL  API’s  based  on  a  non‐SOAP  XML  schema  or  sub‐operations  inside  one  or  more 
already defined service.  


Policy description and control lies at the heart of runtime SOA governance. Policy is a prescription for 
describing    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 and the service’s subsequent behavior when the client invokes it. While there is 
currently  no  universally  accepted  standard  for  expressing  a  SOA  policy  two  emerging  standards 
initiatives are endeavoring to normalize the expression of access policies specifically and service policy 
more broadly. XACML 2.0 (Extensible Access Control Markup Language) defines an XML schema for 
expressing  authorization  and  entitlements  information  to  resources  including  hierarchical  resources 
like XML documents. WS‐Policy, currently a specification put forth by IBM, Microsoft, SAP, BEA and 
Verisign, endeavors to describe how to express access as well as behavior constraints and 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  SOA  governance  framework  should  accommodate  both  standards  for 
describing  policy.  This  will  ensure  future  integration  and  interoperability  with  existing  access  and 
application platforms. 

                                                                                                          Page 4 of 8
Runtime SOA Governance

Policy Lifecycle Management   
Policy Definition  
Defining SOA policy for both runtime access and behavior control requires an ability to author policy 
declaratively. Otherwise policy consistency and compliance can never be guaranteed. Since SOA policy 
must describe both 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  mitigation  preferences,  message  routing  and  transformation  expectations, 
SLA terms, transport and reliability conditions, protocol support and industry specific preferences like 
content rights management and redaction or transaction audibility and non‐repudiation.  
To allow for industry and company specificity any policy authoring environment must 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  exiting  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,  logical  condition, ..). 
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  external  policy 
stores and repositories (that can include access systems, compliance products, management solutions, 
application platforms, UDDI), versioning control and collaborative workflow for managing distributed 
policy authoring and approval processes.    
To ease administration of runtime service access and behavior, Layer 7 provides a sophisticated policy 
editor  and  analysis  product  called  the  SecureSpan  Manager.  The  SecureSpan  Manager  allows 
administrators and business analysts to define runtime policies on a service, operation or client identity 
level.  The  SecureSpan  Manager  also  supports  advanced  policy  composition  functions  so  that  service 
behavior can be conditioned to very precise identity, message content, latency and service availability 
parameters.  Compound  policies  can  also  be  conditioned  to  branch  based  cached  parameter  values, 
runtime events (like management alert) or SLA satisfaction.    
Policy Enforcement 
Once  Policy  is  defined  it  needs to  be  provisioned  directly  to  enforcement  and  application  points  in  a 
SOA or published to a registry alongside a WSDL for later look‐up. Policy application points are client 
applications that require policy configuration to successfully access a service . SOA enforcement points 
are  service  endpoints  and  intermediates  like  XML  Firewalls  and  Gateways  (like  the  SecureSpan 
Gateway) 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  policy:  client 
applications,  intermediaries  and  service  endpoints,  are  equiped  to  consume  and  execute  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.  
Assuming  the  SOA  endpoints  either  natively  or  by  way  of  an  agent  have  the  ability  to  accept  and 
process  a  policy  instructions  there  remain  security,  performance  and  change  management  issues 

                                                                                                        Page 5 of 8
Runtime SOA Governance

emanating  from  the  practical  deployement  of  policy  to  distributed  points  in  an  SOA.  Policies  on 
different  SOA  actors  can  conflict  or  overlap.  Policies  may  need  to  be  staged,  optimized  for 
performance,  production  tested  and  rolled  back  when  issues  arise.  To  properly  manage  provisioning 
and enforcement therefore requires a policy deployment and enforcement infrastruture that can control 
the whole production lifecycle of pushing a policy to a SOA actor or intermediary (i.e. and enforcement 
Today most SOA platforms are not natively equiped to consume runtime policy instructions written in 
either  XACML  2.0  or  WS‐Policy.  For  that  reason,  most  end‐users  contemplating  deploying  a  runtime 
policy enforcement infrastuture will depend on the use of intermediaries.  
In this regard Layer 7 is unique in offering a broad array of intermediaries that can address end‐to‐end 
SOA policy enforcement requirements. For end‐users looking to enforce runtime policy decisions in an 
application oriented networking device, Layer 7 offers one of the most advanced XML Gateway in the 
market.  Available  as  software,  blade  or  64‐bit  appliance  with  onboard  XML  processing  silicon,  the 
SecureSpan Gateway can enforce diverse security, routing, transformation and SLA policy definition in 
a  high‐availability,  high‐throughput,  high‐scalability  device.  For  end‐users  needing  to  enforce  policy 
directly  on  service  endpoints  (application  servers  and  applications)  Layer  7  also  offers  “last‐mile” 
service  agent  software.  The  agent  software  can  consume  security  credentials  (like  SAML  tokens)  and 
enforce  all  policy  directly  on  the  end‐point.  Alternatively,  the  service  agent  can  be  configured  to 
cooperate  with  another  policy  enforcement  point  like  the  SecureSpan  Gateway  to  enforce  only  the 
subset of policy appropriate for some end‐point services like authorization decisions.  
In addition to the SecureSpan Gateway and Service Agent, Layer 7 also offers end‐users the option of 
deploying first‐mile policy application software. Called the SecureSpan Bridge, the software automates 
connectivity between departments and portals with backend Web services. Operating like a browser or 
XML VPN analogue, the SecurSpan Bridge consumes identity and policy requirements from a backend 
Web  service.  This  process  makes  identity  and  security  provisioning  and  change  between  client 
applications and services spanning securiy and identity domains easier to implement.  
Policy Validation  
For policy governance to be effective it is essential that policy compliance be validated at runtime.  This 
requires  real‐time  monitoring  of  service  behavior  for  conformance  to  policy.  For  policies  related  to 
identity,  security  and  data  structure,  monitoring  data  pulled  from  a  policy  enforcement  product  like 
Layer 7’s SecureSpan Gateway is usually sufficient to test policy compliance. For policies that deal with 
availability  and  /  or  performance  it  may  also  be  necessary  to  pull  health  information  from  a  service 
directly.  Several  Web  servics  management  products  provide  service  agents  that  can  provide  this 
By using  data  pulled from a Web services management agent  or  policy  enforcement product  like the 
SecureSpan Gateway, Layer 7 can check for policy violations and automatically adjust policy. Unqiue 
among  policy  governance  products,  Layer  7’s  Policy  Manager  allows  administrators  to  define 
remediation  policies  for  specific  violations  (i.e.  branched  policies  conditioned  to  specific  violation 
conditions).  The  ability  to  define  any  combination  of  policy,  violation  and  remediation  in  the 
SecureSpan Manager and have the resulting conditional policies executed in the SecureSpan Gateway, 

                                                                                                        Page 6 of 8
Runtime SOA Governance

last‐mile agent or Bridge provides architects total flexibility in defining and enforcing governance rules. 
Monitoring and Reporting of compliance information is provided through the a dedicated monitoring 
and compliance screen in the SecureSpan Manager.  


2‐Way Trust and Federated Identity 
SOA  governance  is  impossible  without  an  effective  identity  and  trust  foundation.  For  a  machine‐to‐
machine  based  SOA  interaction  both  actors  in  a  transaction  must  have  certifiable  proof  of  identity  to 
establish  trust.  In  practical  terms  this  kind  of  2‐way  trust  can  be  established  using  a  PKI  based 
relationships  between  a  digitally  certified  consumer  and  service  provider.  For  a  service  to  trust  a 
client’s  identity  requires  every  service  consumer  to  clearly  establish  it’s  identity  in  a  certifiable  and 
non‐reputable  way  to  every  service  provider.  Reciprocally,  every  service  consumer  will  have  to 
authenticate a service provider’s identity by validating its identity certification credentials. In scenarios 
where  the  service  consumer  and  service  provider  lie  in  the  same  identity  domain  this  task  is  made 
simple  because  a  common  identity  directory  will  typically  exist  to  validate  identity  credentials. 
However in scenarios where service consumers and providers lie in different identity domains this task 
is  complicated  since  no  common  identity  store  will  exist.  In  these  scenarios,  a  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.  
Therefore any framework for governing trust between a SOA consumer and provider must include not 
only a mechanism for certifying and authenticating an identity inside a single domain but also between 
federated  domains.  Layer  7  achieves  this  through  identity  and  PKI  coordination  between  the 
SecureSpan Gateway and Bridge. The SecureSpan Bridge can provision and register a digital certificate 
from  a  CA  bundled  inside  the  SecureSpan  Gateway  or  integrated  with  the  Gateway  (like  Verisign). 
Once trust is established the Bridge can then federate identity between the trusted domains leveraging 
either  the  SecureSpan  Gateway’s  onboard  SAML  based  Security  Token  Service  or  an  external  token 
service provided by vendors like CA, IBM Tivoli or Microsoft.  

Client Policies and Policy Negotiation 
When  SOA  governance  must  be  administered  across  organizational  boundaries  there  is  sometimes  a 
problem  of  how  to  accommodate  divergent  client  side  policies.  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,  what  cryptographic  settings  are 
required,  what  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 

                                                                                                           Page 7 of 8
Runtime SOA Governance

will  need  the  ability  to  support  runtime  policy  negotiation  to  accommodate  cross‐organization 
transactions.    For  that  reason,  Layer  7  has  built  into  its  SecureSpan  Bridge  the  capability  to  negotiate 
security and policy settings with the SecureSpan Gateway in manner analogous to VPN and Browser‐
Server  negotiation.  When  combined  with  the  SecureSpan’s  ability  to  establish  trust  and  reconcile 
identity  differences,  this  function  enables  data  exchange  across  domains  requiring  different  security 
clearance levels as is common in the defense and intelligence communities.  

Distributed Policy Enforcement Across Intermediaries and Services 
In  many  instances  SOA  intermediaries  will  share  responsibility  for  policy  enforcement  with  service 
endpoints.  An  intermediary  like  an  XML  Firewall  may  be  responsible  for  certain  security  and  data 
operations  like  data  translation;  schema  validation  and  XML  threat  protection,  while  downstream 
services will retain responsibility for authentication and authorization for example. Or an XML Firewall 
may  perform  first  level  authentication  on  the  identity  of  a  requestor  with  a  downstream  service 
performing an authentication based on a role based definition in a SAML attribute.  In either instance 
there  will  be  a  requirement  for  coordinating  policy  operations  across  service  endpoints  and 
intermediaries  to  ensure  key  policy  operations  are  performed  in  a  secure  sequence  and  to  avoid 
unnecessary  redundancy.  Effective  coordination  of  policy  enforcement  across  distributed  endpoints 
will therefore require policy provisioning and enforcement that can track policy implementation across 
multiple,  distributed  endpoints.  Layer  7  is  unique  in  providing  administrators  the  ability  to  set  and 
define this capability through the SecureSpan Manager.  

SOA  Governance  requires  process  and  product  for  controlling  service  assets  at  both  design  time  and 
runtime. 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.  For  that  reason  Layer  7  has  introduced  a  set  of  products  for  providing  a  runtime  policy 
production environment, a set of intermediates that can enforce policy instructions on behalf of service 
end‐points  and  clients,  and  lastly  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.  

                                                                                                            Page 8 of 8

To top