SOAP “Simple” Object Access Protocol Will Cameron CSC 8530 November 9, 2006 Student Presentation 2

What is SOAP? ► XML to define an extensible messaging framework ► Providing a message construct that can be exchanged over a variety of underlying protocols (HTTP, SMTP) ► “”The framework has been designed to be independent of any particular programming model and other implementation specific semantics.” ► Design Goals: Simplicity and extensibility ► Goals attempted through omission of features “often found in distributed systems”, including  “Reliability”  “Security”  “Correlation”  “Routing”  “Message Exchange Patterns” (MEPs) ► Only two in SOAP 1.2 Spec  Many features can be defined, also through extensions by other specs, implementations, open ended

SOAP Background ► “Designed by Dave Winer, Don Box, Bob Atkinson, and Mohsen Al-Ghosein in 1998” with Microsoft support ► “as an object-access protocol” ► “The SOAP specification is currently maintained by the XML Protocol Working Group of the World Wide Web Consortium.” XML Protocol Working GroupWorld Wide Web ConsortiumXML Protocol Working GroupWorld Wide Web Consortium

Transport ► RPC XML capability using XML and HTTP ► “SOAP works well with network firewalls” firewalls ► “A major advantage over other distributed protocols like GIOP/IIOP or DCOM which are normally filtered by firewalls” GIOPIIOPDCOMGIOPIIOPDCOM ► “XML as the standard message format” ► Given “its widespread use by major corporations and open source development efforts“ open sourceopen source ► The lengthy XML syntax can be both a benefit and a drawback.

