Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Internet protocol suite wikipedia , lookup
Distributed firewall wikipedia , lookup
Wireless security wikipedia , lookup
Cracking of wireless networks wikipedia , lookup
Computer security wikipedia , lookup
Zero-configuration networking wikipedia , lookup
Semantic Web wikipedia , lookup
Recursive InterNetwork Architecture (RINA) wikipedia , lookup
Routing in delay-tolerant networking wikipedia , lookup
Service-oriented architecture implementation framework wikipedia , lookup
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.