t-110.455 network application frameworks and xml summary and conclusions 27.04.2005 sasu tarkoma
DESCRIPTION
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 - PowerPoint PPT PresentationTRANSCRIPT
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.