Secure Web Services Arvind Easwaran CIS/TCOM 551 Spring 2004 Slide Set 7

Outline Web Services (WS): An overview Web Services (WS): An overview XML Basics XML Basics SOAP Basics SOAP Basics WS The real one WS The real one Security in WS Security in WS

Web Services (WS) Overview

Today’s Web Designed for applications involving human interactions Designed for applications involving human interactions Intended purpose Intended purpose –Information sharing: a distributed content library –Enabled B2C e-commerce –Non-automated B2B interactions How did it happen? How did it happen? –Built on very few standards: http + html –Shallow interaction model: very few assumptions –Result was ubiquity

What’s next? There is a lot more we can do ! There is a lot more we can do ! –Open, automated B2B e-commerce –Business process integration on the Web –Resource sharing, distributed computing Existing Web technology is ad hoc for this Existing Web technology is ad hoc for this –Application-to-application interactions with HTML forms Goal Goal Enabling systematic application-to- application interaction on the Web

Web Services “Web services” is an effort to build a distributed computing platform for the Web “Web services” is an effort to build a distributed computing platform for the Web Web service applications are encapsulated, loosely coupled Web “components” that can bind dynamically to each other The Penn – Amazon example

Typical Web Service Components

SOAP Web Services consumers send and receive SOAP messages Web Services consumers send and receive SOAP messages WSDL Web Services Description Language Web Services are defined in terms of the formats and ordering of messages Web Services are defined in terms of the formats and ordering of messages Built using open Internet protocols Built using open Internet protocols XML & HTTP Web Services Architecture A programmable application component accessible via standard Web protocols Open Internet Protocols Web Service UDDI Universal Description, Discovery, and Integration Provide a Directory of Services on the Internet Provide a Directory of Services on the Internet

Web Services Framework Framework can be described in terms of Framework can be described in terms of –What goes “on the wire” Formats and protocols : XML and SOAP using HTTP –What describes what goes on the wire Description languages : WSDL –What allows us to find these descriptions Discovery of services : UDDI

XML

What is XML? Extensible Markup Language Extensible Markup Language Meta language that Meta language that –Allows to create and format own document markups a method for putting structured data into a text file a method for putting structured data into a text file - easy to read - unambiguous - extensible - platform-independent

Sample XML Example <msg:text> Hi please bill to the following address </msg:text><msg:item> Skateboard Skateboard One Warehouse Park One Warehouse Park Boston Boston </msg:message>

XML Declaration the XML declaration the XML declaration –Not required, but typically used –Attributes include:  Version  Encoding – the character encoding

XML Element <msg:text> Hi please bill the following </msg:text><msg:item> … </msg:message> text/element an element text/element an element Each element tag can be divided into 2 parts  Namespace, Tag name Each element tag can be divided into 2 parts  Namespace, Tag name

XML Attribute … … </msg:message> XML Attribute XML Attribute –Describes additional information about an element – text – text –Reserved attribute  xml:lang

XML Namespaces …</msg:message> Namespaces Namespaces –Not mandatory, but useful in giving uniqueness to an element –Declared using the xmlns:name= “value”

SOAP

SOAP An XML envelope for XML messaging An XML envelope for XML messaging Headers + body Headers + body SOAP is “transport independent” SOAP is “transport independent” A convention for doing RPC A convention for doing RPC

Soap Message Processing

SOAP Message Example Very High </SOAP-ENV:Header><SOAP-ENV:Body> “XML Document” </SOAP-ENV:Envelope>

WS Carl Gunter Kevin Lux Michael May

WS Traditional Internet Traditional Internet –Based on a collection of protocols  SMTP, POP, IMAP –Evolved over a vast installed base –Shortcomings  Flexibility  Security and  Integration

WS The Solution Aims to exploit advantages of web service protocols Aims to exploit advantages of web service protocols Uses web service security features to support integrity, authentication, and access control for both end-to-end and hop-by-hop message transmissions Uses web service security features to support integrity, authentication, and access control for both end-to-end and hop-by-hop message transmissions A collection of services that can be added to the base system A collection of services that can be added to the base system

