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
Outline
 Motivation
 Background
 Web
Service Gateway
 Ontology
 Initial Results
DIMACS (Chung, Falchuk, Micallef) – 2
Motivating Scenario
Joe’s Telco
Customer
Portal
ACME Communications
ACME
Customer
Portal
Activation
Billing
Service
Ordering
Network4Sale
Inventory
Inventory
PAY Online
Billing
DIMACS (Chung, Falchuk, Micallef) – 3
Services Design and Deployment
Joe’s Telco
Customer
Portal
ACME Communications
ACME
Customer
Portal
Activation
Billing
Service
Ordering
Inventory
Network4Sale
Inventory
Service
Designer
PAY Online
Billing
Requirements,
Functional & non-functional
constraints
service requirements
Deployment
Administrator
Infrastructure
Capabilities,
capabilities
constraints
* our focus is the set of non-functional req’mts


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?
DIMACS (Chung, Falchuk, Micallef) – 4
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
DIMACS (Chung, Falchuk, Micallef) – 5
Semantic Web
Semantic Web “stack”
–
–
–

Is a key part of the realization of Tim Berners-Lee’s vision
of the
Proof
Semantic Web
Logic Framework
Roots are in RDF, DAML+OIL (DARPA), Logics
Rules
OWL goes beyond expressive capabilities of XML Schema, RDF,
Ontology
RDF-S (e.g. class intersection)
Ontology:
–
–
–
–
RDF Schema
Signature

Motivation: the meaning of Web content is not machine-accessible
Ontology Web Language (OWL) is a W3C Recommendation
Trust
Encryption

RDF
A shared understanding of a domain
Capture: classes, properties, restrictions,XML
disjointedness,
Namespaces
relationships, instances, etc.
URI
Unicode
Used for: organizing, improving search accuracy, detecting
inconsistencies, etc.
e.g. OpenCyc (47000 upper concepts), US Military, Medical, ..
DIMACS (Chung, Falchuk, Micallef) – 6
Semantic Web

OWL ontologies admit to formal representation in Description Logics
(allowing for logic engines)

OWL (Java) API’s 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 University’s Protégé ontology Editor
Several Java OWL API’s
A formal rules language (SWRL) is emerging
Logic Engines (e.g. Racer)
DIMACS (Chung, Falchuk, Micallef) – 7
Solution Approach &
Underpinnings
Service
Designer
Ontology
Creation
existing
ontologies
Stanford
Protégé
Deployment
Administrator
Wizard +
Reasoner
HP
Jena API
Knowledge
Base
Service Consumers
Web Services
Gateway
WSE
W3C
OWL
DIMACS (Chung, Falchuk, Micallef) – 8
Configurable Security

Goals for Web Services Security
–
–
End-to-end security in multi-party SOA environment
Interoperability, performance, manageability
Service
Consumer
Transport level security
Service
Provider
Indirect
Service
Provider
Message level security
DIMACS (Chung, Falchuk, Micallef) – 9
Gateway Approach
 Gateway’s
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
–
DIMACS (Chung, Falchuk, Micallef) – 10
WS Security Gateway
Trust Domain
Service
Consumer
Service
WS Gateway
Service
…
Policy
Service
Consumer
Router
Consumers access a
‘virtual’ endpoint
Service
• 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
DIMACS (Chung, Falchuk, Micallef) – 11
WS Security Gateway Configuration
Trust Domain
Service
Order
Manage
My Features
(non-secure)
WS Gateway
Billing
Policy
Manage
My Features
(secure)
…
Router
Gateway
Configuration
Web Service
Encryption
Authentication
Signature
Update
Voice
Features Encrypt (128)
UserPwd
Architecture
Reasoner
Service
Knowledge
Base
Deployment
Wizard
Metadata
(OWL)
(ontology +
instances)
Deployment
Admin
DIMACS (Chung, Falchuk, Micallef) – 12
Automating Gateway Configuration
Configuration
Interface
Trust Domain
Deployment
Service
Admin
Consumer
…
Wizard (servlets)
Ontology

Service
Consumer
Reasoner
Service
WS Gateway
Service
Policy
Router
Service
Configuration Interface of the Web Services Gateway
–
–
Exposes a Web Service that enables Reasoner to query the nonfunctional capabilities of this Gateway in OWL format
Exposes a Web Service that enables Reasoner to ‘reconfigure’ the
Gateway’s behavior

Activate/deactivate Policy {X} for Web Service {Y}
DIMACS (Chung, Falchuk, Micallef) – 13
Gateway Internals
Service
Consumer

Leverages Microsoft Web Services
Enhancements (WSE) 2.0 capabilities
– WSE Filter Pipeline architecture to
verify security policies
–
filter
Filters:

Trace
Security
router
Referral
Policy
Custom
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
affected by calls upon
Configuration Interface
filter
Service
DIMACS (Chung, Falchuk, Micallef) – 14
Ontology Design Approach

