Transcript T-110.455 Network Application Frameworks and XML Web

T-110.5140 Network Application
Frameworks and XML
Summary and Conclusions
25.04.2006
Sasu Tarkoma
Topics Covered



Distributed systems security
Multi-addressing: Mobility and multihoming
Building applications with XML





Distributed objects
Role of directory services
Mobile and wireless applications
XML-based presentation and RPC
Scalability and performance issues
Interconnections

Network
Security
Objects
Directories
Interconnections applicable on many
levels

Network-level operation


DNS, overlay lookup, IPsec
Application-level operation

UDDI, SSL, WS-Security
Mobility and Routing
Naming, Addressing, and Routing
NAMING
How to identify and
name a node?
Frequent updates?
unicast: to a specific node
broadcast: to all nodes
multicast: to a subset of nodes
anycast: to any one in some subset (IPv6)
ADDRESSING
Where is the node located?
Differences (IPv4/IPv6)
Multi-addressing?
One or two new
name spaces?
ROUTING
How to route information to the
node’s address? NAT traversal?
Overlay vs. network routing
Routing vs. mobility

Topology data aggregation is necessary


Cannot track all hosts in the world
IP addresses determined by topology


Mobile hosts must change their IP
addresses



Network gives the routing prefix
Causes sockets / connections to break
How to communicate address changes?
Goal of a mobility protocol

Transport and applications do not see
address changes
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

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 endpoints (sockets) bound to
identifiers
Process
Transport
identifier
ID Layer
IP Layer
Link Layer
locator
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



HIP has a potential remedy





Broken by firewalls, NATs, mobility
Two versions of IP: IPv4 and IPv6
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


DHT knows HITs / SIDs


Like today
Lease based storage
Middleboxes know SPIs

Soft state
Lessons to learn

Hierarchical routing likely to stay



Applications face changing connectivity





Addresses carry topological information
Efficient and well established
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 endto-end
Mobility management needed



Initial rendezvous: maybe a directory service
Double jump problem: rendezvous needed
Many engineering trade-offs
Distributed Hash Tables and
Overlays
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
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


Overlay networks have been proposed




Scalability, low-latency updates
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


transport protocol transparency


RPC may be implemented using any
transport protocol
transparency of OS and hardware




RPC and RMI used without knowledge of the
location of the invoked procedure / object
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
Standardization

W3C Web Services

XML Protocol Working Group




Web Services Addressing Working Group
Web Services Choreography Working Group
Web Services Description Working Group


WSDL
OASIS


SOAP
E-business standards, UDDI
WS-I (Web Service Interoperability Org.)

Binding profiles,..
Web Service Architecture

The three major roles in web services

Service provider


Service Requestor


Any consumer / client
Service Registry


Provider of the WS
logically centralized directory of services
A protocol stack is needed to support
these roles
Web Services Protocol Stack

Message Transport



XML Messaging



Responsible for encoding messages in
common XML format
XML-RPC, SOAP
Service Description



Responsible for transporting messages
HTTP, BEEP
Responsible for describing an interface to a
specific web service
WSDL
Service discovery


Responsible for service discovery and search
UDDI
WS Protocol Stack
Discovery: UDDI
Description: WSDL
XML Messaging: SOAP, XML-RPC, XML
Transport: HTTP, FTP, BEEP, SMTP, JMS
What is WSDL?


WSDL: Web Service Description Language
An XML language used to describe and locate
web services





Commonly used to describe SOAP-based
services
W3C standard (work in progress)




location of web service
methods that are available
data type information and XML messages
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
<message>: What messages are transmitted?
<portType>: The supported operations
<binding>: The binding to concrete protocols
<service>: Reference to actual location
Mapping SOAP to WSDL
35 of 20
Putting it together
Source: http://msdn.microsoft.com/
SOAP Message Structure
SOAP Envelope
SOAP Header
Header block
Header block
Optional header contains
blocks of information
regarding how to process
the message:


SOAP Body
Message Body


Routing and delivery
settings
Authentication/authorizatio
n assertions
Transaction contexts
Body is a mandatory
element and contains the
actual message to be
delivered and processed
(and fault information)
37 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


Implementation


Public web service registry and development resources
SOAP-based programming protocol for registering and
discovering Web services



Applies equally to XML and non-XML 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
38 of 20
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


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



Authentication and authorization information
shared across security domains
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


W3C



XML Signature (www.w3.org/Signature)
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
Extensible Rights
Markup
Standardization
Groups
Language
W3C
OASIS
XML Common Biometric
XrML
Provisioning
FormateXtensible
(XCBF) Access Control
XML Key ManagementMarkup Language (XACML)
WS-Security
Biometrics
XML Encryption Specification
XML Signature
XKMS
SAML
Security Assertion Markup
language
XACML
Basic XML Security




XML Digital Signatures (XMLDSIG)
XML Encryption
XML Canonicalization
XML Key Management
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
Management
Console
Design and
Deploy
Security
policies
Authorization
Authentication
Content Checking
Integrity
Validation
Routing
XML
ID Management
LDAP
PKI
Single Sign-On
Reporting
Activity
Alerting
Secure logging
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
Summary

Security contexts



WS security standard revisited



SOAP header carries security information (and
other info as well)
Selective processing
SAML



Security needed within and between contexts
XML validation, encryption, and authentication
needed between security contexts!
Statements about authorization, authentication,
attributes
SAML & WS-Security & XACML
Implementations available
Putting it together
With identity/locator split +
overlays?
Upper layers
Overlay
CONTROL
DNS names, custom
identifiers
Overlay addresses
Congestion
End-to-end
Routing
Host Identities
ID Layer
IP addresses
IP addresses
DATA
Routing paths
Routing paths
”Theory”
WS Security
”Practice”
”Future?”
WS Security
WS Security
SOAP
SOAP
HTTP/TLS/sockets
TCP
IP
TCP4
IPv4
TCP6
IPv6
H
I
P
C
T
R
L
SOAP
HTTP?/sockets
TCP
HIPsec
IPv4
IPv6
Discussion
Important Dates


Exam on Tuesday 16.5. 9-12 in T1.
Deadline for the second assignment
12.5.