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 SOAP Web Services consumers send and receive SOAP messages Web Services consumers send and receive SOAP messages WSDL Web Services Description Language Web Services are defined in terms of the formats and ordering of messages Web Services are defined in terms of the formats and ordering of messages Built using open Internet protocols Built using open Internet protocols XML & HTTP Web Services Architecture UDDI Universal Description, Discovery, and Integration Provide a Directory of Services on the Internet Provide a Directory of Services on the Internet

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 Hi please bill to the following address Skateboard One Warehouse Park Boston

9 XML Declaration the XML declaration –Not required, but typically used –Attributes include: Version Encoding – the character encoding

10 XML Element Hi please bill the following …

11 XML Attribute … … XML Attribute –Describes additional information about an element – text

12 XML Namespaces … 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 <t:Transaction xmlns:t=“URI” SOAP-ENV:mustUnderstand=“1” > Very High “XML Document”

15 AMPol Project Adaptive Messaging Policy Project concerns next-generation messaging systems with improved security, flexibility, and integration. Principal activities –WS –Dynamic policy adaptation –Attribute-Based Messaging (ABM)

16 AMPol Principal Activities WS Dynamic policy adaptation Attribute-based messaging

17 Internet 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 WS Project Began at Penn with support from Microsoft Aim: use web services as a new foundation for 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 WS 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 WS Test-bed Machines: Pentium4 Network: 100Mb switched Ethernet Client Machines: 2.8GHz, 512MB RAM Server (S i ): 2.8GHz, 1GB RAM Database (S db ): 2.4GHz, 1GB RAM Internet Emulator (S e ): 2.8GHz, 512MB RAM

24 Parameters Each client will send 2000 requests to S i Operations: send message, list headers, retrieve message, delete message (each with equal chance) Sent messages include local recipient (a user on S i ) and an external recipient (a user on S e ). 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 WS 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 based on WS

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 Client Policies Merged Policies

32 Policy Architecture SMTA RMTA Sender Recipient Merged Policies

33 Policy Architecture SMTA RMTA Sender Recipient Egress Policies Ingress Policies Client Policies 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 WS 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 ABM Server Data Services Legacy Databases Attr. DB Domain B MTA ABM Server Data Services Legacy Databases Attr. DB Regular (SMTP) Inter Domain ABM over Web Services To: &&

39 Phase 1 Architecture WEB Interface Send Mail Send mail B2. Standard Client Address: Attachment:xacml.xml; xquery.xml; sender... Send MTA ABM XML DB Policy. xml ABM Host MUA PDP XACML Engine C5.Xquery(ABM Address) C2.User Attribute List C1.Xquery(User ID) C 3. X A C M L r e q C 4. X A C M L r e s p Web Server A2.User ID A7.Routable Attribute List A3.Xquery(User ID) A4.User Attribute List A 5. X A C M L r e q A 6. X A C M L r e s p A 8. R o t a b l e A t t r i b u t e L i s t A 1. U s e r I D ( A u t h e n t i c a t i o n ) B1. Create Query C6. 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