1 / 24

SOAP “ Simple” Object Access Protocol

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)

meg
Télécharger la présentation

SOAP “ Simple” Object Access Protocol

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  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

  3. 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.”

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

  5. 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. • “For example, CORBA, GIOP and DCOM use much shorter, binary message formats” • 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...“ • Dependence on Web Services Description Language, (WSDL) • “no standard way to dynamically discover the services (methods, parameters) offered, nor to get a WSDL for a particular endpoint.” • (http://en.wikipedia.org/wiki/SOAP)

  6. 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 "http://www.w3.org/2003/05/soap-envelope". • 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.

  7. Sample Fault Message

  8. 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

  9. 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

  10. 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 email • <type> <message> The web service itself • <binding> How info will be passed • <portType> Describe the operations • <service> Describes the location • <service name="StockQuoteService"> <documentation>My first service</documentation> <port name="StockQuotePort" binding="tns:StockQuoteBinding"> <soap:address location="http://example.com/stockquote"/> </port> </service>

  11. WSDL Example Snippet <definitions name="StockQuote“> <types> <schema targetNamespace="http://example.com/stockquote.xsd" xmlns="http://www.w3.org/2000/10/XMLSchema"> <element name="TradePriceRequest"> <complexType> <all> <element name="tickerSymbol" type="string"/> </all> </complexType> </element> <element name="TradePrice"> <complexType> <all> <element name="price" type="float"/> </all> </complexType> </element> </schema> </types> <message name="GetLastTradePriceInput"> <part name="body" element="xsd1:TradePriceRequest"/> </message> <message name="GetLastTradePriceOutput"> <part name="body" element="xsd1:TradePrice"/> </message>

  12. 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

  13. 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.

  14. 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.

  15. 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

  16. 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.

  17. 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

  18. Securing SOAP

  19. 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.

  20. 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

  21. 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

  22. 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

  23. 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

  24. References • What's New in SOAP 1.2 • http://www.idealliance.org/papers/xmle02/dx_xmle02/papers/02-02-02/02-02-02.html • SOAP 1.1, 1.2 • http://www.idealliance.org/papers/xmle02/dx_xmle02/papers/02-02-02/02-02-02.html • http://www.w3.org/TR/2003/REC-soap12-part1-20030624/ • Java APIs for WSDL: http://jcp.org/aboutJava/communityprocess/mrel/jsr110/index2.html • An inside look at WSDL • http://searchwebservices.techtarget.com/tip/1,289483,sid26_gci811272,00.html • Web Services Description Language W3C Note • http://www.w3.org/TR/wsdl • Introduction to Apache Axis 2 • http://www.redhat.com/magazine/021jul06/features/apache_axis2/ • Axis2 Users’ Guide • http://ws.apache.org/axis2/1_0/userguide3.html • SOAP Security Extensions: Digital Signature • http://www.w3.org/TR/SOAP-dsig/ • Web Services Security • http://www-128.ibm.com/developerworks/library/specification/ws-secure/

More Related