automating deployment configuration of web services security c.chung, b.falchuk*, j.micallef...

24
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

Post on 21-Dec-2015

228 views

Category:

Documents


1 download

TRANSCRIPT

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) – 22

From the Admin’s Point-of-View

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]