563.4 Web Services

Presented by: Carl A. Gunter

University of Illinois

Spring 2006

2

Today’s Web

• Designed for applications involving human interactions

• Intended purpose – Information sharing: a distributed content library– Enabled B2C e-commerce– Non-automated B2B interactions

• How did it happen?– Built on very few standards: http + html– Simple interaction model: very few assumptions– Result was ubiquity

3

What’s Next?

• Improve machine-to-machine protocols to enable more automation.

• Use a readily-extensible foundation.

• Build in security from the start.

• Overcome limits to widespread web deployment of Corba, DCOM, etc.

4

Web Services

• Strategy: use XML as a foundation for both infrastructure and application formats.

• Build a stack of XML-based processing layers.• Create XML-based security mechanisms that

integrate with existing approaches (e.g. X.509).

5

Typical Web Service Components

6

SOAPSOAP Web Services consumers send and Web Services consumers send and

receive SOAP messages receive SOAP messages

WSDLWeb Services

Description Language

WSDLWeb Services

Description Language

Web Services are defined in terms of the Web Services are defined in terms of the formats and ordering of messagesformats and ordering of messages

Built using open Internet protocols Built using open Internet protocols XML & HTTP

Web Services Architecture

UDDIUniversal Description,

Discovery, and Integration

UDDIUniversal Description,

Discovery, and Integration

Provide a Directory of Services on the Provide a Directory of Services on the InternetInternet

7

XML

• Extensible Markup Language• Meta language that

– Allows to create and format own document markups

• A method for putting structured data into a text file

- easy to read- unambiguous- extensible- platform-independent

8

Sample XML Example

<?xml version=“1.0” encoding=“…”?><msg:message from=“id” to=“id” xmlns:msg=“URI”

xmlns:po=“URI”><msg:text>

Hi please bill to the following address</msg:text><msg:item>

<po:po id=“123”> <po:billto>

<po:company> Skateboard </po:company> <po:street> One Warehouse Park </po:street> <po:city> Boston </po:city>

</po:billto> </po:po>

</msg:item></msg:message>

9

XML Declaration

<?xml version=“1.0” encoding=“…”?>

• <?xml ?> the XML declaration – Not required, but typically used– Attributes include:

• Version

• Encoding – the character encoding

10

XML Element

<msg:message from=“id” to=“id” xmlns:msg=“URI” xmlns:po=“URI”><msg:text>

Hi please bill the following</msg:text><msg:item> <po:po id=“123”>

… </po:po></msg:item>

</msg:message>

11

XML Attribute

<msg:message from=“id” to=“id” xmlns:msg=“URI” xmlns:po=“URI”>

… <po:po id=“123”>

… </po:po>

</msg:message>

• XML Attribute – Describes additional information about an element– <tag key=”value”> text</tag>

12

XML Namespaces

<msg:message from=“id” to=“id” xmlns:msg=“URI” xmlns:po=“URI”>…

</msg:message>

• Namespaces– Not mandatory, but useful in giving uniqueness to an

element– Declared using the xmlns:name= “value”

13

SOAP

• An XML envelope for XML messaging

• Headers + body• SOAP is “transport

independent”• Supports both

messaging and RPC

SOAP Envelope

SOAP Header: encoding, authentication, transaction information, etc.

SOAP Body

SOAP Body Block: parameters, return values, etc

SOAP Fault

14

SOAP Message Example

<?xml … ?><SOAP-ENV:Envelope xmlns:SOAP-ENV=“URI” >

<SOAP-ENV:Header> <t:Transaction xmlns:t=“URI” SOAP-ENV:mustUnderstand=“1” >

12345 </t:Transaction> <p:Priority xmlns:p=“URI”>

Very High </p:Priority></SOAP-ENV:Header>

<SOAP-ENV:Body>“XML Document”

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

15

AMPol Project

• Adaptive Messaging Policy Project concerns next-generation messaging systems with improved security, flexibility, and integration.

• Principal activities– WSEmail– Dynamic policy adaptation– Attribute-Based Messaging (ABM)

16

AMPol Principal Activities

• WSEmail

• Dynamic policy adaptation

• Attribute-based messaging

17

Internet Email

• Based on a collection of protocols• SMTP, POP, IMAP, S/MIME

• Evolved over a vast installed base• Shortcomings

• Flexibility

• Security

• Integration

18

Approaches to Improvement

• Make incremental changes and overlays for the existing protocols

• Redesign the system from a low level– Example: instant messaging

• Create a design from another high-level foundation– Example: use HTTP and SSL

19

WSEmail Project

• Began at Penn with support from Microsoft

• Aim: use web services as a new foundation for email as a way to improve security, flexibility, and integration

• Ongoing project at both UIUC and Penn

• Applications– Instant messaging– Routed forms– On-demand

attachments

• Theory– Using Proverif and

TuleFale

• Performance– .NET implementation

on a small testbed

Lux May Bhattad Gunter 05

20

Application: Integrated IM

21

Application: Routed Forms

22

Implementation

• WSEmail implemented over .NET framework with Web Services Enhancement (WSE)

• Messages stored on SQL Server 2000• Version 1.0 has

– 68 interfaces– 343 classes– 30 projects– C# .NET-managed code created with MS Visual

Studio

• DNS SRV records used for routing.

23

WSEmail Test-bed

Stc

TestCoordinator

X.509 Certificate Authentication

Se

Windows 2003 Web Edition

Si

Windows 2003 Web Edition

DNS, User Authentication

DNS, User Authentication,

DB Storage

Windows 2003 Server Standard

Edition

T1

T3

T2

T4

Client MachinesWindows XP Pro

