WebServices, GridServices

and Firewalls
Matthew J. Dovey
Technical Manager
Oxford e-Science Centre
http://e-science.ox.ac.uk
(matthew.dovey@oucs.ox.ac.uk)

WebServices
Method of inter-computer communication

Initially Remote Procedural Call

Uses XML for messages

Uses existing Web/Internet protocols for
transfer

e.g. HTTP for synchronous

e.g. SMTP for asynchronous

WebServices
Service defined by endpoint

e.g. URL http://myserver.org/myservice

m.g. e-mail address myservice@myserver.org

Operation (and parameters) defined by XML

message
e.g.
<SOAP-Env:body>
<myOperation>
<myParam></myParam>
</myOperation>
</SOAP-Env:body>

WebServices and Firewalls

SOAP 1.0 (Microsoft) the ability to
transfer information between organisations
through the firewall
Ability to offer multiple WebServices
through a single port
Ability to offer multiple WebServices
through protocols traditionally allowed
through firewalls (http, smtp)
No portmappers

Securing WebServices
Publishing model

Internal services behind the firewall

publish only safe public services
Comparable to public website vs internal
intranet for documents

But

Web Services have bugs

Web Service Infrastructures have bugs
Web Servers/SMTP Servers have bugs

Securing WebServices
Application Level Firewalls

Traditional firewalls assume application defined by

port
WebServices defined by endpoint (URL) and XML
data
Application Firewalls inspect XML data
Check XML conformant with application (determined
by endpoint)
Block unregistered endpoints/XML data
Strong linkage between firewall and application (no
longer disconnected black boxes)
Issues with encrypted data

Securing WebServices
Private Networks via SSL

WebService encryption either

Sensitive message parts (avoiding cost of
encrypting all the message)
Transport (e.g. https, smtp over SSL etc.)

Use of SSL for private network services

Encrypt and authenticate via x509 certificates
No certificate no access

Comparable to VPN solutions for Globus 2

GridServices
An application framework built on
WebServices
Differences from traditional WebServices

State handling
NotificationSource and NotificationSink

Notification Events
Under OGSA Notification model both
source and recipient of a notification must
implement a GRID Service interface
i.e. GRID clients (typically desktops) must
behave as a GRID Service (WebService)
server
Security of desktop as crucial as security
of server
Issues with VPNs

State handling
WebServices handle state via

Out of band session id, e.g. HTTP cookie

Service defined session id carried in SOAP
Envelope

GRIDServices handle state via factories

Factory service returns a URL to a dedicated

service for that client
URL acts as session id
Similar to RPC port mapping (URL mapping)

GRIDService Factories - Cons

Hijacking

URLs transparent when not over SSL

(WebServices can selectively encrypt)
Danger of predictable URLs
(WebServices can generate random and
semantic-less keys)

May be difficult to use with application

level firewalls which rely on fixed
endpoints for services

GRIDService Factories - Pros

Factory could link generated service strongly to
client

Service linked to given ip address only

Service only allows https/SSL connection from client
certificate
i.e. knock on door system comparable in dynamic
firewall solution to Globus 2

Instance could be on another machine

Factory on front-end box

Summary
WebServices originally bypassed firewalls
WebServices require sophisticated
application-aware protection
WebServices/GRIDServices potential offer
mechanisms for enforcing security (e.g.
certificate authentication)

Slide number 14