T-110.455 Network Application Frameworks and XML Summary and Conclusions 27.04.2005 Sasu Tarkoma

T-110.455 Network Application Frameworks and XML

Summary and Conclusions

27.04.2005

Sasu Tarkoma

Topics Covered

Distributed systems security Multi-addressing: Mobility and multi-

homing Building applications with XML

Distributed objects Role of directory services Mobile and wireless applications XML-based presentation and RPC

Scalability and performance issues

Lecture Outline

Note: starts 16.00

Interconnections

Interconnections applicable on many levels Network-level operation

DNS, overlay lookup, IPsec Application-level operation

UDDI, SSL, WS-Security

Network Security

DirectoriesObjects

Mobility and Routing

Naming, Addressing, and Routing

NAMING

ADDRESSING ROUTING

How to identify and name a node?

Frequent updates?

One or two new name spaces?

Where is the node located?

Differences (IPv4/IPv6)

Multi-addressing?

How to route information to the node’s address? NAT traversal?

Overlay vs. network routing

unicast: to a specific nodebroadcast: to all nodesmulticast: to a subset of nodesanycast: to any one in some subset (IPv6)

TCP/IP Network Stack

Networking Layer (IP)Networking Layer (IP)

Transport Layer (TCP/UDP)Transport Layer (TCP/UDP)

Application LayerApplication Layer

Underlying network (link layer)Underlying network (link layer)

host-to-host transportreliability, congestion control,

flow control

host-to-host connectivityrouting, addressing

Link layer: local data transfer,encoding, framing, error correction

Physical: transmission of signals

All applications (FTP, Telnet, HTTP, Overlays)

HOST-TO-HOST

Routing vs. mobility

Topology data aggregation is necessary Cannot track all hosts in the world IP addresses determined by topology

Network gives the routing prefix

Mobile hosts must change their IP addresses Causes sockets / connections to break

How to communicate address changes? Goal of a mobility protocol

Transport and applications do not see address changes

Networks: Mobility

R

Public Switched Data Network

RouterRouter

R R R R

Backbone LAN

Router Router

MAN

NAT

AP

GPRS/UMTSAccess network NAT

BS BS

MH

MH

Ad hoc

MH

Rendezvous

How to find the moving end-point? Tackling double jump

What if both hosts move at the same time? Requires a rendezvous point

Mobility management is needed! Initial rendezvous Can be based on directories Requires fast updates to directories

Does not work well for DNS

Identity/Locator split

Process

Transport

ID Layer

IP Layer

Link Layer

identifier

locator

New name space for IDs Maybe based on DNS Maybe a separate

namespace Maybe IP addresses are

used for location Good for hiding IP versions

Communication end-points (sockets) bound to identifiers

Host Identity Protocol

New cryptographic namespace Connection endpoints mapped to 128 bit

host identity tags (hashes of public keys) Mapping at HIP layer 4-phase Base Exchange with

cryptographic puzzle for DoS prevention IPSec for network-level security

Upper layer view

IP connectivity problematic today Broken by firewalls, NATs, mobility Two versions of IP: IPv4 and IPv6

HIP has a potential remedy Restores end-to-end connectivity (NAT traversal

possible but may require changes / tunnelling) Adds opportunistic security Handles mobility and multi-homing Requires DHT based overlay (currently missing)

Where is the network state? Routers know addresses

Like today DHT knows HITs / SIDs

Lease based storage Middleboxes know SPIs

Soft state

Lessons to learn

Hierarchical routing likely to stay Addresses carry topological information Efficient and well established

Applications face changing connectivity QoS varies periods of non-connectivity

Identifiers and locators likely to split Mobility management is needed Probably changes in directory services

Overlays have been proposed

Summary

Topology based routing is necessary Mobility causes address changes Address changes must be signalled end-

to-end Mobility management needed

Initial rendezvous: maybe a directory service Double jump problem: rendezvous needed

Many engineering trade-offs

Distributed Hash Tables and Overlays

Layered-model revisited

Object API

Firewall bypass

End-to-end

Routing

Congestion control

Presentation DNS names

IP addresses

Routing paths

XML presentation

Finding, meta-data, invoking, syncing, mobility. Web Services

Overlay Networks

Origin in Peer-to-Peer (P2P) Builds upon Distributed Hash Tables

(DHTs) Easy to deploy

No changes to routers or TCP/IP stack Typically on application layer

Overlay properties Resilience Fault-tolerance Scalability

Upper layers

Overlay

Congestion

End-to-end

Routing

DNS names, customidentifiers

Overlay addresses

IP addresses

Routing paths

Some DHT applications

File sharing Web caching Censor-resistant data storage Event notification Naming systems Query and indexing Communication primitives Backup storage Web archive

