270 likes | 421 Views
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
E N D
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 • 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
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
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
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
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
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
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…
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)
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
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/)
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>
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>
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>
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>
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>
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.
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
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.
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.
<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>
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
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
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”
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
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
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