1 / 27

Securing Web Services

Securing Web Services. IS/CS 698 Min Song. A List of Web Services I. a) Core Service Architecture XSD: XML Schema (W3C Recommendation) V1.0 February 1998, V1.1 February 2004 WSDL 1.1: Web Services Description Language Version 1.1, (W3C note) March 2001

byron-gay
Télécharger la présentation

Securing Web Services

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. Securing Web Services IS/CS 698 Min Song

  2. A List of Web Services I • a) Core Service Architecture • XSD: XML Schema (W3C Recommendation) V1.0 February 1998, V1.1 February 2004 • WSDL 1.1: Web Services Description Language Version 1.1, (W3C note) March 2001 • WSDL 2.0: Web Services Description Language Version 2.0, (W3C under development) March 2004 • SOAP 1.1: (W3C Note) V1.1 Note May 2000 • SOAP 1.2: (W3C Recommendation) June 24 2003 • b) Service Discovery • UDDI:(Broadly Supported OASIS Standard) V3 August 2003 • WS-Discovery: Web services Dynamic Discovery (Microsoft, BEA, Intel …) February 2004 • WS-IL:Web Services Inspection Language, (IBM, Microsoft) November 2001

  3. A List of Web Services II • c) Security • SAML:Security Assertion Markup Language (OASIS) V1.1 May 2004 • XACML: eXtensible Access Control Markup Language (OASIS) V1.0 February 2003 • WS-Security: Web Services Security: SOAP Message Security (OASIS) Standard March 2004 • WS-SecurityPolicy: Web Services Security Policy (IBM, Microsoft, RSA, Verisign) Draft December 2002 • WS-Trust:Web Services Trust Language (BEA, IBM, Microsoft, RSA, Verisign …) May 2004 • WS-SecureConversation: Web Services Secure Conversation Language (BEA, IBM, Microsoft, RSA, Verisign …) May 2004 • WS-Federation:Web Services Federation Language (BEA, IBM, Microsoft, RSA, Verisign) July 2003

  4. A List of Web Services III • d) Messaging • WS-Addressing: Web Services Addressing (BEA, IBM, Microsoft) March 2004 • WS-MessageDelivery: Web Services Message Delivery (W3C Submission by Oracle, Sun ..) April 2004 • WS-Routing: Web Services Routing Protocol (Microsoft) October 2001 • WS-RM: Web Services Reliable Messaging (BEA, IBM, Microsoft, Tibco) v0.992 March 2004 • WS-Reliability: Web Services Reliable Messaging (OASIS Web Services Reliable Messaging TC) March 2004 • SOAP MOTM: SOAP Message Transmission Optimization Mechanism (W3C) June 2004 • e) Notification • WS-Eventing: Web Services Eventing (BEA, Microsoft, TIBCO) January 2004 • WS-Notification: Framework for Web Services Notification with WS-Topics, WS-BaseNotification, andWS-BrokeredNotification (OASIS) OASIS Web Services Notification TC Set up March 2004 • JMS:Java Message Service V1.1 March 2002

  5. A List of Web Services IV • f) Coordination and Workflow, Transactions and Contextualization • WS-CAF:Web Services Composite Application Framework including WS-CTX, WS-CFandWS-TXM below (OASIS Web Services Composite Application Framework TC) July 2003 • WS-CTX:Web Services Context (OASIS Web Services Composite Application Framework TC) V1.0 July 2003 • WS-CF: Web Services Coordination Framework (OASIS Web Services Composite Application Framework TC) V1.0 July 2003 • WS-TXM: Web Services Transaction Management (OASIS Web Services Composite Application Framework TC) V1.0 July 2003 • WS-Coordination: Web Services Coordination (BEA, IBM, Microsoft) September 2003 • WS-AtomicTransaction: Web Services Atomic Transaction (BEA, IBM, Microsoft) September 2003 • WS-BusinessActivity: Web Services Business Activity Framework (BEA, IBM, Microsoft) January 2004 • BTP: Business Transaction Protocol (OASIS) May 2002 with V1.0.9.1 May 2004 • BPEL: Business Process Execution Language for Web Services (OASIS) V1.1 May 2003 • WS-Choreography: (W3C) V1.0 Working Draft April 2004 • WSCI: (W3C) Web Service Choreography Interface V1.0 (W3C Note from BEA, Intalio, SAP, Sun, Yahoo) • WSCL:Web Services Conversation Language (W3C Note) HP March 2002

  6. A List of Web Services V • h) Metadata and State • RDF:Resource Description Framework (W3C) Set of recommendations expanded from original February 1999 standard • DAML+OIL: combining DAML (Darpa Agent Markup Language) and OIL (Ontology Inference Layer) (W3C) Note December 2001 • OWLWeb Ontology Language (W3C) Recommendation February 2004 • WS-DistributedManagement: Web Services Distributed Management Framework with MUWS and MOWS below (OASIS) • WSDM-MUWS: Web Services Distributed Management: Management Using Web Services (OASIS) V0.5 Committee Draft April 2004 • WSDM-MOWS: Web Services Distributed Management: Management of Web Services (OASIS) V0.5 Committee Draft April 2004 • WS-MetadataExchange: Web Services Metadata Exchange (BEA,IBM, Microsoft, SAP) March 2004 • WS-RF:Web Services Resource Framework including WS-ResourceProperties, WS-ResourceLifetime, WS-RenewableReferences, WS-ServiceGroup, and WS-BaseFaults(OASIS) Oasis TC set up April 2004 and V1.1 Framework March 2004 • ASAP: Asynchronous Service Access Protocol (OASIS) with V1.0 working draft G June 2004 • WS-GAF:Web Service Grid Application Framework (Arjuna, Newcastle University) August 2003

  7. A List of Web Services VI • g) General Service Characteristics • WS-Policy: Web Services Policy Framework (BEA, IBM, Microsoft, SAP) May 2003 • WS-PolicyAssertions:Web Services Policy Assertions Language (BEA, IBM, Microsoft, SAP) May 2003 • WS-Agreement: Web Services Agreement Specification (GGF under development) May2004 • i) User Interfaces • WSRP: Web Services for Remote Portlets (OASIS) OASIS Standard August 2003 • JSR168: JSR-000168 Portlet Specification for Java binding (Java Community Process) October 2003

  8. Thoughts • Should we be using standards IF they: • Are new and just emerging, • Are changing frequently, for example UDDI! • Enhance interoperability, but potentially cripple performance, • Are not widely adopted, • Are not easy to understand and complicated to implement. • What are the alternatives? • REST, • Web 2.0…

  9. Security • Transport level (https) • Message level: • End-to-end: allows for unlimited intermediaries • Data origin authentication • Different types of security tokens/credentials: • unsigned (username/password) • binary (X.509 certificate) • XML (SAML token)

  10. WS-Security • OASIS standard (http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss)) • Security token validation (authentication): • validate authentication assertions made by principals • Message integrity (signing): • verify message origin • validate encryption keys • confirm security token claims • Message confidentiality (encryption) • Introduces extra XML into SOAP header

  11. WSS Implementations • Java: • WSS4J (http://ws.apache.org/wss4j) • C#: • WSE 2.0 (http://msdn.microsoft.com/webservices/webservices/building/wse/default.aspx) • WSRF.Net (http://www.cs.virginia.edu/~gsw2c/wsrf.net.html) • Perl : • WS-Security will be supported by WSRF::Lite (but not yet) (http://www.sve.man.ac.uk/Research/AtoZ/ILCT) • Python: • pyGridWare (http://dsd.lbl.gov/gtg/projects/pyGridWare/)

  12. SOAP Header optional SOAP Body SOAP Message Structure SOAP Envelope <env:Envelope xmlns:env=“http://www.w3.org/2001/06/soap-envelope/”> …. Rest of the SOAP message … </env:Envelope>

  13. SOAP Header <env:Envelope xmlns:env=“http://www.w3.org/2001/06/soap-envelope/”> <env:Header> <mysoap:transaction xmlns:mysoap=“http://www.mysoap.org/soap/”> transaction data </mysoap:transaction> </env:Header> … rest of the SOAP message - the SOAP body </env:Envelope>

  14. SOAP Body - Request • RPC mechanism: method invocation <env:Envelope xmlns:env=“http://www.w3.org/2001/06/soap-envelope/”> <env:Body> <mysoap:getBalance xmlns:mysoap=“http://www.mysoap.org/soap/financial/” env:encodingStyle=“http://www.w3.org/2001/06/soap-encoding”> <accountNumber>567-89-0123</accountNumber> </mysoap:getBalance> </env:Body> </env:Envelope>

  15. SOAP Body - Response • RPC mechanism: method return <env:Envelope xmlns:env=“http://www.w3.org/2001/06/soap-envelope/”> <env:Body> <mysoap:getBalanceResponse xmlns:mysoap=“http://www.mysoap.org/soap/financial/” env:encodingStyle=“http://www.w3.org/2001/06/soap-encoding”> <balance>3400.00</balance> </mysoap:getBalanceResponse> </env:Body> </env:Envelope>

  16. XML Schema and SOAP Connect an XML Schema document and a SOAP message using namespaces <xsd:schema xmlns:xsd=“http://www.w3.org/2001/XMLSchema” targetNamespace=“http://www.mysoap.org/soap/financial/”> <xsd:element name=“balance” type=“xsd:double”/> <xsd:simpleType name=“accountNumberType”> <xsd:restriction base=“xsd:string”> <xsd:pattern value=“\d{3}-\d{2}-\d{4}”/> </xsd:restriction> </xsd:simpleType> </xsd:schema>

  17. SOAP-HTTP Binding • HTTP “POST” method only • Must label the body (SOAP message) with “application/soap” MIME type • May include a “SOAPAction:” HTTP header in requests • May include a “required-SOAPAction:” HTTP header in responses • Best transport to poke through firewalls.

  18. HTTP and SOAP • SOAP can use any transport protocol GET /mysoapserv/ HTTP/1.1 Host: www.mysoap.org SOAPAction: “HTTP://www.mysoap.org/mysoapserv/” <env:Envelope xmlns:env=“http://www.w3.org/2001/06/soap-envelope/”> <env:Body> <mysoap:getBalanceResponse xmlns:mysoap=“http://www.mysoap.org/soap/financial” env:encodingStyle=“http://www.w3.org/2001/06/soap-encoding”> <balance>3400.00</balance> </mysoap:getBalanceResponse> </env:Body> </env:Envelope> HTTP SOAP Message

  19. SOAP Security Extensions • XML Digital Signatures (SOAP-dsig) • SOAP header carries digital signature information within a SOAP 1.1 Envelope. • Defines <SOAP-SEC:Signature> header entry • C14N of <ds:SignedInfo> MUST be done within its own context.

  20. SOAP Security Extensions • Conforming SOAP Applications must satisfy: • MUST be capable of processing XML Signatures. • <SOAP-SEC:Signature> MUST have a <ds:Signature> element. • All <ds:Reference> elements MUST refer to a valid resource within the SOAP envelope. • If header is processed (mustUnderstand=1), it MUST try to validate the signature.

  21. <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm="http://www.w3.org/TR/2000/CR-xml-c14n-20001026"> </ds:CanonicalizationMethod> <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/> <ds:Reference URI="#Body"> <ds:Transforms> <ds:Transform Algorithm="http://www.w3.org/TR/2000/CR-xml-c14n-20001026"/> </ds:Transforms> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <ds:DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</ds:DigestValue> </ds:Reference> </ds:SignedInfo> <SOAP-ENV:Header> <SOAP-SEC:Signature xmlns:SOAP-SEC="http://schemas.xmlsoap.org/soap/security/2000-12" SOAP-ENV:actor="some-URI“ SOAP-ENV:mustUnderstand="1"> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:SignedInfo> … </ds:SignedInfo> <ds:SignatureValue>MC0CFFrVLtRlk=...</ds:SignatureValue> </ds:Signature> </SOAP-SEC:Signature> </SOAP-ENV:Header> <SOAP-ENV:Body xmlns:SOAP-SEC="http://schemas.xmlsoap.org/soap/security/2000-12" SOAP-SEC:id="Body"> <m:GetLastTradePrice xmlns:m="some-URI"> <m:symbol>IBM</m:symbol> </m:GetLastTradePrice> </SOAP-ENV:Body> Example : SOAP Signature <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Header> … </SOAP-ENV:Header> <SOAP-ENV:Body …> … </SOAP-ENV:Body> </SOAP-ENV:Envelope>

  22. Web Services security challenges • Three main challenges: • Challenge of security based on the end user of a Web Service • Challenge of maintaining security while routing between multiple Web Services • Challenge of abstracting security from the underlying network

  23. Challenge of security based on the end user of a Web Service • SOAP is a technology used to enable one piece of software to easily “talk” to another • E.g. a person making a reservation logs on to a travel site, but actual reservation is done through SOAP to reservation back-end • Challenge: Single sign-on

  24. Challenge of maintaining security while routing between multiple Web Services • WS-Routing: how to insert routing information into the header of a SOAP message • WS-Routing means that a SOAP message may traverse multiple SOAP “hops” • Such hops may disclose information of the SOAP message, because it’s only encrypted at transport level, forming a so-called SOAP “gap” • Challenge: How to get rid of the “SOAP gap”

  25. Challenge of abstracting security from the underlying network • The term “Web” services is actually misleading: • Web services is not reliant on HTTP alone • SOAP messages can be sent using other protocols • Web services security, therefore, cannot rely on Web security alone • Challenge: HTTP-independent Web services security

  26. Meeting the new challenges: New technologies • Including XML-formatted security data in SOAP messages (WS-Security) • WS-Security: defines “placeholders” for security data in SOAP header; adds encryption & signatures to SOAP • Confidentiality for Web services (XML Encryption) • Specification of the W3C • Can actually encrypt any data, but stored in XML format • Not a replacement for SSL; not new algorithms

  27. Web services security threats • Web application security threats • SQL Attacks • Directory traversal attacks • URL string attacks • “SOAP bypasses firewalls” • SOAP travels through normal HTTP port 80

More Related