Rather than focusing on models of message payloads, we focus on:
–
Artifacts in the infrastructure

–
Non-functional qualities


QoS, Security, Reliability, Messaging, etc.
Some related work is re-usable
–
–
–

Security gateways, their capabilities, interconnected-ness, etc.
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
DIMACS (Chung, Falchuk, Micallef) – 15
Ontology
Protégé
Classes..
Properties..
Trust_Domain consists of 0
or more Intermediaries
Security_GW is an
Intermediary
Encryption
artifacts
Authentication
artifacts
DIMACS (Chung, Falchuk, Micallef) – 16
An Intermediary has
messaging and security
capabilities. It supports
Services
Simple Object Property
<owl:ObjectProperty rdf:ID="td_supports_security_cap">
<protege:allowedParent rdf:resource="#Security_Capability"/>
<rdfs:domain rdf:resource="#Trust_Domain"/>
<rdfs:range rdf:resource="http://www.w3.org/2002/07/owl#Class"/>
</owl:ObjectProperty>
A Trust_domain is
composed of
Intermediaries (and
Intranet, devices, ..)
DIMACS (Chung, Falchuk, Micallef) – 17
Reasoning for Service Deployment
Configuration

Objectives
–
–

Several well-applied approaches:
–
–
–
–

Match Service requirements to “Infrastructure” capabilities
Analyze infrastructure for inconsistencies
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
DIMACS (Chung, Falchuk, Micallef) – 18
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
DIMACS (Chung, Falchuk, Micallef) – 19
Two Use-Cases
1.
Service X requires a Kerberos-style encryption. Can the
Infrastructure support X?
1.
2.
Deployment Admin selects the “Configure Security” option
Reasoner applies heuristics
1.
2.
3.
3.
2.
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 Gateway’s Configuration Web Service as
necessary
Multiple security policies need to be enabled for Service X on
the Security Gateway. What is their ordering?
1.
Reasoner applies heuristics to reduce the probability of
incompatible security policy ordering

2.
e.g. Decryption must happen before content can be filtered
Reasoner invokes the Gateway’s Configuration Web Service as
necessary
DIMACS (Chung, Falchuk, Micallef) – 20
Result – Sample System Trace
reasonerImpl:
reasonerImpl:
reasonerImpl:
reasonerImpl:
reasonerImpl:
reasonerImpl:
reasonerImpl:
reasonerImpl:
reasonerImpl:
reasonerImpl:
reasonerImpl:
reasonerImpl:
reasonerImpl:
reasonerImpl:
reasonerImpl:
reasonerImpl:
reasonerImpl:
reasonerImpl:
reasonerImpl:
reasonerImpl:
reasonerImpl:
reasonerImpl:
Testing if reqmt Kerberos can be met on the GW..
Reqmt Kerberos NOT met by exact GW capability X509
Reqmt Kerberos NOT met by more general GW capability Authentication_Security_Capability
Reqmt Kerberos NOT met by exact GW capability SecurID
Reqmt Kerberos NOT met by more general GW capability Authentication_Security_Capability
Reqmt Kerberos NOT met by exact GW capability MD5
Reqmt Kerberos NOT met by more general GW capability Encryption_Security_Capability
Reqmt Kerberos NOT met by exact GW capability DAC
Reqmt Kerberos NOT met by more general GW capability Encryption_Security_Capability
Reqmt Kerberos NOT met by exact GW capability CRAM_MD5
Reqmt Kerberos NOT met by more general GW capability Authentication_Security_Capability
Reqmt Kerberos NOT met by exact GW capability RC2
Reqmt Kerberos NOT met by more general GW capability Encryption_Security_Capability
Reqmt Kerberos NOT met by exact GW capability Microsoft_Windows
Reqmt Kerberos NOT met by more general GW capability Authentication_Security_Capability
Reqmt Kerberos NOT met by exact GW capability Kerberos_v5
Reqmt Kerberos met by more general GW capability Kerberos
Testing if reqmt Kerberos can be met on the TD..
Reqmt Kerberos NOT met by exact TD capability Kerberos_v5
Reqmt Kerberos met by more general TD capability Kerberos
Summary:
Kerberos
reasonerImpl: Calling out to GW with the following:
reasonerImpl: (http://www.telcordia.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
DIMACS (Chung, Falchuk, Micallef) – 21
From the Admin’s Point-of-View
DIMACS (Chung, Falchuk, Micallef) – 22
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
–
Implementation beyond security aspects of the infrastructure

–
Work
Messaging (e.g. delivery guarantees, topic spaces, etc)
Consider dynamically changing non-functional requirements
and capabilities (as opposed to deployment time)
DIMACS (Chung, Falchuk, Micallef) – 23
Thank you.
Chit Chung
chit@research.telcordia.com
Ben Falchuk
bfalchuk@research.telcordia.com
Josephine Micallef
micallef@research.telcordia.com