UserNameand

PasswordAuthentication

Sdb SQL Server 2000 Enterprise Edition (SP3a)

Machines: Pentium4

Network: 100Mb switched Ethernet

Client Machines: 2.8GHz, 512MB RAM

Server (Si): 2.8GHz, 1GB RAM

Database (Sdb): 2.4GHz, 1GB RAM

Internet Emulator (Se): 2.8GHz, 512MB RAM

24

Parameters

• Each client will send 2000 requests to Si

• Operations: send message, list headers, retrieve message, delete message (each with equal chance)

• Sent messages include local recipient (a user on Si) and an external recipient (a user on Se).

• Test coordinator holds test parameters that clients receive and parse

• Message database is pre-populated with a few entries

• Test coordinator signals test start

• Clients non-deterministically pick an action to perform, based on upon test parameters

25

Results

• Average latency: .274 sec / msg

• Rate of 1786 msg / min

• Client machines sent 36.4MB and received 369.4MB

• Test took 1824 sec to execute

• Benchmark comparison to SMTP on our machines showed .170 sec / msg with messages of similar size

• Benchmark UW Parkside peak usage figures were 1716 msg / min

26

Performance Results

• Average latency: .274 sec / msg

• Rate of 1786 msg / min

• Client machines sent 36.4MB and received 369.4MB

• Test took 1824 sec to execute

• Benchmark comparison to SMTP on our machines showed .170 sec / msg with messages of similar size

• Benchmark UW Parkside peak usage figures were 1716 msg / min

27

Theory

• On Demand Attachments Protocol– Nine messages, four

parties– Complex messages – Want to prove that

receiving an attachment means it was sent by the sender in the from field

28

AMPol Principal Activities

• WSEmail

• Dynamic policy adaptation

• Attribute-based messaging

Afandi Zhang Hafiz Gunter 06

29

Policy Adaptation

• Large-scale systems often cannot operate under a uniform policy

• Scalability can be aided by allowing parties to express policies that must be satisfied in interactions

• Apply this idea to messaging systems to achieve adaptive messaging policy

• Case study for email based on WSEmail

30

Architectural Components

• Policy Model– What policies can be expressed– Our instantiation: AMPL and APES (Attachments,

Payment, Encryption, Signature)

• Policy Discovery– Policy merging– Policy Query Protocol (PQP)

• Extension and Enforcement– Conformance– Extension– Enforcement

31

Policy Architecture

SMTA RMTA

Sender Recipient

Egress Policies Ingress Policies

ClientPolicies

Merged Policies

32

Policy Architecture

SMTA RMTA

Sender Recipient

Merged Policies

33

Policy Architecture

SMTA RMTA

Sender Recipient

Egress Policies Ingress Policies

ClientPolicies

Plug in Server

34

Demo

• A message from Afandisandy1 to Afandigary1

• Two MTAs– Afandisandy1’s egress policy is HashCash

(cycle exhaustion)– Afandigary1’s ingress policy includes RTT

(Reverse Turing Test) and Identity-Based Encryption (IBE)

• Run demo

35

AMPol Principal Activities

• WSEmail

• Dynamic policy adaptation

• Attribute-based messaging

Bobba Fatemieh Kahn Gunter Khurana 06

36

Problem and Approach

• Problem– Limited scope for

targeted messaging– Unwanted messages

• Approach– Target messages

based on recipient attributes

– Create recipient lists dynamically

37

Scenarios and Challenges

• Scenarios– Address all faculty

going on sabbatical next term

– Address all the people working on security related projects in an organization

– Address all TeraGrid system administrators

– Address doctors in the tri-state area who have expertise in a specific kind of operation

• Challenges– User attribute

assimilation and query– User privacy– Access rights– Inter-domain

messaging• Attribute mapping• Privacy policy• AAA

38

Architecture

Domain A

MTA

ABMServer

DataServices

Legacy Databases

Attr.DB

Domain B

MTA

ABMServer

DataServices

Legacy Databases

Attr.DB

Regular E-mail (SMTP)

Inter Domain ABM over Web Services

To:

Mgr@

DomA

&&

Mgr@

DomB

39

Phase 1 Architecture

WEB Interface

Send Mail

Send mail

B2.

Standard Email Client

Address : abm@uiuc.eduAttachment : xacml.xml;

xquery .xml; sender

.

.

.Send

MTA

ABM

XML DB

Policy.xml

ABM Host

MUA

PDPXACML Engine

C5. Xquery (ABM Address )

C2. User Attribute List

C1. Xquery (User ID )

C3

. X

AC

ML

re

qC

4.

XA

CM

L r

esp

Web Server

A2. User ID

A7. Routable Attribute List

A3. Xquery (User ID )

A4. User Attribute List

A5

. X

AC

ML

re

q

A6

. X

AC

ML

re

spA8

. R

ota

bl e

Att

rib

ute

Li s

t

A1

. U

se

r ID

(A

uth

en

tica

tio

n)

B1. Create Query

C6. Email list

Run Demo

Policy Specialization Path

Address Resolution Path

40

Phase I

• Attribute assimilation and query– Native XML attribute database– XQuery

• Privacy and privileges– Restricted access to attributes– Policy specification and enforcement using XACML

• Performance evaluation:– 60,000 users and 100 attributes

41

Policy Specialization Time

42

Address Resolution Time RDB

Relational DB

43

Address Resolution Time XMLDB

XML DB

44

Conclusions

• Crossroads for important technology advances– Adaptive policies– Web services (“Service Oriented

Architectures”)– Formal models and verification for security

protocols

• Messaging systems– Critical in their own right– Good domain for developing and applying

core advances