Secure Web Services Arvind Easwaran arvinde seas CIS TCOM 551

Secure Web Services Arvind Easwaran (arvinde@seas) CIS/TCOM 551 Spring 2004 Slide Set 7

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

Web Services (WS) Overview

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

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

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

Typical Web Service Components

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

Web Services Framework n 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 n Meta language that n – Allows to create and format own document markups n a method for putting structured data into a text file - easy to read - unambiguous - extensible - platform-independent

Sample XML Example <? xml version=“ 1. 0” encoding=“…”? > <msg: message from=“id” to=“id” xmlns: msg=“URI” xmlns: po=“URI”> <msg: text> Hi please bill to the following address </msg: text> <msg: item> <po: po id=“ 123”> <po: billto> <po: company> Skateboard </po: company> <po: street> One Warehouse Park </po: street> <po: city> Boston </po: city> </po: billto> </po: po> </msg: item> </msg: message>

XML Declaration <? xml version=“ 1. 0” encoding=“…”? > n <? xml ? > the XML declaration – Not required, but typically used – Attributes include: § Version § Encoding – the character encoding

XML Element <msg: message from=“id” to=“id” xmlns: msg=“URI” xmlns: po=“URI”> <msg: text> Hi please bill the following </msg: text> <msg: item> <po: po id=“ 123”> … </po: po> </msg: item> </msg: message> n n <tag> text/element </tag> an element Each element tag can be divided into 2 parts Namespace, Tag name

XML Attribute <msg: message from=“id” to=“id” xmlns: msg=“URI” xmlns: po=“URI”> … <po: po id=“ 123”> … </po: po> </msg: message> n XML Attribute – Describes additional information about an element – <tag key=”value”> text</tag> – Reserved attribute xml: lang

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

SOAP

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

Soap Message Processing

SOAP Message Example <? xml … ? > <SOAP-ENV: Envelope xmlns: SOAP-ENV=“URI” > <SOAP-ENV: Header> <t: Transaction xmlns: t=“URI” SOAP-ENV: must. Understand=“ 1” > 12345 </t: Transaction> <p: Priority xmlns: p=“URI”> Very High </p: Priority> </SOAP-ENV: Header> <SOAP-ENV: Body> “XML Document” </SOAP-ENV: Body> </SOAP-ENV: Envelope>

WSEmail Carl Gunter Kevin Lux Michael May

WSEmail n Traditional Internet Email – Based on a collection of protocols § SMTP, POP, IMAP – Evolved over a vast installed base – Shortcomings § Flexibility § Security and § Integration

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

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

Architecture

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

Architecture (Contd) n n 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 Servers authenticate themselves using certificates Such certificates are used in TLS and used to sign messages using XMLDSIG

Variations – Security Token

Security Token (Contd) n n n SC contacts SS to obtain a security token recognized by RS SC sends a message authenticated with this credential to RS Instant messages are posted directly to the client 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

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: must. Understand="1“ SOAP-ENV: actor=“…” xmlns: wsse=“…"> <wsse: Username. Token xmlns: wsu=“…“ wsu: Id="Security. Token…"> <wsse: Username>SC</wsse: Username> <wsse: Nonce>…</wsse: Nonce> <wsu: Created>Date</wsu: Created> </wsse: Username. Token>

<Signature. Value>…</Signature. Value> <Key. Info> <wsse: Security. Token. Reference> <wsse: Reference URI=“…" /> </wsse: Security. Token. Reference> </Key. Info> </Signature> </wsse: Security>

Canonicalization n Logically equivalent physically different XML snippets – <p a=“ 1” b=“ 2”> </p> – <p a=“ 1” b=“ 2” />

XML Element Specific Security <po xmlns=“URI” id=“ 123”> <enc: Encrypted. Data Type=“URI”> <enc: Encryption. Method Algorithm=“…”/> <ds: Key. Info> <ds: Key. Name> Shared Key </ds: Key. Name> </ds: Key. Info> <enc: Cipher. Data>…</enc: Cipher. Data> </enc: Encrypted. Data> … </po>

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

Platform Level Security

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

Is SSL Alone Enough? n For n As some applications Yes 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 n Without Security and Trust – Web Services are Dead On Arrival n 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