Automating Deployment Configuration of Web Services Security

1
Automating Deployment Configuration of Web
Services Security

• C.Chung, B.Falchuk, J.Micallef
• presenter
• DIMACS Workshop on Security of Web Services and
  E-Commerce
• May 5-6, 2005
• Rutgers University

2
Outline

• Motivation
• Background
• Web Service Gateway
• Ontology
• Initial Results

3
Motivating Scenario
4
Services Design and Deployment
our focus is the set of non-functional reqmts

• Decouple Service Design from Deployment
  Configuration
• Automate deployment-time configuration of
  Infrastructure to meet service requirements
• Can Web Services X,Y,Z be supported on the
  Infrastructure?

5
Web Services Deployment Configuration

• Configurable at deployment time
• Security
• Transport e.g. bindings (HTTP vs JMS)
• Reliability e.g. Message Delivery (e.g. at
  least once)
• The deployment configuration becomes harder to
  manage with increased (1) number of Web Services
  increases, or increased (2) requirements
  sophistication
• No standard schema yet captures non-functional
  artifacts
• Without rich semantic underpinnings, the
  brokering and reasoning required to perform
  configurations, is somewhat hobbled

6
Semantic Web

• Motivation the meaning of Web content is not
  machine-accessible
• Ontology Web Language (OWL) is a W3C
  Recommendation
• Is a key part of the realization of Tim
  Berners-Lees vision of the Semantic Web
• Roots are in RDF, DAMLOIL (DARPA), Logics
• OWL goes beyond expressive capabilities of XML
  Schema, RDF, RDF-S (e.g. class intersection)
• Ontology
• A shared understanding of a domain
• Capture classes, properties, restrictions,
  disjointedness, relationships, instances, etc.
• Used for organizing, improving search accuracy,
  detecting inconsistencies, etc.
• e.g. OpenCyc (47000 upper concepts), US Military,
  Medical, ..

7
Semantic Web

• OWL ontologies admit to formal representation in
  Description Logics (allowing for logic engines)
• OWL (Java) APIs make certain types of inference
  accessible
• Consistency is asserted instance A consistent
  with ontology?
• Classification is instance A a type of Class C?
• Subsumption Reasoning is the asserted instance
  A related to B through the subtype tree?
• Heuristic rules
• OWL Tools and Support are emerging
• Stanford Universitys Protégé ontology Editor
• Several Java OWL APIs
• A formal rules language (SWRL) is emerging
• Logic Engines (e.g. Racer)

8
Solution Approach Underpinnings
Service Consumers
Wizard Reasoner
Knowledge Base
HP Jena API
W3C OWL
9
Configurable Security

• Goals for Web Services Security
• End-to-end security in multi-party SOA
  environment
• Interoperability, performance, manageability

Service Provider
Indirect Service Provider
Service Consumer
10
Gateway Approach

• Gateways main functions
• Encapsulates (virtualizes) backend Web Services
• Enables reconfigurable security by applying
  policies
• also configurable load balancing, versioning,
  transport, reliability
• WS-Security (OASIS standard, Apr 04) enables
• Endpoint-to-endpoint message integrity and
  confidentiality
• Selective encryption of sensitive data
• Selective digital signing of critical data
• Benefits
• Simplifies security management
• Centralizes security policies for a trust domain
• Enables modular, adaptable infrastructure (via
  gateway reconfiguration)
• Decouples the Gateway platform from that of Web
  Services

11
WS Security Gateway
Consumers access a virtual endpoint

• Maps Gateway service endpoints to
  Gateway-managed service endpoints, and vice versa
• Uses WS-Addressing and WS-Referral

• Associates policies with Gateway service
  endpoints
• Enforces policies on service invocation
• Uses WS-Security, WS-Policy, and
  WS-SecurityPolicy

12
WS Security Gateway Configuration
Trust Domain

Service Order
Manage My Features (non-secure)
WS Gateway
Billing
Policy
Update Voice Features
Router
Gateway Configuration Web Service
13
Automating Gateway Configuration
Trust Domain
Service
Service
Service

• Configuration Interface of the Web Services
  Gateway
• Exposes a Web Service that enables Reasoner to
  query the non-functional capabilities of this
  Gateway in OWL format
• Exposes a Web Service that enables Reasoner to
  reconfigure the Gateways behavior
• Activate/deactivate Policy X for Web Service Y

14
Gateway Internals
Service Consumer

• Leverages Microsoft Web Services Enhancements
  (WSE) 2.0 capabilities
• WSE Filter Pipeline architecture to verify
  security policies
• Extends WSE Framework to perform routing
• Policies can be either built-in or custom
• signing and encryption are built-in
• custom policies extend the PolicyAssertion class

filter
Filters
router
affected by calls upon Configuration Interface
filter
Service
15
Ontology Design Approach

• Rather than focusing on models of message
  payloads, we focus on
• Artifacts in the infrastructure
• Security gateways, their capabilities,
  interconnected-ness, etc.
• Non-functional qualities
• QoS, Security, Reliability, Messaging, etc.
• Some related work is re-usable
• IBM an OWL ontology for QoS (metrics,
  measurements..)
• Carnegie Mellon ontology capturing the
  artifacts described in the W3C Web services
  architecture
• Specifications (e.g. WS-Reliability, WS-Security)
  contain rich (English) descriptions of important
  artifacts
• Our ontology is the result of (1) modeling new
  artifacts, (2) inclusion of artifacts from
  existing models
