Securing Web Services - PowerPoint PPT Presentation

securing web services n.
Skip this Video
Loading SlideShow in 5 Seconds..
Securing Web Services PowerPoint Presentation
Download Presentation
Securing Web Services

play fullscreen
1 / 27
Download Presentation
Presentation Description
Download Presentation

Securing Web Services

- - - - - - - - - - - - - - - - - - - - - - - - - - - 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 ( • 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 ( • C#: • WSE 2.0 ( • WSRF.Net ( • Perl : • WS-Security will be supported by WSRF::Lite (but not yet) ( • Python: • pyGridWare (

  12. SOAP Header optional SOAP Body SOAP Message Structure SOAP Envelope <env:Envelope xmlns:env=“”> …. Rest of the SOAP message … </env:Envelope>

  13. SOAP Header <env:Envelope xmlns:env=“”> <env:Header> <mysoap:transaction xmlns:mysoap=“”> 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=“”> <env:Body> <mysoap:getBalance xmlns:mysoap=“” env:encodingStyle=“”> <accountNumber>567-89-0123</accountNumber> </mysoap:getBalance> </env:Body> </env:Envelope>

  15. SOAP Body - Response • RPC mechanism: method return <env:Envelope xmlns:env=“”> <env:Body> <mysoap:getBalanceResponse xmlns:mysoap=“” env:encodingStyle=“”> <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=“” targetNamespace=“”> <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: SOAPAction: “HTTP://” <env:Envelope xmlns:env=“”> <env:Body> <mysoap:getBalanceResponse xmlns:mysoap=“” env:encodingStyle=“”> <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=""> </ds:CanonicalizationMethod> <ds:SignatureMethod Algorithm=""/> <ds:Reference URI="#Body"> <ds:Transforms> <ds:Transform Algorithm=""/> </ds:Transforms> <ds:DigestMethod Algorithm=""/> <ds:DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</ds:DigestValue> </ds:Reference> </ds:SignedInfo> <SOAP-ENV:Header> <SOAP-SEC:Signature xmlns:SOAP-SEC="" SOAP-ENV:actor="some-URI“ SOAP-ENV:mustUnderstand="1"> <ds:Signature xmlns:ds=""> <ds:SignedInfo> … </ds:SignedInfo> <ds:SignatureValue>MC0CFFrVLtRlk=...</ds:SignatureValue> </ds:Signature> </SOAP-SEC:Signature> </SOAP-ENV:Header> <SOAP-ENV:Body xmlns:SOAP-SEC="" 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=""> <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