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. ACME Communications Joe’s Telco Customer Portal ACME Customer Portal Billing Billing Inventory Activation Network4Sale PAY Online Inventory Service Ordering Motivating Scenario

4. ACME Communications Joe’s Telco Customer Portal ACME Customer Portal Billing Billing Activation Inventory Deployment Administrator Service Designer Functional & non-functional service requirements Requirements, constraints Capabilities, constraints Capabilities, constraints Infrastructure capabilities Network4Sale PAY Online Inventory Service Ordering 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? * our focus is the set of non-functional req’mts

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. Trust Semantic Web “stack” Proof Logic Framework Rules Encryption Signature Ontology RDF Schema RDF XML Namespaces URI Unicode 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, ..

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)

8. Deployment Administrator Ontology Creation Web Services Gateway existing ontologies WSE Service Designer Stanford Protégé Solution Approach & Underpinnings Service Consumers Wizard + Reasoner Knowledge Base HP Jena API W3C OWL

9. Transport level security Message level security 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 • 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

11. Trust Domain WS Gateway Service Service Consumer Service Policy … Router Service Service Consumer 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. Manage My Features (secure) Encrypt (128) UserPwd Encryption Authentication Signature Metadata (OWL) Architecture Reasoner Service Deployment Wizard Knowledge Base (ontology + instances) Deployment Admin 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. Configuration Interface WS Gateway Deployment Admin Service Consumer Policy … Router Wizard (servlets) Service Consumer Reasoner Ontology Automating Gateway Configuration Trust Domain • 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} Service Service Service

14. Trace Security Referral Policy Custom 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 <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, ..) An Intermediary has messaging and securitycapabilities. 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 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? • 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 Gateway’s 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 reasonerImpl: 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_Capability reasonerImpl: Reqmt Kerberos NOT met by exact GW capability DAC reasonerImpl: Reqmt Kerberos NOT met by more general GW capability Encryption_Security_Capability reasonerImpl: 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_Capability reasonerImpl: Reqmt Kerberos NOT met by exact GW capability Microsoft_Windows reasonerImpl: Reqmt Kerberos NOT met by more general GW capability Authentication_Security_Capability reasonerImpl: 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.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

22. From the Admin’s 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.