Title: T-110.5140 Network Application Frameworks and XML Summary and Conclusions 25.04.2006 Sasu Tarkoma
1T-110.5140 Network Application Frameworks and XML
Summary and Conclusions25.04.2006Sasu
Tarkoma
2Topics 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
3Interconnections
Network
Security
Directories
- Interconnections applicable on many levels
- Network-level operation
- DNS, overlay lookup, IPsec
- Application-level operation
- UDDI, SSL, WS-Security
4Mobility and Routing
5Naming, 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 nodes address?
NAT traversal? Overlay vs. network routing
Where is the node located? Differences
(IPv4/IPv6) Multi-addressing?
6Routing 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
7Rendezvous
- 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
8Identity/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
9Host 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
10Upper 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
11Lessons 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
12Summary
- 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
13Distributed Hash Tables and Overlays
14Overlay 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
15Some DHT applications
- File sharing
- Web caching
- Censor-resistant data storage
- Event notification
- Naming systems
- Query and indexing
- Communication primitives
- Backup storage
- Web archive
16Applications 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
17Summary
- 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
18Middleware
19Middleware
- 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)
20Why 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
21Middleware 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
22Transparencies
- 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
23Network 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
24Examples
- 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
25Mobile 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
26Mobile Middleware II
- Goals for middleware
- fault-tolerance, adaptability, heterogeneity,scala
bility, resource sharing - Mobile middleware
- dynamically changing context
- decoupled
- events, tuple spaces
- Basic solution for wireless
- Use a proxy
27Summary
- 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, ..
28Web Services
29Standardization
- 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,..
30Web 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
31Web 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
32WS Protocol Stack
Discovery UDDI
Description WSDL
XML Messaging SOAP, XML-RPC, XML
Transport HTTP, FTP, BEEP, SMTP, JMS
33What 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.
34WSDL Overview
ltdefinitionsgt ROOT WSDL element
lttypesgt The data types that are used
ltmessagegt What messages are transmitted?
ltportTypegt The supported operations
ltbindinggt The binding to concrete protocols
ltservicegt Reference to actual location
35Mapping SOAP to WSDL
36Putting it together
Source http//msdn.microsoft.com/
37SOAP 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)
38What 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
39Web Services Security
40Need 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
41High-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
42Application-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
43Standardization landscape
- Who are specifying the basic standards?
- Who are specifying the higher level standards?
- Who is implementing the standards?
44Who 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
45Standardization 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
XACML
SAML
Security Assertion Markup language
46Basic XML Security
- XML Digital Signatures (XMLDSIG)
- XML Encryption
- XML Canonicalization
- XML Key Management
47Web 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)
48Functional point of view
Management Console Design and Deploy Security po
licies
ID Management LDAP PKI Single Sign-On
Authorization
Authentication
Content Checking
Reporting Activity Alerting Secure logging
Integrity
Validation
Routing
49Security 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
50Summary
- 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
51Putting it together
52With identity/locator split overlays?
CONTROL
Upper layers
DNS names, custom identifiers
Overlay
Overlay addresses
Host Identities
Congestion
IP addresses
ID Layer
IP addresses
End-to-end
DATA
Routing
Routing paths
Routing paths
53(No Transcript)
54Discussion
55Important Dates
- Exam on Tuesday 16.5. 9-12 in T1.
- Deadline for the second assignment 12.5.