Applications for DHTs

DHTs are used as a basic building block for an application-level infrastructure Internet Indirection Infrastructure (i3)

New forwarding infrastructure based on Chord DOA (Delegation Oriented Architecture)

New naming and addressing infrastructure based on overlays

Summary

Mobility and multi-homing require directories Scalability, low-latency updates

Overlay networks have been proposed Searching, storing, routing, notification,.. Lookup (Chord, Tapestry, Pastry), coordination

primitives (i3), middlebox support (DOA) Logarithmic scalability, decentralised,…

Host/identity split and overlays for directories seem good candidates for solving many of the issues with mobility and multi-homing

Middleware

Middleware

Widely used and popular term Fuzzy term One definition

“A set of service elements above the operating system and the communications stack”

Second definition “Software that provides a programming model

above the basic building blocks of processes and message passing” (Colouris, Dollimore, Kindberg, 2001)

Why Middleware?

Application development is complex and time-consuming Should every developer code their own protocols

for directories, transactions, ..? How to cope with heterogeneous environments?

Networks, operating systems, hardware, programming languages

Middleware is needed To cut down development time

Rapid application development Simplify the development of applications Support heterogeneous environments and mask

differences in OS/languages/hardware

Middleware cont.

Middleware services include directory, trading, brokering remote invocation (RPC) facilities transactions persistent repositories location and failure transparency messaging Security

Network stack (transport and below) is not part of middleware

Transparencies

Location transparency RPC and RMI used without knowledge of the location

of the invoked procedure / object transport protocol transparency

RPC may be implemented using any transport protocol transparency of OS and hardware

RPC/RMI uses external data representation Presentation is important XML is becoming increasingly important

transparency of programming languages language independent definition of procedures:

CORBA IDL

Network Application Framework

Network Application Framework is middleware

Contains services for distributed applications

Middleware as a term is fuzzier and larger In this course, we focus on network

application frameworks and XML objects (discovery, representation) directories (overlays,..) network security

Examples

Middleware CORBA Message-oriented Middleware Event Systems & tuple spaces Java Message Service Java 2 Enterprise Edition (J2EE) .NET

Mobile middleware WAE J2ME Wireless CORBA FUEGO

Mobile Middleware I

Middleware is typically designed and implemented for fixed-network hosts High bandwidth, low latency, reliable

communication Persistent storage and sufficient computing

power No mobility

Mobile environment requires new solutions Existing middleware services do not scale Previous lectures: mobility is challenging Small devices / embedded systems pose totally

different challenges

Mobile Middleware II

Goals for middleware: fault-tolerance, adaptability,

heterogeneity,scalability, resource sharing Mobile middleware

dynamically changing context decoupled

events, tuple spaces Basic solution for wireless

Use a proxy

Summary

Middleware for application development and deployment for supporting heterogeneous environments Main communication paradigms: RPC/RMI,

asynchronous events (publish/subscribe) J2EE, CORBA, ..

Mobile middleware Desktop middleware not usable on small,

mobile devices Special solutions are needed J2ME, Wireless CORBA, ..

Web Services

A Basic Web Service

Computer ALanguage: C++

OS: W2000

Computer ALanguage: C++

OS: W2000

Computer BLanguage: Java

OS: Linux

Computer BLanguage: Java

OS: Linux

XML

XML

Independent oflanguage, OS, network

protocols

Standardization

W3C Web Services XML Protocol Working Group

SOAP Web Services Addressing Working Group Web Services Choreography Working Group Web Services Description Working Group

WSDL

OASIS E-business standards, UDDI

WS-I (Web Service Interoperability Org.) Binding profiles,..

Web Service Architecture

The three major roles in web services Service provider

Provider of the WS Service Requestor

Any consumer / client Service Registry

logically centralized directory of services

A protocol stack is needed to support these roles

Web Services Protocol Stack

Message Transport Responsible for transporting messages HTTP, BEEP

XML Messaging Responsible for encoding messages in common XML

format XML-RPC, SOAP

Service Description Responsible for describing an interface to a specific web

service WSDL

Service discovery Responsible for service discovery and search UDDI

WS Protocol Stack

Transport: HTTP, FTP, BEEP, SMTP, JMSTransport: HTTP, FTP, BEEP, SMTP, JMS

XML Messaging: SOAP, XML-RPC, XMLXML Messaging: SOAP, XML-RPC, XML

Description: WSDLDescription: WSDL

Discovery: UDDIDiscovery: UDDI

WSDL with Java

Services

WSDL document

JAXR

UDDI

Publish

firewall

WS requester

Business partneror other system

SOAP RQBind

SOAP RQ

SOAP RQ

1. WSDL is publishedto UDDI

