Security and Latency Considerations in Simple Object Access Protocol CSE 581 Winter 2002

1. Security and Latency Considerations in Simple Object Access Protocol CSE 581 Winter 2002 Sudarshan “Sun” Murthy smurthy@sunlet.net CSE581 (Winter '02): Security & Latency in SOAP (c) Sudarshan "Sun" Murthy

2. Papers • Damiani E, et al. Fine-grained Access Control for SOAP E-Services • W3C XML Protocol Working Group. SOAP Version 1.2 Part 0: Primer • uddi.org. UDDI Technical White Paper • Dan Davis, Manish Parashar. Latency Performance of SOAP Implementations CSE581 (Winter '02): Security & Latency in SOAP (c) Sudarshan "Sun" Murthy

3. What is Simple Object Access Protocol (SOAP)? • Provides a definition of an XML document for exchange between peers in a decentralized, distributed environment • A stateless 1-way message exchange paradigm • Can be bound to transport protocols like HTTP • Does not define many aspects: semantics of data exchanged, routing, reliability, security • Extensible to convey specificinformation CSE581 (Winter '02): Security & Latency in SOAP (c) Sudarshan "Sun" Murthy

4. SOAP vs. Other RMI Means • Java, DCOM are popular RMI means • Language or platform specific; verbose • CORBA is another popular RMI means • ORB’s don’t interoperate well; verbose • SOAP provides yet another means of RMI • Language and platform neutral due to XML • Can be bound to a suitable transport protocol • No/fewer firewall traversal issues (?) CSE581 (Winter '02): Security & Latency in SOAP (c) Sudarshan "Sun" Murthy

5. SOAP Message Overview • Message is embedded in Envelope element • Envelope has Header and Body elements • Header is optional; Body is mandatory • Contents are application specific • Children of Header (called blocks) allow • SOAP processors to exchange information • Application specific extensions CSE581 (Winter '02): Security & Latency in SOAP (c) Sudarshan "Sun" Murthy

6. SOAP Message Processing • A message might visit one or more nodes • A node/processor plays zero or more roles • Roles may be fixed, discovered from message • Each processor processes the envelope (part or full) and might perform actions such as • Process message partially • Alter message • Forward message CSE581 (Winter '02): Security & Latency in SOAP (c) Sudarshan "Sun" Murthy

7. SOAP Action • A message that requests RPC must contain • Target of the procedure or method (final node) • A procedure or method name (usually a URI) • Parameters to the procedure or method (body) • Context for the service (contained in header) • A response message must correlate to a request • Transport protocol used may not support this CSE581 (Winter '02): Security & Latency in SOAP (c) Sudarshan "Sun" Murthy

8. SOAP Transports • SOAP defines binding to HTTP • HTTP clients are widely deployed • Clients simply POST requests • Responses easily correlate to requests • SOAP may be bound to other transports • SMTP • Java RMI, C++ RMI CSE581 (Winter '02): Security & Latency in SOAP (c) Sudarshan "Sun" Murthy

9. Some gateways use this field to implement security HTTP SOAP Request POST /QuoteService HTTP/1.1 SOAP-Action="http://www.acme.com/GetQuote" Content-Type: text/xml; charset="UTF-8" Content-Length: nnnn <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/Envelope" xmlns:ACME="http://www.acme.com/soap" SOAP-ENV:EncodingStyle="http://schemas.xmlsoap.org/soap/encoding"> <SOAP-ENV:Header> <!--header blocks> </SOAP-ENV:Header> <SOAP-ENV:Body> <ACME:GetQuote ACME:id="ref-1"> <!—method parameter elements go here--> </ACME:GetQuote> </SOAP-ENV:Body> </SOAP-ENV:Envelope> CSE581 (Winter '02): Security & Latency in SOAP (c) Sudarshan "Sun" Murthy

10. HTTP SOAP Response HTTP/1.1 200 OK Content-Type: text/xml; charset="UTF-8" Content-Length: nnnn <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/Envelope" xmlns:ACME="http://www.acme.com/soap" SOAP-ENV:EncodingStyle="http://schemas.xmlsoap.org/soap/encoding"> <SOAP-ENV:Body> <ACME:GetQuoteResponse> <ACME:Amount>18</ACME:Amount> </ACME:GetQuoteResponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope> CSE581 (Winter '02): Security & Latency in SOAP (c) Sudarshan "Sun" Murthy

11. SOAP Execution Sequence CSE581 (Winter '02): Security & Latency in SOAP (c) Sudarshan "Sun" Murthy

12. SOAP Issues We will discuss only these • Security • Latency • Interoperability • Multiple sources of issues • SOAP, transport protocol • Reliability issues (due to transport/network) • Improvements must apply regardless of the transport protocol used CSE581 (Winter '02): Security & Latency in SOAP (c) Sudarshan "Sun" Murthy

13. SOAP Security Concerns • XML documents are clear text; we must ensure • Authenticity • Privacy • Non-repudiation • Actions might be privileged • Message/client might be authentic, but client might not be authorized to make that request We might take a peek at these The primary paper deals with this CSE581 (Winter '02): Security & Latency in SOAP (c) Sudarshan "Sun" Murthy

14. SOAP Fine-grained Authorizations • Intercept SOAP requests (and responses) using an authorization filter • Requests might be allowed/rejected/filtered • Elements/attributes are candidate objects • XPath expressions identify objects • Multiple authorization subjects are possible • Users, groups, location, roles CSE581 (Winter '02): Security & Latency in SOAP (c) Sudarshan "Sun" Murthy

15. Simple Public Key Infrastructure Realizing Fine-grained Authorizations • Use custom header blocks in message • Closely related to XML-SPKI • Credential element defines user and location • Zero or more roles may also be defined • Establish a database of authorizations • Store triples of subject, object, and permission • Use secure credential mechanism such as SSL to authenticate clients CSE581 (Winter '02): Security & Latency in SOAP (c) Sudarshan "Sun" Murthy

16. Impact of Fine-grained Authorizations • Authorization filter needs to be inserted in front of the SOAP gateway • Client applications must be altered to insert custom headers • Servers that don’t have the authorization filter can simply ignore custom headers received from clients • Some servers might provide a fault response CSE581 (Winter '02): Security & Latency in SOAP (c) Sudarshan "Sun" Murthy

17. Remarks about Fine-grained Authorizations • Simple; one of firsts in SOAP authorization • HTTP transport bias for authentication • XPath results change if message is altered • Filtering parts of message might be harmful • What if method parameters are filtered out? • Some filters cannot be expressed • See Section 4.5 example 4 CSE581 (Winter '02): Security & Latency in SOAP (c) Sudarshan "Sun" Murthy

18. SOAP Latency • Compares 4 implementations • Apache SOAP (Tomcat, Java) • MS SOAP Toolkit (IIS, Visual Basic) • SOAP::Lite (Perl) • XSOAP, aka SoapRMI (Java) • Contrasts with Java RMI and CORBA • Measurements made with clear XML- no security measures used CSE581 (Winter '02): Security & Latency in SOAP (c) Sudarshan "Sun" Murthy

19. Experiment Design • Client and server on same/different machine • Clients perform basic operations • doNothing, getString, getIntegers • doNothing also measures • TCP setup delay • HTTP to Apache Tomcat (web server) delay • HTTP to MS IIS (web server) delay CSE581 (Winter '02): Security & Latency in SOAP (c) Sudarshan "Sun" Murthy

20. doNothing Results CSE581 (Winter '02): Security & Latency in SOAP (c) Sudarshan "Sun" Murthy

21. doNothing Analysis • Nagle algorithm hurts • With Apache SOAP, client sent request in two packets; the second packet arrived 170 ms later! • With MS, client sends request in one packet and receives a continue response; server sends OK response with body after client sends ACK • SOAP and XML processing hurt • TCP setup time and HTTP-server time is small CSE581 (Winter '02): Security & Latency in SOAP (c) Sudarshan "Sun" Murthy

22. Apache SOAP Event Trace CSE581 (Winter '02): Security & Latency in SOAP (c) Sudarshan "Sun" Murthy

23. MS SOAP Event Trace CSE581 (Winter '02): Security & Latency in SOAP (c) Sudarshan "Sun" Murthy

24. getString Results CSE581 (Winter '02): Security & Latency in SOAP (c) Sudarshan "Sun" Murthy

25. getInteger Results CSE581 (Winter '02): Security & Latency in SOAP (c) Sudarshan "Sun" Murthy

26. Results • Apache SOAP works well for large requests, MS works well for large responses • JavaRMI and CORBA work much better • Motivations to transport these over HTTP • XSOAP numbers demonstrate this possibility • Transportation costs are negligible compared to cost of XML processing, serializing, and deserializing CSE581 (Winter '02): Security & Latency in SOAP (c) Sudarshan "Sun" Murthy

27. Factors Influencing Latency • Security measures • Adding transport protocol security could hurt more. For example, HTTPS transport for signed and encrypted messages. • Number of intermediary processors • Encoding scheme • Packing scheme (MIME, DIME, etc.) • Allows mixing content types CSE581 (Winter '02): Security & Latency in SOAP (c) Sudarshan "Sun" Murthy

28. SOAP Security Sampler • Several drafts are growing/brewing • XML Encryption • XML Signatures • Web Services Security Language • Web Services License Language • Here is a request without security: notsecure.xml • Here is that request with security: secure.xml • Neither version contains authorization information • What does this do to latency? CSE581 (Winter '02): Security & Latency in SOAP (c) Sudarshan "Sun" Murthy

29. Universal Description, Discovery, and Integration (UDDI) • Allows businesses to describe their web services in a registry • Registry is logically centralized, but physically distributed • Allows customers to discover web services • Allows developers to integrate applications with web services (not quite) • Defines an API to achieve all this CSE581 (Winter '02): Security & Latency in SOAP (c) Sudarshan "Sun" Murthy

30. UDDI Realization • Who owns the registries? • IBM, MS, Ariba have announced plans • MS (?) says its registry will be free • Not much progress since late 2000 • Universal Service Interop Protocols are still “yet to be defined” • A sponsor has other thoughts? Who could that be?  CSE581 (Winter '02): Security & Latency in SOAP (c) Sudarshan "Sun" Murthy

31. Conclusions • SOAP is an improvement in interoperable middleware domain • Security needs immediate attention • Latency is relatively high, even without security measures in place • Authorization measures might hurt interoperability • UDDI- a pie in the sky? CSE581 (Winter '02): Security & Latency in SOAP (c) Sudarshan "Sun" Murthy

32. References • Visit this URL to see this presentation, list of references, etc. http://www.cse.ogi.edu/~smurthy/soap/index.html CSE581 (Winter '02): Security & Latency in SOAP (c) Sudarshan "Sun" Murthy