The Solution (Contd) A way to integrate different messaging systems A way to integrate different messaging systems Prototype system is built using Microsoft.Net Prototype system is built using Microsoft.Net On-demand attachments On-demand attachments Integrated instant messaging Integrated instant messaging

Architecture

Architecture (Contd) Sender Client SC makes a call on its Sender Server SS Sender Client SC makes a call on its Sender Server SS All calls are SOAP calls over TCP All calls are SOAP calls over TCP The server SS then makes a call on the Receiver Server RS The server SS then makes a call on the Receiver Server RS The Receiver Client RC periodically makes calls to RC The Receiver Client RC periodically makes calls to RC Security based on standards for web service security possibly supported by encrypted tunnels Security based on standards for web service security possibly supported by encrypted tunnels

Architecture (Contd) Hop-by-hop confidentiality, so communications between the nodes can be protected by TLS Hop-by-hop confidentiality, so communications between the nodes can be protected by TLS Clients like SC and RC are typically authenticated by a password Clients like SC and RC are typically authenticated by a password Servers authenticate themselves using certificates Servers authenticate themselves using certificates Such certificates are used in TLS and used to sign messages using XMLDSIG Such certificates are used in TLS and used to sign messages using XMLDSIG

Variations – Security Token

Security Token (Contd) SC contacts SS to obtain a security token recognized by RS SC contacts SS to obtain a security token recognized by RS SC sends a message authenticated with this credential to RS SC sends a message authenticated with this credential to RS Instant messages are posted directly to the client Instant messages are posted directly to the client RS and RC apply access control for this function based on the security token from SC RS and RC apply access control for this function based on the security token from SC Token is recognized because of a form of federated identity between SS and RS Token is recognized because of a form of federated identity between SS and RS

Security

Why Web Services Security is a Challenge Theory: This thing has 4 wheel drive But we only take it to the Mall Practice: In this environment we need 4 wheel drive

Message Level Security

Example : SC to SS <wsse:Security SOAP-ENV:mustUnderstand="1“ SOAP-ENV:actor=“…” xmlns:wsse=“…"> SOAP-ENV:actor=“…” xmlns:wsse=“…"> <wsse:UsernameToken xmlns:wsu=“…“ wsu:Id="SecurityToken…"> wsu:Id="SecurityToken…"><wsse:Username>SC</wsse:Username> … … Date Date

<Signature><SignedInfo> <DigestValue>…</DigestValue></Reference></SignedInfo>

<SignatureValue>…</SignatureValue> </Signature></wsse:Security>

Canonicalization Logically equivalent physically different XML snippets Logically equivalent physically different XML snippets – –

XML Element Specific Security <ds:KeyInfo> Shared Key Shared Key </ds:KeyInfo><enc:CipherData>…</enc:CipherData></enc:EncryptedData>…</po>

XML Key Management Specification (XKMS) Management of Public Keys Management of Public Keys –Registration  Alice registers her signature public key –Information  Bob looks up the key for Alice  Bob checks to see if it is valid Core Objective Core Objective –Shield the client from the complexity of PKI

Platform Level Security

Security Terminology Authentication Authentication –Positively identifying the clients –User ID password pairs, X509 certificate etc Authorization Authorization –Defining what authenticated clients are allowed to see and do –ACLs Non Repudiation Non Repudiation –Digital Signatures Secure Communication Secure Communication –Ensuring that messages remain private and unaltered as they cross networks –SSL point-to-point

Is SSL Alone Enough? For some applications  Yes For some applications  Yes As Infrastructure  No As Infrastructure  No  SSL does not support multi-party transactions –Intermediate Node  SSL does not support non-Repudiation  Does not leave any audit trail

Demo

Conclusions Without Security and Trust Without Security and Trust –Web Services are Dead On Arrival Considerable progress has already been made Considerable progress has already been made –Industry wide consensus on value of standards –Basic Infrastructure is in place or in development –There is considerable consensus on the roadmap –Web Services is certainly moving towards a secure architecture