securing web services is/cs 698 min song. a list of web services i a) core service architecture ...

27
Securing Web Services IS/CS 698 Min Song

Upload: desiree-cramer

Post on 14-Dec-2015

212 views

Category:

Documents


0 download

TRANSCRIPT

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, and WS-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-CF and WS-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

OWL Web 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) May 2004

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 Message Structure

SOAP Headeroptional

SOAP Body

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 protocolGET /mysoapserv/ HTTP/1.1Host: www.mysoap.orgSOAPAction: “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.

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>

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

<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: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>

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