• Such re-use and extension is supported and
  encouraged by ontology practitioners

16
Ontology
Classes..
Protégé
Properties..
Trust_Domain consists of 0 or more Intermediaries
Security_GW is an Intermediary
Encryption artifacts
Authentication artifacts
17
Simple Object Property ltowlObjectProperty
rdfID"td_supports_security_cap"gt
ltprotegeallowedParent rdfresource"Security_Cap
ability"/gt ltrdfsdomain rdfresource"Trust_D
omain"/gt ltrdfsrange rdfresource"http//www.
w3.org/2002/07/owlClass"/gt lt/owlObjectProperty
gt
A Trust_domain is composed of Intermediaries (and
Intranet, devices, ..)
An Intermediary has messaging and security
capabilities. It supports Services
18
Reasoning for Service Deployment Configuration

• Objectives
• Match Service requirements to Infrastructure
  capabilities
• Analyze infrastructure for inconsistencies
• Several well-applied approaches
• Matching, pruning approach via a broker Sycara
  et al., 2004
• Heuristics for good matches Li et al, 2003
  Sycara et al., 2003
• Efficiency and accuracy via post-match filtering
  Ludwig et al, 2002
• Other approaches using logics and full-blown
  reasoners
• Degree of match
• Exact Match (matches exactly)
• Subsumption Match (matches more generally)
• Plugin Match (matches more specifically)
• Others Reverse Subsumption, Partial,
  Re-formulation Matches

19
Reasoner Algorithm

• Determining if the infrastructure support service
  X (and all its requirements) relies largely on
  recursively
• Decomposing assertions into fundamental parts
• Classifying parts
• Checking for satisfiability/consistency
• Matchmaking on requirements and capabilities
• degrees of match plug-in (more specific),
  subsumption (more general), exact

20
Two Use-Cases

• Service X requires a Kerberos-style encryption.
  Can the Infrastructure support X?
• Deployment Admin selects the Configure Security
  option
• Reasoner applies heuristics
• GW has declared Kerberos_v5 capability
• Reasoner applies subsumption heuristic Kerberos
  satisfies Kerberos_v5 more generally
• Reasoner concludes that X is satisfiable
• Reasoner invokes the Gateways Configuration Web
  Service as necessary
• Multiple security policies need to be enabled for
  Service X on the Security Gateway. What is their
  ordering?
• Reasoner applies heuristics to reduce the
  probability of incompatible security policy
  ordering
• e.g. Decryption must happen before content can be
  filtered
• Reasoner invokes the Gateways Configuration Web
  Service as necessary

21
Result Sample System Trace
reasonerImpl Testing if reqmt Kerberos can be
met on the GW.. reasonerImpl Reqmt Kerberos
NOT met by exact GW capability X509 reasonerImpl
Reqmt Kerberos NOT met by more general GW
capability Authentication_Security_Capability reas
onerImpl Reqmt Kerberos NOT met by exact GW
capability SecurID reasonerImpl Reqmt
Kerberos NOT met by more general GW capability
Authentication_Security_Capability reasonerImpl
Reqmt Kerberos NOT met by exact GW capability
MD5 reasonerImpl Reqmt Kerberos NOT met by
more general GW capability Encryption_Security_Cap
ability reasonerImpl Reqmt Kerberos NOT met
by exact GW capability DAC reasonerImpl
Reqmt Kerberos NOT met by more general GW
capability Encryption_Security_Capability reasoner
Impl Reqmt Kerberos NOT met by exact GW
capability CRAM_MD5 reasonerImpl Reqmt
Kerberos NOT met by more general GW capability
Authentication_Security_Capability reasonerImpl
Reqmt Kerberos NOT met by exact GW capability
RC2 reasonerImpl Reqmt Kerberos NOT met by
more general GW capability Encryption_Security_Cap
ability reasonerImpl Reqmt Kerberos NOT met
by exact GW capability Microsoft_Windows reasonerI
mpl Reqmt Kerberos NOT met by more general
GW capability Authentication_Security_Capability r
easonerImpl Reqmt Kerberos NOT met by exact
GW capability Kerberos_v5 reasonerImpl
Reqmt Kerberos met by more general GW capability
Kerberos reasonerImpl Testing if reqmt Kerberos
can be met on the TD.. reasonerImpl Reqmt
Kerberos NOT met by exact TD capability
Kerberos_v5 reasonerImpl Reqmt Kerberos
met by more general TD capability
Kerberos reasonerImpl Summary reasonerImpl
Kerberos reasonerImpl Calling out to GW with
the following reasonerImpl (http//www.telcordi
a.com/services/billing,Kerberos,true)
Subsumption replacement
service asks only for general Kerberos support,
the infrastructure supports a level equal to or
more specific than what was requested
22
From the Admins Point-of-View
23
Conclusions and Future Work

• Conclusions
• Deployment configuration of Enterprise-grade Web
  Service based solutions is hard
• When there are a large number of services to
  manage
• When non-functional service requirements
  complexity is high
• Commercial tools exist for several aspects of Web
  Service management but richer, logics-based
  configuration is not yet there
• Thus far no COTS makes systematic use of
  semantically rich languages
• Future Work
• Implementation beyond security aspects of the
  infrastructure
• Messaging (e.g. delivery guarantees, topic
  spaces, etc)
• Consider dynamically changing non-functional
  requirements and capabilities (as opposed to
  deployment time)

24
Thank you.