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
DIMACS (Chung, Falchuk, Micallef) – 2
Outline
Motivation Background Web Service Gateway Ontology Initial Results
DIMACS (Chung, Falchuk, Micallef) – 3
Motivating Scenario
Joe’s Telco
CustomerPortal
ACME Communications
ServiceOrdering
Billing
Inventory
Activation
ACMECustomer
Portal
Network4Sale
Inventory
PAY Online
Billing
DIMACS (Chung, Falchuk, Micallef) – 4
Services Design and Deployment
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?
DeploymentAdministrator
Capabilities, constraintsCapabilities, constraints
Infrastructure capabilities
Joe’s Telco
CustomerPortal
ACME Communications
ServiceOrdering
Billing
Inventory
Activation
ACMECustomer
Portal
Network4Sale
Inventory
PAY Online
Billing
Requirements, constraints
Functional & non-functional service requirements
ServiceDesigner
* our focus is the set of non-functional req’mts
DIMACS (Chung, Falchuk, Micallef) – 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
DIMACS (Chung, Falchuk, Micallef) – 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-Lee’s vision of the Semantic Web
– Roots are in RDF, DAML+OIL (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, ..
URI Unicode
XML Namespaces
RDF
En
cry
pti
on
RDF Schema
Ontology
Rules
Logic Framework
Proof
Sig
natu
re
Trust
Semantic Web “stack”
DIMACS (Chung, Falchuk, Micallef) – 7
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) – 8
Solution Approach & Underpinnings
W3COWL
KnowledgeBase
StanfordProtégé
existingontologies
OntologyCreation
HPJena API
Wizard +Reasoner
WSE
Web ServicesGateway
DeploymentAdministrator
ServiceDesigner
Service Consumers
DIMACS (Chung, Falchuk, Micallef) – 9
Configurable Security
Goals for Web Services Security – End-to-end security in multi-party SOA environment– Interoperability, performance, manageability
ServiceConsumer
ServiceProvider
IndirectServiceProvider
Transport level securityTransport level security Message level securityMessage level security
DIMACS (Chung, Falchuk, Micallef) – 10
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) – 11
Trust Domain Trust DomainService
Consumer
ServiceConsumer
…WS Gateway
Policy
Router
Service
Service
Service
WS Security Gateway
• Associates policies with Gateway service endpoints• Enforces policies on service invocation• Uses WS-Security, WS-Policy, and WS-SecurityPolicy
• Maps Gateway service endpoints to Gateway-managed service endpoints, and vice versa• Uses WS-Addressing and WS-Referral
Consumers access a ‘virtual’ endpoint
DIMACS (Chung, Falchuk, Micallef) – 12
Trust Domain Trust Domain
ManageMy Features(non-secure)
WS Gateway
Policy
Router
ServiceOrder
Billing
ManageMy Features
(secure)
…
UpdateVoice
Features
Gateway ConfigurationWeb Service Metada
ta(OWL)
EncryptionAuthenticationSignature
Encrypt (128)UserPwd
WS Security Gateway Configuration
Deployment Wizard Knowledge
Base (ontology + instances)
ArchitectureReasonerService
DeploymentAdmin
DIMACS (Chung, Falchuk, Micallef) – 13
Trust Domain Trust Domain
WS Gateway
Policy
Router
Service
Service
Service
Automating Gateway Configuration
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
Gateway’s behavior Activate/deactivate Policy {X} for Web Service {Y}
ServiceConsumer
ServiceConsumer
…
ReasonerOntology
Wizard (servlets)
DeploymentAdmin
Configuration Interface
DIMACS (Chung, Falchuk, Micallef) – 14
Gateway Internals
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
filter
Service
ServiceConsumer
affected by calls uponConfiguration Interface
Custom
Policy
Referral
Security
Trace
router
Filters:
DIMACS (Chung, Falchuk, Micallef) – 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
DIMACS (Chung, Falchuk, Micallef) – 16
Ontology
Encryption artifacts
Protégé
Authentication artifacts
Trust_Domain consists of 0 or more Intermediaries
Security_GW is an Intermediary
Properties..Classes..
DIMACS (Chung, Falchuk, Micallef) – 17
An Intermediary has messaging and security capabilities. It supports
Services
A Trust_domain is composed of Intermediaries
(and Intranet, devices, ..)
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>
DIMACS (Chung, Falchuk, Micallef) – 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
DIMACS (Chung, Falchuk, Micallef) – 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
DIMACS (Chung, Falchuk, Micallef) – 20
Two Use-Cases
1. Service X requires a Kerberos-style encryption. Can the Infrastructure support X?1. Deployment Admin selects the “Configure Security” option2. Reasoner applies heuristics
1. GW has declared Kerberos_v5 capability2. Reasoner applies subsumption heuristic: Kerberos satisfies Kerberos_v5
more generally3. Reasoner concludes that X is satisfiable
3. Reasoner invokes the Gateway’s Configuration Web Service as necessary
2. 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 e.g. Decryption must happen before content can be filtered
2. Reasoner invokes the Gateway’s Configuration Web Service as necessary
DIMACS (Chung, Falchuk, Micallef) – 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 X509reasonerImpl: Reqmt Kerberos NOT met by more general GW capability Authentication_Security_CapabilityreasonerImpl: Reqmt Kerberos NOT met by exact GW capability SecurIDreasonerImpl: Reqmt Kerberos NOT met by more general GW capability Authentication_Security_CapabilityreasonerImpl: Reqmt Kerberos NOT met by exact GW capability MD5reasonerImpl: Reqmt Kerberos NOT met by more general GW capability Encryption_Security_CapabilityreasonerImpl: Reqmt Kerberos NOT met by exact GW capability DACreasonerImpl: Reqmt Kerberos NOT met by more general GW capability Encryption_Security_CapabilityreasonerImpl: Reqmt Kerberos NOT met by exact GW capability CRAM_MD5reasonerImpl: Reqmt Kerberos NOT met by more general GW capability Authentication_Security_CapabilityreasonerImpl: Reqmt Kerberos NOT met by exact GW capability RC2reasonerImpl: Reqmt Kerberos NOT met by more general GW capability Encryption_Security_CapabilityreasonerImpl: Reqmt Kerberos NOT met by exact GW capability Microsoft_WindowsreasonerImpl: Reqmt Kerberos NOT met by more general GW capability Authentication_Security_CapabilityreasonerImpl: Reqmt Kerberos NOT met by exact GW capability Kerberos_v5reasonerImpl: Reqmt Kerberos met by more general GW capability KerberosreasonerImpl: Testing if reqmt Kerberos can be met on the TD..reasonerImpl: Reqmt Kerberos NOT met by exact TD capability Kerberos_v5reasonerImpl: Reqmt Kerberos met by more general TD capability KerberosreasonerImpl: Summary:reasonerImpl: Kerberos
reasonerImpl: Calling out to GW with the following:reasonerImpl: (http://www.telcordia.com/services/billing,Kerberos,true)
SubsumptionSubsumptionreplacementreplacement
*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) – 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)
Thank you.
Chit Chung [email protected]
Ben Falchuk [email protected]
Josephine Micallef [email protected]