Transport Weaknesses ► Its format is possible for humans to read, but can be complex and can have slow processing times ► Lengthy XML format, SOAP can be slower than competing middleware technologies such as CORBA. middlewareCORBA middlewareCORBA ► “For example, CORBA, GIOP and DCOM use much shorter, binary message formats” CORBA ► However “hardware appliances are available to accelerate processing of XML messages” ► “Binary XML is also being explored as a means for streamlining the throughput requirements of XML...“ Binary XMLBinary XML ► Dependence on Web Services Description Language, (WSDL) Web Services Description LanguageWeb Services Description Language ► “no standard way to dynamically discover the services (methods, parameters) offered, nor to get a WSDL for a particular endpoint.” WSDL ► (

Data Encapsulation ► A SOAP message, the Basic Unit of Communication ► A Required Envelope element that “identifies the XML document as a SOAP”  A [local name] of Envelope.  A [namespace name] of "  Zero or more namespace qualified attribute information items amongst its [attributes] property. ► An optional header, must be directly after the envelope ► A required body containing the “element information items”  Targeted at a SOAP reciever in the message path ► An optional fault element  A mandatory Code element information item  A mandatory Reason element information item ► Human readable reason for fault  Optional Role element information item ► Role the node was operating in at the point the fault occurred  Optional Detail element information item ► intended for carrying application specific error information related to the SOAP Body. ► To SOAP, a URI is simply a formatted string that identifies a web resource via its name, location, or any other characteristics.

Sample Fault Message

SOAP and WSDL ► Web Service Definition Language  XML to define the public interface to a SOAP web service  Whereas RMI can look up the name of a service in the registry, SOAP can find the public interface in a web accessible WSDL file  In Axis2 WSDLs can be used to generate a skeleton  JWSDL Java API for manipulating WSDL  Apache proposing its own version Woden

WSDL ► Requestor locates WSDL document on the server ► Downloaded to the requestor ► WSDL examined by the requestor, based upon what is found a SOAP request or requests (invocation) is sent out to the Web service provider

WSDL Document ► Describes the services, where it can be located, instructions on how to bind and run ► Can be retrieved from a UDDI directory, HTTP requests, or even ► The web service itself ► How info will be passed ► Describe the operations ► Describes the location ► My first service ► My first service

WSDL Example Snippet </complexType></element> <complexType> </complexType></element></schema></types> </message> </message>

Sending and Receiving Elements ► SOAP Sender ► SOAP Receiver ► SOAP message path ► SOAP intermediary  Both a receiver and sender target-able from a SOAP message  Processes header blocks and forwards message to a ► Ultimate SOAP receiver

SOAP Defined Message Exchange Patterns ► Request-Response Message Exchange Pattern  Details of which left to the implementer (synchronous, asynchronous, etc) ► SOAP Response Message Exchange Pattern  non-SOAP (no envelope) message acting as a request followed by a SOAP message acting as a response.

Axis2 Implemented Message Patterns ► Flexibility to support multiple exchange patterns ► Reflects the fact that web services moving from mostly synchronous-RPC style interactions to a message-oriented approach ► Encourages both synchronous and asynchronous interactions.

Why is SOAP message-level security needed? ► No security is required in either HTTP, XML, or SOAP ► One major motivation for SOAP is its ability to get through firewalls ► When there are already transport layer security mechanisms such as SSL/TLS and IPSec ► End-to-end Security  A SOAP message may go to intermediate nodes  An intermediate node can receive and transmit  Secure transport protocols such as SSL/TLS can assure the security of messages during transmission  secure end-to-end communication is not possible if intermediaries not trusted  Also compromised if any communication link is not secured

Securing SOAP ► Need application layer security ► Any point where messages are in plain text, it can be a potential point of attack ► Difficult to integrate cryptographic functionality without introducing more security holes ► Commercial cryptographic libraries are usually extremely flexible to meet many different levels of security requirements ► Using them properly may require good understanding of cryptographic technologies ► Often desirable to have security functionality as close to the application level as possible but not built into the application itself.

Transport Independence ► An intended use of SOAP intermediaries is to forward messages to different networks, often using different transport protocols ► Even if links are secured and the intermediaries can be trusted  security information needs to be translated to the next secure transport protocol along the message path  Could be tedious and complex, which may lead to security breaches  such as the authenticity of the originator of the message

Securing SOAP

Security of Stored Messages ► Transport layer security secures data when it is traveling on communication links ► It has no effect on stored data ► Once a transmission is received and decrypted, transport layer security does not help much ► Where messages are stored and then forwarded, message layer security is necessary ► Applications messages are often stored for logging and auditing purposes ► Having cryptographic protection on such persistent data may be necessary anyway SOAP security extensions proposed here can be used for this purpose as well.

Digital Signatures ► W3C submission defines a security Digital Signature header syntax ► digital signatures alone do not provide message authentication ► must be combined with means to ensure the uniqueness of the message, such as nonces or time stamps

Web Services Security Model ► Defined by OASIS to secure SOAP ► Through message integrity, message confidentiality, and single message authentication ► Mechanisms can be combined to allow a wide variety of security models using a variety of cryptographic technologies ► Also provides a general-purpose mechanism for associating security tokens with messages ► Describes how to encode Username Tokens, X.509 Tokens, SAML Tokens, REL Tokens and Kerberos Tokens ► Message integrity is provided by leveraging XML Signature and security tokens to ensure that messages have originated from the appropriate sender and were not modified in transit ► Message confidentiality leverages XML Encryption and security tokens to keep portions of a SOAP message confidential

WS Security Model ► Security Tokens  Authority can sign/encrypt token, X.509 Cert  Signatures verify message origin and integrity  Additional measures needed to protect against attacks  Security context must be understood  Certificate evaluation must be incorporated for digital signatures

Conclusions ► SOAP is an effective and flexible distributed communications specification ► There are many security concerns which must be carefully considered within the application context ► Issues ironically rise out of the firewall traversing use of HTTP

References ► What's New in SOAP 1.2 ► 02.html 02.html 02.html ► SOAP 1.1, 1.2 ► 02.html 02.html 02.html ► ► Java APIs for WSDL: ► An inside look at WSDL ► ► Web Services Description Language W3C Note ► ► Introduction to Apache Axis 2 ► ► Axis2 Users’ Guide ► ► SOAP Security Extensions: Digital Signature ► ► Web Services Security ►