2. Look up WS

3. Retrieve WSDLdescription

4. Call WS

JAXR=Java API for XML Registries

What is WSDL?

WSDL: Web Service Description Language An XML language used to describe and locate

web services location of web service methods that are available data type information and XML messages

Commonly used to describe SOAP-based services

W3C standard (work in progress) Initial input: WSDL 1.1 as W3C Note Current version 2.0 (last call) Some differences between 1.1 and 2.0

WSDL 1.1 in WS-I Basic Profile 1.0 and 1.1.

WSDL Overview

<definitions>: ROOT WSDL element

<types>: The data types that are used<types>: The data types that are used

<message>: What messages are transmitted?<message>: What messages are transmitted?

<portType>: The supported operations<portType>: The supported operations

<binding>: The binding to concrete protocols<binding>: The binding to concrete protocols

<service>: Reference to actual location<service>: Reference to actual location

42 of 20

Mapping SOAP to WSDL

Putting it together

Source: http://msdn.microsoft.com/

44 of 20

SOAP Message Structure

SOAP EnvelopeSOAP HeaderHeader blockHeader block

SOAP Body

Message Body

Optional header contains blocks of information regarding how to process the message: Routing and delivery

settings Authentication/

authorization assertions Transaction contexts

Body is a mandatory element and contains the actual message to be delivered and processed (and fault information)

45 of 20

What is UDDI?

Universal Description Discovery and Integration Industry-wide initiative supporting web services Specifications

Schemas for service description Schemas for business (service implementers) description Developed on industry standards

Applies equally to XML and non-XML web services Implementation

Public web service registry and development resources SOAP-based programming protocol for registering and

discovering Web services XML schema for SOAP messages a description of the API

UDDI does not directly specify how pricing, deadlines, etc. are handled/matched

Advanced discovery via portals and marketplaces

Web Services Security

Need for XML security

XML document can be encrypted using SSL or IPSec this cannot handle the different parts of the

document documents may be routed hop-by-hop different entities must process different parts of the

document SSL/TLS/IPSec provide message integrity and

privacy only when the message is in transit We also need to encrypt and authenticate the

document in arbitrary sequences and to involve multiple parties

High-level view to WS security

Security is as strong as the weakest link The options for an attacker are:

Attack the Web Service directly Using ”unexpected” XML

Attack the Web Services platform Attack a WS security tool Attack the underlying operating system or

network connection

Application-layer Security

Identity-based security Authentication and authorization information

shared across security domains Content-based security

Protecting against buffer overflow and CGI-like attacks

Must have knowledge about the applications to which these messages are directed

Accountability or non-repudation Need message level security Maintain integrity, archived audit trails

The standards and specifications mentioned earlier address these issues

Standardization landscape

Who are specifying the basic standards? Who are specifying the higher level

standards? Who is implementing the standards?

Who are specifying the standards?

Joint IETF/W3C XML Signature (www.w3.org/Signature)

W3C XML Encryption (www.w3.org/Encryption/2001) XML Key Management (XKMS) (www.w3.org/2001/XKMS)

OASIS WS-Security

SOAP Message Security specification etc. SAML: Security Assertion Markup Language XACML: Extensible Access Control Markup language Electronic Business XML (ebXML) (with UN/CEFACT)

Web Services Interoperability Organization (WS-I) Basic security

Standardization Groups

XML EncryptionXML Encryption

XML SignatureXML Signature XKMSXKMS

XrMLXrML

WS-SecurityWS-Security

ProvisioningProvisioning

BiometricsBiometrics

XACMLXACMLSAMLSAML

W3C OASIS

Security Assertion Markup language

XML Common Biometric Format (XCBF)

Extensible Rights Markup Language

eXtensible Access Control Markup Language (XACML)XML Key Management

Specification

Basic XML Security

XML Digital Signatures (XMLDSIG) XML Encryption XML Canonicalization XML Key Management

Digital Signatures

MessageDigest

MessageDigest

Message

Private key Public keyAsymmetric Key Pair

SIGN VERIFYSignature Pass/Fail

Need to know the message, digest, and algorithm (f.e.

SHA1)

XML Digital Signatures (cont.)

<Signature ID?> <SignedInfo> <CanonicalizationMethod/> <SignatureMethod/> (<Reference URI?>

(<Transforms>)? <DigestMethod></DigestMethod>

<DigestValue></DigestValue> </Reference>)+ </SignedInfo> <Signaturevalue></Signaturevalue> (<KeyInfo>)? (<Object ID?>)*</Signature>

Encryption

Public key Private keyAsymmetric Key Pair

Encrypt Decrypt

XML Encryption

