1 / 20

An Analysis of SOAP Security

An Analysis of SOAP Security. Vinod Pandarinathan Vijay Asokan Parthiv Nayak. Agenda. Introduction Skeleton SOAP Message SOAP Message Format and Transmission Why Message Layer Security? CIA in MLS Current Problems and Trends Conclusion ???. Introduction. SOAP 1.1

kim
Download Presentation

An Analysis of SOAP Security

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. An Analysis of SOAP Security Vinod Pandarinathan Vijay Asokan Parthiv Nayak

  2. Agenda • Introduction • Skeleton SOAP Message • SOAP Message Format and Transmission • Why Message Layer Security? • CIA in MLS • Current Problems and Trends • Conclusion • ???

  3. Introduction • SOAP 1.1 • Simple Object Access Protocol • SOAP 1.2 • A “wrapper” protocol • Written in XML • Independent of Platform, OS, Programming Language • Independent of the wrapped data • Independent of the transport protocol • A uni-directional message exchange paradigm • Simple and Extensible • N4S - http://www.w3schools.com/SOAP/soap_intro.asp

  4. SOAP Header Header Block ... Header Block SOAP Body Body Block ... Body Block SOAP Envelope Skeleton SOAP Message <?xml version="1.0"?> <soap:Envelope xmlns:soap=http://www.w3.org/2001/12/soap-envelope soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> <soap:Header> ... ... </soap:Header> <soap:Body> ... ... <soap:Fault> ... ... </soap:Fault> </soap:Body> </soap:Envelope> - http://www.w3schools.com/SOAP/soap_intro.asp

  5. HTTP Request HTTP Body XML Syntax SOAP Envelope SOAP Body SOAP Body Block Textual Integer Receiver Sender 0x0b66 Message Transmission • Typical Binding - Serl.cs.colorado.edu/downloads/serl-talks/2002.02.04-SOAP.ppt

  6. Uni-directional Exchange Intermediary Intermediary Intermediary InitialSender UltimateReceiver - Serl.cs.colorado.edu/downloads/serl-talks/2002.02.04-SOAP.ppt

  7. Bi-directional Exchange Series Intermediary InitialSender UltimateReceiver - Serl.cs.colorado.edu/downloads/serl-talks/2002.02.04-SOAP.ppt

  8. Remote Procedure Call To invoke a SOAP RPC, the following information is needed: • The address of the target SOAP node. • The procedure or method name. • The identities and values of any arguments to be passed to the procedure or method together with any output parameters and return value. • A clear separation of the arguments used to identify the Web resource which is the actual target for the RPC, as contrasted with those that convey data or control information used for processing the call by the target resource. • The message exchange pattern which will be employed to convey the RPC, together with an identification of the so-called "Web Method" (on which more later) to be used. • Optionally, data which may be carried as a part of SOAP header blocks. - Serl.cs.colorado.edu/downloads/serl-talks/2002.02.04-SOAP.ppt

  9. Example Request Code <?xml version='1.0' ?> <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope" > <env:Header> <t:transaction xmlns:t="http://thirdparty.example.org/transaction" env:encodingStyle="http://example.com/encoding" env:mustUnderstand="true" >5</t:transaction> </env:Header> <env:Body> <m:chargeReservation env:encodingStyle="http://www.w3.org/2003/05/soap-encoding" xmlns:m="http://www.southwest.com/"> <m:reservation xmlns:m="http:// www.southwest.com/reservation"> <m:code>AB123CD</m:code> </m:reservation> <o:creditCard xmlns:o="http://www.visa.com/financial"> <n:name xmlns:n="http://www.visa.com/employees"> Parthiv Nayak </n:name> <o:number>1234567890123456</o:number> <o:ccv>123</o:ccv> <o:expiration>12/12</o:expiration> </o:creditCard> </m:chargeReservation> </env:Body> </env:Envelope> - http://www.w3.org/TR/soap12-part0/#L1185

  10. Example Response Code <?xml version='1.0' ?> <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope" > <env:Header> <t:transaction xmlns:t="http://thirdparty.example.org/transaction" env:encodingStyle="http://example.com/encoding" env:mustUnderstand="true">5</t:transaction> </env:Header> <env:Body> <m:chargeReservationResponse env:encodingStyle="http://www.w3.org/2003/05/soap-encoding" xmlns:m="http://www.southwest.com/"> <m:code>AB123CD</m:code> <m:viewAt> http://www.southwest.com/reservations?code=AB123CD </m:viewAt> </m:chargeReservationResponse> </env:Body> </env:Envelope> - http://www.w3.org/TR/soap12-part0/#L1185

  11. Message Layer Security • Why do we need another layer of security ? • End to end security • Transport layer independence • Common Infrastructure • Security for stored messages

  12. Confidentiality with MLS <SOAP-SEC:Encryption xmlns:SOAP-SEC="http://schemas.xmlsoap.org/soap/security/"> <xenc:DecryptionInfo Id="decInfo1" xmlns:xenc="http://www.w3.org/2000/10/xmlenc"> <xenc:Method Algorithm="http://www.w3.org/2000/10/xmlenc#des-cbc-pkcs5padding"/> <xenc:ReferenceList> <xenc:Reference URI="#encData1"/> </xenc:ReferenceList> </xenc:DecryptionInfo> </SOAP-SEC:Encryption> <xenc:EncryptedData xmlns:xenc="http://www.w3.org/2000/10/xmlenc" Id="encData1" DecryptionInfoURI="#decInfo1"IV="x40tN1mAZSY="> 0rqGM/nMhGNHY0U6ZhbkuPDEpYaqD/nwqtt0iw361RLeVGvJgn37GeNkdaVY+JizNWsqR//TDeOG= </xenc:EncryptedData>

  13. Authentication - Digitally signed messages <SOAP-ENV:Header> <SOAP-SEC:Signature xmlns:SOAP-SEC=http://schemas.xmlsoap.org/soap/security/ SOAP-ENV:actor="urn:validator" SOAP-ENV:mustUnderstand="1"> <ds:Signature Id="MyFirstSignature" xmlns:ds="http://www.w3.org/2000/02/xmldsig#"> <ds:SignedInfo> <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1"/> <ds:Reference URI="#Body"> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue>MC0CFFrVLtRlk=...</ds:SignatureValue> </ds:Signature> </SOAP-SEC:Signature> </SOAP-ENV:Header>

  14. Authorization - MLS <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Header> <SOAP-SEC:Authorization xmlns:SOAP-SEC=http://schemas.xmlsoap.org/soap/security/ SOAP-ENV:actor="a URI of an actor“ SOAP-ENV:mustUnderstand="1"> <AttributeCert> …… </AttributeCert> </SOAP-SEC:Authorization> </SOAP-ENV:Header> <SOAP-ENV:Body> </SOAP-ENV:Body></SOAP-ENV:Envelope>

  15. Current Problem • SOAP uses HTTP,and can transfer binart files • HTTP traffic is not blocked by Firewalls • Network Security is breached. "SOAP goes through firewalls like a knife through butter." -http://www.prescod.net/rest/security.html Possible Solution: • Parsing XML data. • CPU intensive, and lower performance. • Also hard to find patterns because of XML’s dynamic nature.

  16. Current Trend • Axis 2 – Apache Software Foundation Provides web service engines designed for SOAP and XML with emphasis on security, and modularization. http://ws.apache.org/axis2/1_2/userguide.html#handlessoap

  17. Cont… • SOAP Security Extensions - W3C Provides SOAP Security Extensions. Currently we have the “SOAP Security Extensions: Digital Signatures” • WS-Security (Web Service Security) - OASIS Provides the mechanism for Security tokens within SOAP messages, and also detail the use of Kerberos, X.509 certificate with SOAP.

  18. Cont… Current Goal of OASIS (http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf): • Multiple security token formats • Multiple trust domains • Multiple signature formats • Multiple encryption technologies • End-to-end message content security and not just transport-level security The OASIS consortium would come up with the security guidelines, and after an approval/ implementation phases would ratify it as a standard.

  19. Conclusion • SOAP is new. • More standardization required. • Needs modularization is security. • Going in the right direction.

  20. We hope NOT!!! ;-)

More Related