563.4 Web Services

1. 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. 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). Web Services

5. Typical Web Service Components

6. Web Services Architecture UDDI Universal Description, Discovery, and Integration • Provide a Directory of Services on the Internet WSDL Web Services Description Language • Web Services are defined in terms of the formats and ordering of messages SOAP • Web Services consumers send and receive SOAP messages XML & HTTP • Built using open Internet protocols

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. 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 WSEmail Project 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 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. 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 Parameters

25. 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 Results

26. 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 Performance Results

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 RMTA SMTA Egress Policies Merged Policies Ingress Policies Client Policies Recipient Sender

32. Policy Architecture RMTA SMTA Merged Policies Recipient Sender

33. Policy Architecture RMTA SMTA Egress Policies Ingress Policies Client Policies Recipient Sender 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 Limited scope for targeted messaging Unwanted messages Approach Target messages based on recipient attributes Create recipient lists dynamically Problem and Approach

37. 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 Scenarios and Challenges

38. Data Services Data Services Attr. DB Attr. DB Domain B Legacy Databases Legacy Databases ABM Server ABM Server Inter Domain ABM over Web Services To: Mgr@DomA && Mgr@DomB MTA MTA Regular E-mail (SMTP) Architecture Domain A

39. t s i L e t u b i r t t A e l b a t o ) R n . o i 8 t A p p a q q s s c e e i e e r r t r r n L L L L e M M h M M t C C C C u A A A A A X X ( X X . . D . . 5 3 6 4 I A 3 . Xquery ( User ID ) A C A C r e s A 4 . User Attribute List U . 1 A A 2 . User ID A 7 . Routable Attribute List C 1 . Xquery ( User ID ) C 2 . User Attribute List C 5 . Xquery ( ABM Address ) Standard Email Client C 6 . Email list Address : ABM abm @ uiuc . edu B 1 . Attachment : xacml . xml ; Create xquery . xml ; B 2 . Send Query MTA sender mail . Send . . Phase 1 Architecture PDP XACML Engine Policy . Policy Specialization Path xml Web Server WEB Interface ABM Host XML DB Address Resolution Path MUA Send Mail Run Demo

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