<EncryptedData Id? Type? MimeType? Encoding?> <EncryptionMethod/>? <ds:KeyInfo> <EncryptedKey>? <AgreementMethod>? <ds:Keyname>? <ds:RetrievalMethod>? <ds:*>? </ds:KeyInfo> <CipherData> <CipherValue>? <CipherReference URI?>? </CipherData><EncryptionProperties>?</EncryptedData>

Why Canonicalization is Hard

Exactly the same sequence of data bytes must be used for signing as for verifying Problem of DTDs & Schemas Problem of white space Curse of namespaces The usual:

Encodings & character sets (UTF-8,..) Representations (<foo/>, <foo></foo>) Reordering of attributes

XML Key Management (XKMS)

A Web Service that provides an interface to a PKI Abstracts PKI certificates Towards centralized PKI management (an

enterprise resource vs. configured by end-clients) Designed to manage the sharing of public keys

Managing includes verifying signatures Also includes encrypting messages

XKMS takes complexity from the applications Originally from

VeriSign, Microsoft, webMethods XKMS 1.0

W3C Note 30 March 2001 XKMS 2.0

W3C Candidate Recommendation 5 April 2004

XML Key Management (XKMS)

The XML Key Management Specification (XKMS) comprises two parts the XML Key Information Service

Specification (X-KISS), and Retrieval of information about keys

the XML Key Registration Service Specification (X-KRSS).

Store of information about keys Uses the SOAP 1.1 protocol for

communication, XML Schema, WSDL 1.0

Based on XML Signatures

Web Services Security Requirements

Access control to Web services WS-Security, XML-Signature SAML – Issuing and validation of SAML

assertions Digital certificate validation

Content-filtering XML Filters based on data format (XSD) Filters based on content (XPath) Filters based on integrity (XML Signature)

Functional point of view

Routing

Integrity Validation

Content Checking

Authentication

Authorization

XML

ManagementConsole

Design andDeploySecuritypolicies

ID ManagementLDAPPKI

Single Sign-On

ReportingActivityAlerting

Secure loggingXML

Security Contexts in Web Services

Remember Web Services goals: Re-use existing services Combine services from several domains

Security result: Must support several security domains SOAP intermediaries Reusing security tokens from one message in

another message

WS Security I

Web Services Security: SOAP Message Security 1.0 (Oasis Standard 2004)

End-to-End security Headers are decrypted and processed as needed

Selective processing Some parts are plain text Some are encrypted Some are signed

How does it work? SOAP header carries security information (and

other info as well)

WS Security II

Ability to send security tokens as part of a message, message integrity, and message confidentiality

Security model in terms of security tokens combined with digital signatures to protect and authenticate SOAP messages

An X.509 is an example of a signed security token endorsed by a CA.

When third party support is not available, receiver may choose to accept the claims in the token based on trust on the entity that sent the message.

SAML

SAML (Security Assertion Markup Language) A XML-based framework (schemas) for the

exchange of authentication and authorization information

A standard message exchange protocol How you ask and receive information

Mainly for integration, up to relying parties to decide to what authentication authority to trust

Assertions can convey information about authentication acts performed by subjects, attributes of subjects, and authorization decisions about whether subjects are allowed to access certain resources Authentication statements merely describe acts

of authentication that happened previously Specified by OASIS

SAML in a nutshell

XML-based framework for exchanging security information XML-encoded security assertions XML-encoded request/response protocol Rules on using assertions with standard

transport and messaging frameworks

SAML & WS-Security allow a SOAP message to include information about the end-user’s authentication status

Summary

Security contexts Security needed within and between contexts XML validation, encryption, and authentication

needed between security contexts! WS security standard revisited

SOAP header carries security information (and other info as well)

Selective processing SAML

Statements about authorization, authentication, attributes

SAML & WS-Security & XACML Implementations available

Putting it together

With identity/locator split + overlays?

Upper layers

Overlay

Congestion

End-to-end

Routing

Overlay addresses

IP addresses

Routing paths

DNS names, customidentifiers

Host Identities

IP addresses

Routing paths

ID Layer

CONTROL

DATA

”Theory”

WS SecurityWS Security

SOAPSOAP

TCPTCP

IPIP

”Practice”

WS SecurityWS Security

SOAPSOAP

TCP4TCP4

IPv4IPv4

HTTP/TLS/socketsHTTP/TLS/sockets

TCP6TCP6

IPv6IPv6

”Future?”

WS SecurityWS Security

SOAPSOAP

IPv4IPv4

HTTP?/socketsHTTP?/sockets

IPv6IPv6

TCPTCP

HIPsecHIPsec

HIPCTRL

HIPCTRL

Discussion

Important Dates

Exam on Thursday 12.5. 12-15 in T1. Deadline for the second assignment

15.5.