T 110 455 network application frameworks and xml summary and conclusions 27 04 2005 sasu tarkoma
This presentation is the property of its rightful owner.
Sponsored Links
1 / 73

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


  • 46 Views
  • Uploaded on
  • Presentation posted in: General

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

Download Presentation

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

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


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 Conclusions27.04.2005Sasu Tarkoma


Topics covered

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

Lecture Outline

Note: starts 16.00


Interconnections

Objects

Interconnections

  • Interconnections applicable on many levels

    • Network-level operation

      • DNS, overlay lookup, IPsec

    • Application-level operation

      • UDDI, SSL, WS-Security

Network

Security

Directories


Mobility and routing

Mobility and Routing


Naming addressing and routing

Naming, Addressing, and Routing

How to identify and name a node?

Frequent updates?

One or two new name spaces?

NAMING

unicast: to a specific node

broadcast: to all nodes

multicast: to a subset of nodes

anycast: to any one in some subset (IPv6)

ROUTING

ADDRESSING

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

Overlay vs. network routing

Where is the node located?

Differences (IPv4/IPv6)

Multi-addressing?


Tcp ip network stack

TCP/IP Network Stack

All applications (FTP, Telnet,

HTTP, Overlays)

Application Layer

host-to-host transport

reliability, congestion control,

flow control

Transport Layer (TCP/UDP)

host-to-host connectivity

routing, addressing

HOST-TO-HOST

Link layer: local data transfer,

encoding, framing, error correction

Physical: transmission of signals

Networking Layer (IP)

Underlying network (link layer)


Routing vs mobility

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

MH

AP

NAT

GPRS/UMTS

Access network

Public Switched Data Network

NAT

Router

Router

BS

BS

Backbone LAN

MAN

Ad hoc

MH

MH

R

R

R

R

Router

Router

Networks: Mobility

R


Rendezvous

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


T 110 455 network application frameworks and xml summary and conclusions 27 04 2005 sasu tarkoma

Process

Transport

IP Layer

Link Layer

Identity/Locator split

  • 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

identifier

ID Layer

locator


Host identity protocol

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

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

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

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

Distributed Hash Tables and Overlays


Layered model revisited

Layered-model revisited

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

DNS names

Object API

XML presentation

Presentation

Firewall bypass

IP addresses

Congestion control

End-to-end

Routing

Routing paths


Overlay networks

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


T 110 455 network application frameworks and xml summary and conclusions 27 04 2005 sasu tarkoma

Upper layers

DNS names, custom

identifiers

Overlay

Overlay addresses

Congestion

IP addresses

End-to-end

Routing

Routing paths


Some dht applications

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

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


Summary1

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


Middleware1

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

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

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

  • 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

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

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

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


Summary2

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

Web Services


A basic web service

XML

XML

A Basic Web Service

Computer A

Language: C++

OS: W2000

Computer B

Language: Java

OS: Linux

Independent of

language, OS, network

protocols


Standardization

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

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

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

WS Protocol Stack

Discovery: UDDI

Description: WSDL

XML Messaging: SOAP, XML-RPC, XML

Transport: HTTP, FTP, BEEP, SMTP, JMS


Wsdl with java

WS requester

Business partner

or other system

SOAP RQ

SOAP RQ

Bind

Publish

Services

JAXR

SOAP RQ

WSDL document

WSDL with Java

2. Look up WS

UDDI

4. Call WS

firewall

1. WSDL is

published

to UDDI

3. Retrieve WSDL

description

JAXR=Java API for XML Registries


What is wsdl

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

WSDL Overview

<definitions>: ROOT WSDL element

<types>: The data types that are used

<message>: What messages are transmitted?

<portType>: The supported operations

<binding>: The binding to concrete protocols

<service>: Reference to actual location


Mapping soap to wsdl

Mapping SOAP to WSDL


Putting it together

Putting it together

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


Soap message structure

SOAP Envelope

SOAP Header

Header block

Header block

SOAP Body

Message Body

SOAP Message Structure

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)


  • What is uddi

    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

    Web Services Security


    Need for xml 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

    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

    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

    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

    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

    W3C

    OASIS

    Standardization Groups

    Extensible Rights Markup Language

    XrML

    Provisioning

    XML Common Biometric Format (XCBF)

    eXtensible Access Control Markup Language (XACML)

    XML Key Management Specification

    WS-Security

    Biometrics

    XML Encryption

    XML Signature

    XKMS

    SAML

    XACML

    Security Assertion Markup language


    Basic xml security

    Basic XML Security

    • XML Digital Signatures (XMLDSIG)

    • XML Encryption

    • XML Canonicalization

    • XML Key Management


    Digital signatures

    Message

    Digest

    Message

    Digest

    SIGN

    VERIFY

    Signature

    Pass/Fail

    Private key

    Public key

    Asymmetric Key Pair

    Digital Signatures

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

    Message


    Xml digital signatures cont

    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

    Encrypt

    Decrypt

    Public key

    Private key

    Asymmetric Key Pair

    Encryption


    Xml encryption

    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

    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

    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 xkms1

    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

    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

    XML

    XML

    Functional point of view

    Management

    Console

    Design and

    Deploy

    Security

    policies

    ID Management

    LDAP

    PKI

    Single Sign-On

    Authorization

    Authentication

    Content Checking

    Reporting

    Activity

    Alerting

    Secure logging

    Integrity

    Validation

    Routing


    Security contexts in web services

    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

    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

    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.


    T 110 455 network application frameworks and xml summary and conclusions 27 04 2005 sasu tarkoma

    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

    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


    Summary3

    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 together1

    Putting it together


    T 110 455 network application frameworks and xml summary and conclusions 27 04 2005 sasu tarkoma

    With identity/locator split + overlays?

    CONTROL

    Upper layers

    DNS names, custom

    identifiers

    Overlay

    Overlay addresses

    Host Identities

    Congestion

    ID Layer

    IP addresses

    IP addresses

    End-to-end

    DATA

    Routing

    Routing paths

    Routing paths


    T 110 455 network application frameworks and xml summary and conclusions 27 04 2005 sasu tarkoma

    ”Theory”

    ”Practice”

    ”Future?”

    WS Security

    WS Security

    WS Security

    SOAP

    H

    I

    P

    C

    TRL

    SOAP

    SOAP

    HTTP?/sockets

    HTTP/TLS/sockets

    TCP

    TCP

    TCP4

    TCP6

    HIPsec

    IP

    IPv4

    IPv6

    IPv4

    IPv6


    Discussion

    Discussion


    Important dates

    Important Dates

    • Exam on Thursday 12.5. 12-15 in T1.

    • Deadline for the second assignment 15.5.


  • Login