Automating Deployment Configuration of Web Services Security C

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 Network 4 Sale 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 Network 4 Sale 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 “stack” Motivation: the meaning of Web content is not machine-accessible § Ontology Web Language (OWL) is a W 3 C Recommendation Trust – – § 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 Encryption – Signature § 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. Open. Cyc (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 W 3 C 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

• Uses WS-Security, WS-Policy, and WS-Security. Policy • Enforces policies on service invocation • Associates policies with Gateway service endpoints WS Gateway ‘virtual’ endpoint Consumers access a Service Consumer • Uses WS-Addressing and WS-Referral vice versa Gateway-managed service endpoints, and • Maps Gateway service endpoints to Policy Trust Domain Router … Service Consumer Service WS Security Gateway DIMACS (Chung, Falchuk, Micallef) – 11

Policy Trust Domain Billing Deployment Admin Update Voice … Features Encrypt (128) User. Pwd (ontology + instances) Knowledge Base Architecture Reasoner Service Order Service Encryption Authentication Signature WS Security Gateway Configuration Web Service Deployment Wizard Router Manage My Features (secure) (non-secure) My Features Manage WS Gateway DIMACS (Chung, Falchuk, Micallef) – 12

Deployment Service Admin Service Consumer Service … Wizard (servlets) Ontology Service Consumer Reasoner Trust Domain Router § Configuration Interface of the Policy Web Services Gateway – – Exposes a Web Service WS that. Gateway 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 Policy. Assertion 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 § § Qo. S, Security, Reliability, Messaging, etc. Some related work is re-usable – – – § Security gateways, their capabilities, interconnected-ness, etc. IBM – an OWL ontology for Qo. S (metrics, measurements. . ) Carnegie Mellon – ontology capturing the artifacts described in the W 3 C 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: Object. Property rdf: ID="td_supports_security_cap"> <protege: allowed. Parent rdf: resource="#Security_Capability"/> <rdfs: domain rdf: resource="#Trust_Domain"/> <rdfs: range rdf: resource="http: //www. w 3. org/2002/07/owl#Class"/> </owl: Object. Property> 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. 2. GW has declared Kerberos_v 5 capability Reasoner applies subsumption heuristic: Kerberos satisfies Kerberos_v 5 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 reasoner. Impl: reasoner. Impl: Testing if reqmt Kerberos can be met on the GW. . Reqmt Kerberos NOT met by exact GW capability X 509 Reqmt Kerberos NOT met by more general GW capability Authentication_Security_Capability Reqmt Kerberos NOT met by exact GW capability Secur. ID Reqmt Kerberos NOT met by more general GW capability Authentication_Security_Capability Reqmt Kerberos NOT met by exact GW capability MD 5 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_MD 5 Reqmt Kerberos NOT met by more general GW capability Authentication_Security_Capability Reqmt Kerberos NOT met by exact GW capability RC 2 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_v 5 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_v 5 Reqmt Kerberos met by more general TD capability Kerberos Summary: Kerberos reasoner. Impl: Calling out to GW with the following: reasoner. Impl: (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 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