session_10_web_services_security_102608

session_10_web_services_security_102608 - Web Services...

Info iconThis preview shows page 1. Sign up to view the full content.

View Full Document Right Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: Web Services Security Cryptography and Network Security TECH 6350 Session 10 Web Services Security Manuel Mogollon [email protected] Graduate School of Management Information Assurance University of Dallas 0 Web Services Security Session 11 – Contents • Web Services • Extensible Markup Language (XML) • Simple Object Access Protocol (SOAP) • Universal Discovery, Description, and Integration, UDDI • Web Services Description Language ( WSDL) • XML Encryption • XML Signature • XML Key Management Specification • Security Assertion Markup Language (SAML) • Web Services Security Language (WS-Security) Web Services XML XMLEnc XMLSig XKMS SAML WS-Security M. Mogollon – 01/08 - 1 1 Web Services Security TCP/IP Stack and Security Related Protocols • • • • • HTTP, SMTP, Telnet, FTP, Gopher Application Layer Transport Layer TCP Network Layer IP Web Services XML RARP Ethernet, Token-Ring, FDDI, X.25, Wireless, Async, ATM, SNA...Data Layer Data Layer XMLEnc XMLSig • Web Services • SOCKS V5 • SSL, TLS UDP AR P S/MIME PGP S-HTTP IPSec (ISAKMP) SET XKMS • IPSec (AH, ESP) • Packet Filtering • Tunneling Protocols • PPP-EAP, IEEE 802.1X, CHAP, PAP, MS-CHAP SAML WS-Security M. Mogollon – 01/08 - 2 • From the perspective of networking, the single application layer is sufficient to describe communications with applications, but the point of view of sending data over the network, the application layer actually consists of a number of individual data layers, including the following: o The description layer (WSDL) o The messaging layer (SOAP) o The transmission layer (XML) The protocol layer (HTTP, SMTP, FTP) • 2 Web Services Security Application Integration • Typical examples of software application are databases. • B2B requires companies to share, modify, or add information by integrating their applications. • For more than 20 years, companies have been developing computer-to-computer communication, i.e., distributed computing. • Distributed computing protocols such as DCOM, CORBA, Distributed Smalltalk, and RMI were developed for services to agree on programming languages and shared context. • None of these protocols operates effectively over the Web. Web Services XML XMLEnc XMLSig XKMS SAML WS-Security M. Mogollon – 01/08 - 3 • A service is an application offered by an organization that can be accessed through a programmable interface. It could be as simple as selling a movie ticket, allowing a passenger to select a seat on a flight, or letting suppliers access inventories to reduce inventory-related costs. Companies used point-to-point communications to integrate their applications by connecting business partners and customers; performance was improved by designing those applications as services that ran on centralized application servers. Travel agencies, for example, had software from different airlines installed in their systems so they were able to access the airlines reservation systems. Because the reservation systems were designed as object-oriented programming, which bonded data and processing together, if the travel agency wanted to sell airline tickets from several airlines, it needed different software for each airline. • Distributed computing protocols such as DCOM, CORBA, Distributed Smalltalk, and RMI were developed for services to agree on programming languages and shared context. Each of these protocols was constrained by vendor operability because they were built as silos. Further, none of these protocols operated effectively over the Web. With distributed computing protocols, software was developed for travel agencies to buy airline tickets from any airline, but it was still necessary to have another software to make hotel reservations or to rent a car. 3 Web Services Security Electronic Services • Service Oriented Architecture (SOA) is also about distributed computing, but it provides a way to create sets of services and with such granularity that each service can be invoked, published, and discovered. Examples of such services include the following: — Purchasing an airline ticket; renting a car — Accessing a seat assignment data base to get an assigned seat. — Requesting part inventory information from a buyer to restock. • With SOA, only one software is necessary to buy airline tickets or to rent a car, but SOA does not use standard Internet protocols. • Virtually all companies have presence and are invested on the Web to exchange information with other companies or consumers. • Web services provide application integration through the Web. Web Services XML XMLEnc XMLSig XKMS SAML WS-Security M. Mogollon – 01/08 - 4 • Service Oriented Architecture (SOA) is also about distributed computing, but it provides a way to create sets of services and with such granularity that each service can be invoked, published, and discovered. With SOA, only one software is necessary to buy airline tickets or to rent a car, but SOA does not use standard Internet protocols. • Web services represent the convergence between Service Oriented Architecture (SOA) and the Web; it takes all the best features of SOA and combines them with the Web. Unlike some software that is accessed via proprietary protocols, Web services are accessed via ubiquitous Web protocols. As a result, it is possible to go to a Web site and purchase a ticket, make hotel reservations, and rent a car. 4 Web Services Security Web Services • The common aspect of all services is that the information resides in databases. — Stored in specialized data servers, using proprietary formats that make them difficult to access or to connect to other databases. — Web servers only accessible through hyper scripting languages. • Web services represent the convergence between Service Oriented Architecture (SOA) and the Web. • Web services are accessed via ubiquitous Web protocols. Web Services XML XMLEnc XMLSig XKMS SAML WS-Security M. Mogollon – 01/08 - 5 • The common aspect of all these services is that the information resides in databases, and all these databases are stored in specialized data servers, using proprietary formats that make them difficult to access or to connect to other databases. Even Web servers are only accessible through hyperscripting languages. • By using common standards, Web services can make databases available across the Web; they unlock the databases and make their information available to other databases, workstations, or kiosks. The information can be used by other departments within a company, as well as by customers, vendors, suppliers, or the public in general. True application sharing requires a serverto-server (S2S) access. 5 Web Services Security Web Services • Web services allow computers running on different operating platforms to access and share each other’s databases by using open standards. — Extensible Markup Language (XML) — Simple Object Access Protocol, SOAP • A Web service is an application that — Can be identified by a Uniform Resource Identity. — Can be defined and located. — Is able to interact with other software applications. • Web services can make databases available across the Web. — Unlock databases and make their information available to other databases, workstations, or kiosks. — Provide true application sharing required for server-to-server (S2S) access. — Can be used by other departments within a company, as well as by customers, vendors, suppliers, or by the public in general. Web Services XML XMLEnc XMLSig XKMS SAML WS-Security M. Mogollon – 01/08 - 6 • Web services allow computers running on different operating platforms to access and share each other’s databases by using open standards such as Extensible Markup Language, XML, and Simple Object Access Protocol, SOAP. A Web service is an application, identified by a uniform resource identity, capable of being defined and located, as well as of interacting with other software applications. • The following are some characteristics of Web services: o Web services are accessible over the Web. o Web services communicate using XML Web Protocol. XML is platform-independent and language-neutral, which allows for easy integration. o Web services are designed with interfaces that can be called from other programs. This application-to-application programming interface can be invoked from any type of application client or service. o Web services are registered at Web Service Registries, which allow the registry users to easily find the services that they need. o Web services communicate by sending messages in plaintext to each other. o Web services can be developed and deployed on any platform. o All Web services applications use the same language, the Extensible Markup Language (XML), to describe their interfaces and to encode their messages. 6 Web Services Security Web Services Interactions Function Web Web site description Web Services Search Engine Web site location UDDI Search Engine Description WSDL Transport protocol HTTP SOAP Data format HTML XML UDDI Universal Description, Discovery and Integration WSDL Web Services Description Language SOAP Simple Object Access Protocol XML Extensible Markup Language Web Services XML XMLEnc UDDI finds the WSDL description of a queried service, as well as the access point of the service, and provides this information to the service consumer. WSDL is the language used to describe what information is available at the Web service and the procedures for how to call the information from the database. SOAP allows XML messages to be sent over HTTP. XML recognizes data in a field. XMLSig XKMS SAML WS-Security M. Mogollon – 01/08 - 7 • When a user is looking for some specific Web pages on the Web, he uses search engines such as Google or Yahoo. When a database is looking for specific information on another database, it uses a directory called Universal Discovery, Description, and Integration (UDDI), to search for registries; UDDI is a type of directory in which companies list the Web services that they provide. IBM, Microsoft, and SAP are among the companies that maintain UDDI registries. • A search at one of the Web search engines produces many results, so the user has to select which one is the most appropriate. A search for “chips” at any Web search engine produces links to potato chips and to microchips. In XML, the Web Services Description Language, WSDL, provides a description of what information is available at the Web service and the procedures for how to get the information needed from the database. • To be able to send XML over HTTP, it was necessary to create a new mechanism to wrap the information and send it over HTPP. That new mechanism is called Simple Object Access Protocol (SOAP). • Independent of the Web browser used to visit a Web site, the information displayed on the monitor is the same. This is because Web sites are encoded using Hypertext Markup Language (HTML), so the browser displays the same fonts, colors, and location on the screen as the graphical image at the Web server. HTML is a display language –not a data-representing language. XML was developed to recognize data in a field; as long as two databases have the same fields, for example, first name, last name, and telephone number, XML can extract the information needed from both databases. 7 Web Services Security Web Services Interactions The UDDI Registry points to and describes services. 3 L 1 A Web service L D D S S W W UDDI Registry provider registers the service. The Web service consumer queries the UDDI registry for a service. 2 Web service consumer invokes, requests, service. 4 SOAP 5 Web Service Provider Web Services XML Web service provides requested service. XMLEnc XMLSig Web Service Consumer XKMS SAML WS-Security M. Mogollon – 01/08 - 8 • The service provider who wants to make the service available to consumers registers the service in a UDDI registry using WSDL. The service provider describes its service and provides directions and pointers to find the service. The UDDI acts as directory that has descriptions of services and directions to find service providers. • When service consumers want to use a service, they query the UDDI registry to find a service that matches their needs. The UDDI finds the information, obtains the WSDL description of the service, as well as the access point of the service, and provides this information to the service consumer. Service consumers use the WSDL description to prepare a SOAP message in order to communicate with the service. • In summary, Web service architecture consists of three primary functions: o Discovery: Universal Description, Discovery and Integration (UDDI) o Description: Web Services Description Language (WSDL) o Transport: Simple Object Access Protocol (SOAP). 8 Web Services Security XML– Extensible Markup Language • HTML was designed to display data and to focus on how data looks; when HTML is used to display data, the data is stored inside HTML. • XML was developed to recognize structure information. As long as two databases have the same fields, for example, first name, last name, and telephone number, XML can extract information from both databases. • Converting data to XML allows incompatible database systems to exchange information. • XML is a standard language for web services and document sharing. Information encoded in XML can be read by many different types of applications using only a text editor. • XML can be used not only to share data, but also to store data. • XML is particularly vulnerable to security compromises. — Any XML message, including SOAP messages, should be enhanced with security features including encryption, digital signatures, authentication mechanisms, and privacy controls. Web Services XML XMLEnc XMLSig XKMS SAML WS-Security M. Mogollon – 01/08 - 9 • XML is used to exchange data. Unlike HTML, which was designed to display data and to focus on how data looks, XML was designed to describe data and to focus on what data is. XML was created to structure and store data, as well as to manage a large amount of simple or complex data in many forms without limitations. XML displays this data in a readable format. • When HTML is used to display data, the data is stored inside HTML. With XML, data can be stored in separate XML files outside the HTML, so changes in the data will not require any changes to the HTML code. If XML data is stored inside HTML pages, it is stored as data islands, so HTML only needs to be used for formatting and displaying the data. • XML functions similarly to Adobe PDF files. Adobe PDF files preserve the look and integrity of the original documents, and they can be read electronically by anyone, regardless of hardware and software platforms. XML functions in the same way; converting the data to XML allows incompatible database systems to exchange information. XML encodes information, so many different types of applications using only a text editor can read it. • XML can be used not only to share data, but also to store data. Since XML data is stored in plaintext format, it is possible to store data in XML format so the stored data will be software and hardware independent, making it easier to retrieve the data. • The XML text-based data has many advantages, but it is inefficient. Web services are slower than applications using binary data and, because data is sent in plain text, there are some concerns about security. 9 Web Services Security XML Syntax <?xml version="1.0" encoding="ISO-8859-1"standalone="no"?> [1] <NameAndAdress Role=”Supplier”> [1a] <CompanyName>Plano Hammers and Nails</CompanyName> [1b] <AddressLine>101 Some Street</AddressLine> • An XML document contains one [1c] <City>Plano</City> or more root elements, delimited [1d] <State>TX</State> by start-tags and end-tags. [1e] <ZipCode>75075</ZipCode> • The name in the start-tags and [1f] <CountryCode>US</Countrycode> end-tags gives the element's </NameAndAddress> type. [2] <Catalog> • All XML documents must contain [2a] <Hammer> a single tag pair defining a root [2a1] <Description>Five-inch hammer </Description> element; all other elements must [2a2] <SKU>301245AB</SKU> be within this root element. [2a3] <Price>$2.45</Price> • All root elements can have sub </Hammer> elements (child elements). [2b] <Nail> [2b1] <Description>One-inch </Description> • All information is in clear. [2b2] <SKU>253648AA</SKU> [2b3] <Price>$2.45</Price> </Nail> </Catalog> Web Services XML XMLEnc XMLSig XKMS SAML WS-Security M. Mogollon – 01/08 - 10 • The first line in the document, the XML declaration, defines the XML version and the character encoding used in the document; it is expressed in Latin characters, e.g., UTF-8, UTF-16, EUC-JP, and ISO-10646-UC-2. In this case, the document conforms to the 1.0 specification of XML and uses the ISO-8859-1 (Latin-1/West European) character set. The standalone declarations are “no” (parsing affected by external DTD subsets), or “yes” (parsing not affected by external DTD subset). • By definition, each XML document contains one or more root elements, the boundaries of which are delimited either by start-tags and end-tags, or, for empty elements, by an empty-element tag. The name in the start-tags and end-tags gives the element's type. In the example above, there are two root elements, the NameAndAddress [1] and the Catalog [2]. • All XML documents must contain a single tag pair defining a root element, and all other elements must be within this root element. All root elements can have sub elements (child elements). • In the example above, the child elements, CompanyName, AddressLine, ZipCode, and CountryCode, are all nested inside the root element, NameAndAddress. Notice that each child element has its boundaries delimited by start-tags and end-tags. 10 Web Services Security Simple Object Access Protocol (SOAP) • Is the standard communications protocol for Web services. • Is independent of any programming language or operating systems. • Provides a way for applications to communicate with one another over the Internet, independent of platform. • Consist of an envelope, the header and the body. • The communication is peer-to-peer between an initial SOAP sender and the SOAP receiver. It involves multiple message exchanges between these two nodes in request/response, solicit/response, and notification formats. • SOAP protocol is designed to support one or more intermediaries that can forward or reroute SOAP messages based upon information either in the SOAP header or in the HTTP header. • The Organization for the Advancement of Structured Information Standards (OASIS) has two security specifications to secure SOAP: The Security Assertion Markup Languages (SAML) and Web Services Security (WS-Sec). Web Services XML XMLEnc XMLSig XKMS SAML WS-Security M. Mogollon – 01/08 - 11 • SOAP is the standard communications protocol for Web services. In the same way that MIME (Multipurpose Internet Mail Extensions) defines the email message format, SOAP defines the XML message format. • SOAP is supported by HTTP and is independent of any programming language or operating systems. As a transport mechanism for XML, SOAP provides a way for applications to communicate with one another over the Internet, independent of platform. • As with MIME, SOAP contains an envelope, the header, and the body. XML defines the format of the information and then SOAP adds the necessary HTTP headers to send it. The communication is peer-to-peer between an initial SOAP sender and an ultimate SOAP receiver and involves multiple message exchanges between these two nodes in request/response, solicit/response, and notification formats. • The original SOAP did not include security at all, but the Organization for the Advancement of Structured Information Standards (OASIS) has two security specifications to secure SOAP: the Security Assertion Markup Language (SAML) and Web Services Security (WS-Sec). • SAML addresses the issue of access authentication and authorization. WS-Sec addresses the issue of securing the content of Web services messages. SAML and WS-Sec can be used in a hierarchical trust model in which a certificate authority is required, and in a user-centric model in which a certificate authority is not required – similar to Pretty Good Privacy (PGP). 11 Web Services Security Universal Discovery, Description, and Integration (UDDI) • Companies that want to publish their services on the Internet use a UDDI registry to register the information about the service they offer. • Currently Microsoft and IBM in the US and SAP in Germany are among the companies that act as public UDDI operators. • UDDI specifies the following: — The description and discovery of businesses, organizations, and other Web services providers. — The Web services they make available — The technical interfaces which may be used to access those services. Web Services XML XMLEnc XMLSig XKMS SAML WS-Security M. Mogollon – 01/08 - 12 • Search engines are used to find information on the Internet, but a Web page is meaningless if a person or corporation cannot find it. It is the same with Web services; potential users go to a registry to find information about a specific service. Companies that want to publish their services on the Internet use a UDDI registry to register the information about the service they offer. Currently Microsoft and IBM in the US and SAP in Germany are among the companies that act as public UDDI operators. Information published in one public UDDI repository is replicated automatically in all other public repositories. Organizations can set up a private registry to support the requirements of a company or group of companies. • UDDI Version 3 specification defines a set of services that support the following: (1) The description and discovery of businesses, organizations, and other Web services providers, (2) The Web services they make available, and (3) The technical interfaces that may be used to access those services. UDDI provides a standard mechanism to register and discover Web services. 12 Web Services Security Registering a Service in UDDI • Business Entity: Company name, address, business identifiers. • Business Service: Type of Web services offered. • Binding Template: Information for finding, accessing and using a particular Web service. • tModel (Technical model): A reusable concept, such as a Web service type, a protocol used by Web services, or a category system offered by multiple businesses. For example, several companies offering weather reports can use the same tModel. • Publisher Assertion: Relationship that the Business Entity has with another Business Entity, e.g., supplier, distributor. Web Services XML XMLEnc XMLSig XKMS SAML WS-Security M. Mogollon – 01/08 - 13 Conceptually, the business registration provided to an UDDI is organized as follows: • Business Entity: Describes a business or other organization that typically provides Web services. Includes name, short description, address, contact, and known business identifiers, including the Thomas Register identifier and a D-U-N-S number. • Business Service: Describes a collection of related Web services offered by an organization, the business entity. Each business service entry contains a description of the service, a list of categories that describe the service, and a list of binding templates that point to technical information about the service. • Binding Template: Describes the technical information for finding and using a particular Web service. The binding template represents the way the business service is accessed, e.g., a telephone number, a Web site, or a Web service. Each business service can have multiple binding template entries. • tModel: Describes a technical model representing a reusable concept, such as a Web service type, a protocol used by Web services, or a category system that is offered by multiple businesses, all supporting the same service interface. A tModel specifies information such as the tModel name, the name of the organization that published the tModel, a list of categories that describe the tModel, and pointers to technical specifications for the tModel. For example, there may be several companies offering weather reports, so all of them can use the same tModel. • Publisher Assertion: Describes, from the point of view of one business entity, the relationship that the business entity has with another business entity. • Subscription: Describes a standing request to keep track of changes to the entities described by the subscription. 13 Web Services Security Web Services Description Language (WSDL) • WSDL is a document written in XML that describes the messages that must be exchanged to successfully interact with a Web Service. • The WSDL message defines the where and how of getting a service. — — — — • The name and location of the Web service. The type of data the Web service uses How the request for a service should be sent How to put together and bind all the information. The WSDL Specification is divided into six major components: — Definition: Defines the name of the Web service. — Message: Defines and describes the message. — PortType: Defines the Web service, the intended recipient of a message, the messages themselves, and how the operations can be performed. — Types: Describes all the types of data used between the client and the Web service server. — Binding: Defines the message format and protocol details for each port. — Service: Defines where the services are located and provides the addresses for invoking them. Web Services XML XMLEnc XMLSig XKMS SAML WS-Security M. Mogollon – 01/08 - 14 • WSDL is a document written in XML that describes the messages that must be exchanged to successfully interact with a Web service. It provides the name and location of the Web service, the type of data the Web service uses, how the request for a service should be sent, and how to put together and bind all the information. • The WSDL specification is divided into six major components: • Definitions: The definitions element is the parent element in all WSDL documents. It gives the name of the Web service, lists multiple namespaces used throughout the remainder of the document, and contains all the service elements described below. • Message: The message element defines and describes a one-way message, whether it is a single message request or a single message response. • Port Type: The port type defines multiple operations: a Web service, the intended recipient of a message, the messages themselves, and how the operations can be performed. An operation is a combination of messages labeled as input, output, or fault to indicate what part a particular message plays in the interaction. In the WSDL Version 2 specification, port types have been renamed as interfaces and ports as end-points. • Types: The types element describes all the types of data used between the client and the Web service server. If the Web service uses only XML Schema built-in simple types, such as strings and integers, the types element is not required. • Binding: The binding element defines the message format and protocol details for each port. WSDL-specific built-in extensions that define SOAP services and SOAP-specific information are included in the binding component. • Service: The service element defines where the services are located and provides the address for invoking the specified service. Most commonly, this includes a URL for invoking the SOAP service. 14 Web Services Security Web Services Security • • Web services is about the free exchange high-value data. XML is a text-based, platform-independent standard. — Anyone who has access to an XML document can easily read the document. — In a man-in-the-middle attack, a hacker could change the information in XML. • • Web services should be reliable and secure. Web services security provides the following security services: — XML Encryption is used to encipher data or to securely transport encrypting keys. — XML Signature is used to provide integrity, message authentication, and /or signer authentication services for data of any type. — XML Key Management Specification (XKMS) is used to register, locate, and validate public keys used in XML Signatures. It manages the life cycle of public keys and certificates and allows PKI as a trusted Web service. — Security Association Markup Language (SAML) provides portable identity, authentication and authorization using credentials called assertions. SAML solves the problem of Web Single Sign-On by allowing users to gain access to website resources in multiple domains without having to re-authenticate after initially logging on to the first domain. — Web Services Security (ws-security) describes how to attach security tokens to the SOAP message header. Web Services XML XMLEnc XMLSig XKMS SAML WS-Security M. Mogollon – 01/08 - 15 • XML is a text-based, platform-independent standard used for Web services so that there can be a free exchange of information. Nevertheless, anyone who has access to an XML document can easily read the document, thus making XML and Web services more exposed to hackers. Businesses require that the exchange of high-value data such as business processes, e-commerce transactions, and the exchange of inventory information be protected. Government information, legal documents, financial data, and medical records have the same need for security. • Web services security provides the following security services: confidentiality, integrity, authentication, non-repudiation, and access control. Several mechanisms have been developed to provide those security services in Web services. They include XML encryption, XML Signature, XML Key Management Specification (XKMS), the Security Association Markup Language (SAML), and Web Services Security (ws-security). 15 Web Services Security Distributing Computing Service Oriented Architecture (SOA) Web Services XML Encryption Web Services (Convergence between SOA and the Web) SAML (Addresses the issue of Web services access authentication and authorization) SOAP (Defines the XML message format. XML XML Key Information XML Key Management Web Services Security Web Services XML Signature Extensible Markup Language (XML) XMLEnc XMLSig XML Key Registration SAML Artifact Profile (Push) SAML POST Profile (Pull) Web Services Security Model (How to attach signature and encryption headers to SOAP messages) XKMS SAML Security Tokens Signature WS-Security M. Mogollon – 01/08 - 16 • Use this chart as a reference to know where you are in the rest of this chapter. 16 Web Services Security XML Encryption • XML Encryption specifies a process for encrypting data and representing the result in XML. • Data to be encrypted may be arbitrary data (including an XML document), an XML element, or XML element content. • The main role element in XML encryption is EncryptedType from which two role elements are derived. — EncryptedData which contains all the information to encipher the XML data. — EncryptedKey which contains the information to encipher keys. • CipherData is the XML Encryption element that contains or references the enciphered data. Web Services XML XMLEnc XMLSig XKMS SAML WS-Security M. Mogollon – 01/08 - 17 • In a credit card transaction, certain information is relevant only to specific parties. The issuer, the financial institution that establishes an account for a cardholder and issues the payment card, doesn’t need to know what product or service the cardholder is purchasing. The merchant, the company that offers goods or services for sale, doesn’t need to know the credit card number. In XML, it is possible to encipher either a root or a child element of the transaction. XML encryption is not a new type of encryption algorithm, but a way to encipher XML elements. • In XML encryption, data is transformed into serialized octets for encryption and decryption operations. The application is responsible for transforming and marshalling the XML octets, so that they can be serialized into an octet sequence for enciphering and deciphering. 17 Web Services Security XML Encryption Data 3DES, AES Block Encryption 3DES AES, 128, 192, 256 Wrapping the Key Diffie-Hellman Key Exchange ZZ Stream Cipher RSA-v1.5 RSA-OAEP Transporting the Key Encrypted Key Keying Material Agreement Method Encryption Method Element Encrypted Key Element Key Info Element Key Name Retrieval Method Data Object Encryption 3DES, AES Or Encrypted Data Element Cipher Value Cipher Reference Cipher Data Element Encryption Properties Element Web Services XML XMLEnc XMLSig XKMS SAML WS-Security M. Mogollon – 01/08 - 18 1. Select an EncryptedType structure, either EncryptedData or EncryptedKey. An EncryptedType structure represents all of the information discussed below, including the type of encrypted data, encryption algorithm, parameters, key type, etc. 2. Select the algorithm (and parameters) to be used to encipher the data. This information is contained in the EncryptionMethod element. 3. Obtain and (optional) represent the key. This information is contained in the ds:KeyInfo element. As required, ds:InfoKey may have several child elements to identify the key (ds:KeyName, ds:KeyValue, ds:RetrievalMethod, etc.). If the key itself is to be encrypted for transport, then it is necessary to create an EncryptedKey element and apply an encryption process. EncryptedKey may be a child of ds:KeyInfo, or it may exist elsewhere and be identified in the RetrievalMethod. 4. Encipher the data. This information is contained in the CipherData element. The data needs to be converted to serial data in octets, UTF-8, and then the octets are enciphered using the algorithm and key from steps 2 and 3. o If the encrypted octet sequence is to be stored in the CipherData element within the EncryptedType, then the encrypted octet sequence is base64 encoded and inserted as the content of a CipherValue element. o If the encrypted octet sequence is to be stored outside the EncryptedType element, then it is necessary to provide information in a CipherReference element for the deciphering party to be able to retrieve the encrypted octet sequence. 5. Add additional information concerning the generation of the EncryptedData or EncryptedKey; this information could include the date/time stamp or the serial number of cryptographic hardware used during encryption. This information is placed in an EncryptionProperty element. 18 Web Services Security XML Encryption Data Syntax <EncryptedData Id? Type? MimeType? Encoding?> [1] EncryptedData contains all the information needed to encipher XML data. EncryptedKey contains the information to encipher keys. <EncryptionMethod/>? [2] <ds:KeyInfo> [2a] <EncryptedKey>? [2b] <AgreementMethod>? [2c] <ds:KeyName>? [2d] <ds:RetrievalMethod>? [2e] <ds:*>? The KeyInfo element provides information on how the secret key is sent to the recipient. The secret key is the key used to encipher the data. </ds:KeyInfo>? [3] <CipherData> [3a] <CipherValue>? [3b] <CipherReference URI?>? </CipherData> [4] <EncryptionProperties>? </EncryptedData> Web Services XML XMLEnc The EncryptionMethod element describes the encryption algorithm used to encipher the data. XMLSig The CipherData element provides the enciphered data. In the CipherData, either the enciphered data is included in the CipherValue element, or a reference to an external location in the CipherReference element is provided. XKMS SAML WS-Security M. Mogollon – 01/08 - 19 19 Web Services Security EncryptionMethod • An optional element that describes the encryption algorithm used to encipher the data. • Depending of the encryption algorithms used, the syntax is one as one of the followings: — <EncryptionMethod Algorithm='http://www.w3.org/2001/04/xmlenc#tripledes-cbc'/> — <EncryptionMethod Algorithm='http://www.w3.org/2001/04/xmlenc# aes128-cbc'/> — <EncryptionMethod Algorithm='http://www.w3.org/2001/04/xmlenc# aes256-cbc'/> — <EncryptionMethod Algorithm='http://www.w3.org/2001/04/xmlenc# aes192-cbc'/> Web Services XML XMLEnc XMLSig XKMS SAML WS-Security M. Mogollon – 01/08 - 20 • EncryptionMethod is an optional element that describes the encryption algorithm used to encipher the data. If the element is absent, the encryption algorithm must be known by the recipient to be able to decipher the XML message. The permitted child elements of the EncryptionMethod are determined by the specific value of the algorithm attribute URI; the KeySize child element is always permitted. Depending on the encryption algorithms used, the syntax is one of the following: <EncryptionMethod Algorithm='http://www.w3.org/2001/04/xmlenc#tripledes-cbc'/> <EncryptionMethod Algorithm='http://www.w3.org/2001/04/xmlenc# aes128-cbc'/> EncryptionMethod Algorithm='http://www.w3.org/2001/04/xmlenc# aes256-cbc'/> <EncryptionMethod Algorithm='http://www.w3.org/2001/04/xmlenc# aes192-cbc'/> • The encryption algorithms used in XML encryption are: tripledes-cbc, aes128-cbc, aes256-cbc‘, and aes192-cbc. 20 Web Services Security Getting Key Information • Parties who have not exchanged secret keys previously. — Encipher or wrap the secret key for transport using a public key system. — Use EncryptedKey. • Parties who have not exchanged secret keys previously. — Use Diffie-Hellman for key agreement. — Use AgreementMethod. • When secret keys have already been loaded in both parties’ systems and every loaded secret key is associated with a name. — Send the name of the secret key that will be used to encipher the XML information. — Use KeyName. • When the secret key is located at a specific location. — Provide a link to identify and locate the keys. — Use RetrievalMethod. Web Services XML XMLEnc XMLSig XKMS SAML WS-Security M. Mogollon – 01/08 - 21 • There are four ways to send information about the secret key needed to decipher CipherData: 1. If the parties have not exchanged secret keys previously, it is necessary to transport the secret key in a secure manner. This could be done by enciphering or wrapping the key for transport using a public key system. The element where this information is provided is called EncryptedKey. 2. If the parties have not exchanged secret keys previously, it is necessary to agree on a secret key. This could be done by using Diffie-Hellman for key agreement, and the element where the agreement information is provided is called AgreementMethod. 3. If the secret keys have already been loaded into both parties’ systems, it is only necessary to define which of the secret keys was used to encipher the XML information. In general, every loaded secret key is associated with a name. The element where this information is provided is called ds:KeyName. 4. The information on how to find the key to decipher the XML document could be attached to the KeyInfo element or detached (not inside ds:KeyInfo). If the information on how to get the secret key is not attached to the KeyInfo, then the RetrievalMethod element is an alternative way to identify and locate the key by providing a link to the key information location. 21 Web Services Security Encrypted Key – Wrapping the Key Use shared key-encrypting-key to wrap (encipher) a session key Web Service Requester Web Service Provider Shared key-encrypting key Shared Key-Encrypting Key Session key Decipher Encipher Session key Block 1 + + 3DES or AES 3DES or AES Enciphered Session key Block 1 Shared keyencrypting key Session key Block n Enciphered Session key Block n IV Web Services XML Enciphered Session key Block n Enciphered Session key Block 1 + + 3DES or AES 3DES or AES Session key Block n Session key Block 1 Use 3DES or AES to encipher and decipher a session key XMLEnc Session key XMLSig XKMS SAML IV Shared keyencrypting key WS-Security M. Mogollon – 01/08 - 22 • Symmetric key wrap algorithms are algorithms specifically created for wrapping, enciphering and deciphering symmetric keys. Both parties need to share a key-encrypting-key that is used to wrap (encipher) the key that is going to be used to encipher the information. In cryptanalysis, the more a key is used, the higher the probability that it could be broken. By using a key-encrypting-key to wrap keys, then the KEK will be used a fewer number of times that if it were used to encipher messages. • Keys are encrypted using 3DES or AES. 22 Web Services Security Encrypted Key – Transporting the Key Use a public key algorithm to transport the session key Web Service Web Requester Session Key XML RSAES-v1.5 or RSAES-OAEP .Algorithm Enciphering Web Services Session Key RSAES-v1.5 or RSAES-OAEP .Algorithm Service Provider’s Public Key Web Service Provider Deciphering XMLEnc XMLSig XKMS Service Provider’s Private Key SAML WS-Security M. Mogollon – 01/08 - 23 • Key transport algorithms are public key encryption algorithms specified for encrypting and decrypting keys. Their identifiers appear as algorithm attributes to EncryptionMethod elements that are child elements of EncryptedKey. EncryptedKey is in turn the child of a ds:KeyInfo element. The type of key being transported depends on the type of encryption algorithm that is going to be used as indicated in the EncryptionMethod. • The XML encryption recommendation implements two required key transport algorithms: RSAESPKCS1-v1.5 and RSAES-OAEP. Both transport algorithms are defined in RFC 3447, “PKCS #1: RSA Cryptography Specifications Version 2.1.” • RFC 3447 recommends RSAES-OAEP for all new applications because it includes plaintext awareness. Optimal Asymmetric Encryption Padding (OAEP) is a method for encoding messages developed by Mihir Bellare and Phil Rogaway. In RSAES-OAEP, the key is encoded first with OAEP and then encrypted with RSA. 23 Web Services Security Key Agreement Use Diffie-Hellman to calculate ZZ and RFC-2631 Key Agreement Method to generate key material. Web Service Requester Web Service Provider Diffie-Hellman Key Exchange Diffie-Hellman Key Exchange Pre Master Key (ZZ) Pre Master Key (ZZ) Key Material Generation Keying Material = KM(1) || KM(2) || KM(3) || ... KM(counter) = Hash ( ZZ || counter || EncryptionAlg || KA-Nonce || KeySize ) Session Key Session Key Web Services XML Key Material Generation XMLEnc XMLSig XKMS SAML WS-Security M. Mogollon – 01/08 - 24 • A key agreement algorithm allows a sender and a receiver to share a secret key computed from public-key algorithms. Normally, the shared secret key is not used as a key, but instead, is used to arrive at key material. In TLS/SSL, (See Chapter 12, “Phase 2 & 3 Authentication and Key Exchange”) the shared secret key is called the pre-master key, and from this pre-master key, the secret key is calculated. • RFC 2631 (Rescorla, 1999) describes the Diffie-Hellman key agreement method, in which, from a Diffie-Hellman shared secret, ZZ, key material is generated. The method described in RFC 2631 is used in XML encryption for KeyAgreement. • XML encryption does not provide an on-line key agreement negotiation protocol. The AgreementMethod element can be used by the originator to identify the keys and computational procedure that were used to obtain a shared encryption key. 24 Web Services Security Key Info – Key Name Web Service Web Requester The secret keys have been loaded into both servers, so only the name associated with the key needs to be sent. Secret Key Table Web Service Provider Secret Key Table Key Name Secret Key Key Name Type of Encryption Algorithm Web Services Secret Key Key Name Type of Encryption Algorithm XML XMLEnc XMLSig XKMS SAML WS-Security M. Mogollon – 01/08 - 25 • Assuming that in a symmetric encryption the secret key has been loaded into both parties, then only the name associated with the key needs to be sent. In the drawing above, only the key name is sent. 25 Web Services Security XML Signatures • Provide integrity, message authentication, and/or signer authentication services for data of any type, whether located within the XML that includes the signature or elsewhere. • Specify XML syntax and processing rules for creating and representing digital signatures. • Can be applied to any digital content (data object), including XML. • Constitute a method of associating a key with referenced data (octets). • Are applied to arbitrary digital content (data objects) in the same way as digital signatures are. — A hash function is applied to a data object, the resulting value is cryptographically signed by enciphering with the sender’s private key. Web Services XML XMLEnc XMLSig XKMS SAML WS-Security M. Mogollon – 01/08 - 26 • The XML-Signature Syntax and Processing W3C Recommendation specifies a process for creating and representing digital signatures. XML signatures provide integrity, message authentication, and/or signer authentication services for data of any type, whether located within the XML that includes the signature or elsewhere. • XML signatures are applied to arbitrary digital content (data objects) in the same way as a digital signature is done. A hash function is applied to a data object, the resulting value is placed in an element (with other information), and that element is then cryptographically signed by enciphering with the sender’s private key. 26 Web Services Security XML Signature Syntax [1] [1a] [1b] [1c] [1c1] [1c2] [1c3] [2] [3] [3a] [3b] [3c] [3d] [3e] [3f] [4] <Signature ID?> <SignedInfo> <CanonicalizationMethod/> <SignatureMethod/> <Reference URI? > (<Transforms>)? <DigestMethod> <DigestValue> </Reference>)+ </SignedInfo> <SignatureValue> <KeyInfo>)? <KeyName> <KeyValue> <RetrievalMethod> <X509Data> <PGPData> <SPKIData> </KeyInfo> <Object ID?>)* </Signature> Web Services XML XMLEnc XMLSig The SignedInfo element identifies all cryptographic functions involved in the signature operation (e.g., hashing, public key algorithms, MACs, padding, etc.). The SignatureMethod provides the name of the algorithm used to convert the canonicalized SignedInfo into the SignatureValue. The SignatureValue shows the digital signature value. The KeyInfo identifies the key to be used to validate the signature. Possible forms for identification include certificates, key names, and key agreement algorithms information, among others. XKMS SAML WS-Security M. Mogollon – 01/08 - 27 27 Web Services Security XML Signature Canonicalization Method Message Authentication (HMAC) Signature Signature Method Algorithm (DSA, RSASSA-PKCS 1) Digest Value Transform Elements Digest Method Signed Info Signed Info Element Canonicalized Signed Info Element Hash Function Reference Element Encryption Signature Value Signature ID Element Digital Signature Key Name Digest Value Retrieval Method Digest (SHA-1, SHA-224, Function SHA-256, SHA-384, SHA-512) Data Object Web Services XML Key Info Element Key Info Key Value (DSAKey, RSAKey, X.509Data, PGPData, SPKI Data, Mgmdata) XMLEnc XMLSig XKMS SAML WS-Security M. Mogollon – 01/08 - 28 • The required SignedInfo element is the information that is actually signed. The SignedInfo root element has as child elements the CanonicalizationMethod, the SignatureMethod, and the Reference. • Core validation of SignedInfo consists of two mandatory processes: validation of the signature over SignedInfo and validation of each reference digest within SignedInfo. • The CanonicalizationMethod is the algorithm that is used to canonicalize the SignedInfo element before it is hashed as part of the signature operation. • The SignatureMethod is the algorithm that is used to convert the canonicalized SignedInfo into the SignatureValue. A data object is signed in the same way as is done for a digital signature. First, the message is hashed, and then it is signed with a secret key (symmetric encryption) or with a private key (asymmetric encryption). • Each Reference element includes the digest method and resulting digest value calculated over the identified data object. It also may include transformations that produced the input to the digest operation. • KeyInfo indicates the key to be used to validate the signature. Possible forms for identification include certificates, key names, and key agreement algorithms, among others. KeyInfo is optional for two reasons. First, the signer may not wish to reveal key information to all document processing parties. Second, the information may be known within the application's context and need not be represented explicitly. Since KeyInfo is outside of SignedInfo, if the signer wishes to bind the keying information to the signature, a Reference can easily identify and include the KeyInfo as part of the signature. 28 Web Services Security XML Key Management (XKMS) • XML Key Management specifies protocols for distributing and registering public keys. — Defines the different phases of certificates and keys in XML Signature. • The XML Key Management Specification consist of two parts: — XML Key Information Service Specification (X-KISS), which defines the specifications to locate (retrieve) and validate certificates. — XML Key Registration Service Specification (X-KRSS), which describes a protocol for registration and subsequent management of public key life cycle. Web Services XML XMLEnc XMLSig XKMS SAML WS-Security M. Mogollon – 01/08 - 29 • In general, key management is associated with the generation, distribution, negotiation, exchange, and destruction of crypto variables. However, the XML key management specification specifies protocols for distributing and registering public keys; these protocols are suitable for use in conjunction with the standard for XML signatures and XML encryption. This is mainly a publickey infrastructure issue. • The XML Key Management Specification implements in XML the different phases of certificates and keys. Those specifications are the following: o XML Key Information Service Specification (X-KISS), which defines the specifications to locate (retrieve) and validate certificates. o XML Key Registration Service Specification (X-KRSS), which manages the life cycle of public keys and certificates. • When discussing PKI and certificates, the public key of each user can be authenticated (signed) by a certificate authority. The certificate created by the CA binds the public key to the person or entity who owns the public key. In XKMS, the word “certificate” is not used; instead, “key binding” is used. Also, note that the word “service” in XML key information service and in XML key registration service doesn’t refer to Web services, but only to the service provided by each of them. 29 Web Services Security XKMS Registration Service (Certificate Authority) Trust Service (Repository Site) X-KRSS • Register • Recover • Reissue • Revoke X-KISS • Locate • Validate Client (End-Entity) Client (End-Entity) The Client registers, or requests to recover, reissue, or revoke his public keys and certificates. Web Services PKI Services XML XMLEnc Locate: What are the public key values of a specific user and how they can be used? Validate: What is the binding status between a public-key and a specific user? XMLSig XKMS SAML WS-Security M. Mogollon – 01/08 - 30 • If the Trust Service do not have all the information to validate the query, it may obtain the additional data required from a PKI Service. Once the validity of the key binding has been determined, the XKMS Service returns the status result to the client. 30 Web Services Security XKMS X-KISS Locate LocateResult LocateRequest • Locate ID Number • Locate ID Number • ResultMajor="Success" • Respond With • Request ID – KeyName • Unverified Key Binding – KeyValue – X509Cert • ID – X509Chain • KeyInfo – KeyValue – PGPWeb – X509Certificate – PGP • Query Key Binding • KeyUsage – KeyUsage – Signature – Key Used with Application =“xxxxx“? – Encryption – Owner of the Key ="[email protected]" – Exchange • Key Use with Application=“xxxxxxx" • Owner of the Key ="[email protected]" Web Services XML XMLEnc XMLSig XKMS SAML WS-Security M. Mogollon – 01/08 - 31 • The X-KISS locate service provides directory services, and it answers questions about the publickey values of a specific user and how the key can be used. The request element is QueryKeyBinding, a child element of LocateRequest, and because the service is not required to make an assertion concerning the validity of the binding, the response is UnverifiedKeyBinding, a child element of LocateResult. • In the LocateRequest, the client is querying about a key to encipher a message for the email address [email protected] using Open PGP (RFC 2440) according to the S/MIME Version 3 Message Specification (RFC 3851). The client is querying the service to provide the results as indicated in ResponseWith. • In the LocateResult, the service answers is an UnverifiedKeyBinding meaning that the key binding needs verification. The key values that the client was asking to locate are presented in as part of the KeyInfo. The public key belongs to [email protected], and how it can be used is indicated in KeyUsage. 31 Web Services Security XKMS X-KISS Validate ValidateResult ValidateRequest • • • • • • • Validation ID Number • QueryKeyBinding • KeyUsage • Key Use with Application =“xxxxx“? • Owner of the Key ="[email protected]" • • • • • Web Services XML XMLEnc XMLSig Validate ID Number ResultMajor="Success" Request ID Key Binding ID KeyInfo – KeyValue – X509Certificate KeyUsage – Signature – Encryption – Exchange Key Used with Application=“xxxxxxx" Owner of the Key [email protected] Status Value="Valid"> ValidReason=IssuerTrust …. XKMS SAML WS-Security M. Mogollon – 01/08 - 32 • A location service provides only information that is trustworthy but does not provide any assurance that it is valid. Therefore, the client should validate the information by forwarding the data to a validation service or by performing the necessary trust path verification. The validation service allows the client to obtain the status of the binding between the public key and the data elements. Furthermore, the status of each of the data elements returned is valid and all are bound to the same public key. A validation service only returns information that has been validated by the XKMS service and the client may rely on the information returned by the service without further validation. • The validation process is as follows: The client sends the XKMS service information containing some or all of the elements for which the status of the key binding is required. If the information is incomplete, the XKMS service may obtain the additional data required from a PKI service. Once the validity of the key binding has been determined, the XKMS service returns the status result to the client. • The validation service also provides all of the services provided by the XKISS locate service. 32 Web Services Security XKMS X-KRSS Registration RegistrationResult RegistrationRequest • Registration ID Number • Respond With type of certificate (X.509, …) • Registration ID Number • KeyInfo (Information submitted) • ResultMajor="Success" – KeyValue • Request ID – KeyUsage • KeyInfo – Key Use with Application =“xxxxx“? – KeyValue – Authentication – KeyUsage – KeyBinding – Key Used with Application=“xxxxxxx" – DigestMethod • Status – DigestValue – ValidReason – Proof of Possession The Key Registration Service supports key registration, recovery, reissue, and revocation. Web Services XML XMLEnc XMLSig XKMS SAML WS-Security M. Mogollon – 01/08 - 33 • The Key Registration only supports four services –register, recover, reissue, and revoke. • When clients lose their private keys, they can ask the recovery service to send them a copy. In other words, the private key associated with a key binding is recovered. For key recovery to be possible, the recovery service must have escrowed the private key and, therefore, have a copy. If the registration service doesn’t have a record of the key binding to be recovered, it will respond with NotFound. • The security policy of the issuer may consider it a breach of security when a client loses his private key and, as a result, the key and all of the associated key bindings would be revoked. This is especially true if the key recovery was requested by a third party such as the supervisor of the key holder. • In the revoke service, a previously registered key binding is revoked. A revocation request needs only to contain sufficient information to identify the key binding and the authority requesting the revocation in order to revoke a key binding. 33 Web Services Security Security Assertion Markup Language (SAML) • SAML addresses the issue of Web services access authentication and authorization. — Certificate authorities issue certificates as means of authentication. — SAML uses assertions (credentials) about subjects (individual or an entity). • Assertions are issued by authentication authorities, attribute authorities and policy decision points; they can be passed to other web domains. • SAML provides portable identity authentication and authorization. — Subject is granted or denied access to a specified web domain resource. • Web domains can challenge the assertions, and there should be ways to prove the assertions. • SAML solves the problem of Web Single Sign-On by allowing users to gain access to website resources in multiple domains without having to reauthenticate after initially logging on to the first domain. • SAML is flexible, so it can be used with any XML file transferred within the enterprise or the Internet. Web Services XML XMLEnc XMLSig XKMS SAML WS-Security M. Mogollon – 01/08 - 34 • SAML addresses issues involved with the use of authentication and authorization to Web services. Every time an end-user accesses a Web site on an Intranet or the Internet, it is required to enter a password. For this reason, end-users have many passwords to remember, and many store them in a personal device, such as a cellular phone or a PDA. • On an Intranet, it is possible to use a Single Sign-On (SSO) system as a solution to the problem. Users either use the same password to access all company Web sites, or they are only required to authenticate themselves one time, and then the system automatically assigns them their appropriate access privileges. SSO may solve the problem of multiple passwords inside one organization, but when access is required to other organizations or Web sites on the Internet, the problem still exists because each Web site requires the individuals or entities to identify and authenticate themselves. • Ideally, a subject’s identity would be initially established and verified at a Web domain, and some type of credentials that assert the subject’s identity would be given to the subject. When several Web domains are involved in a transaction, the subject should be able to show the asserted credentials, assertions, to other Web domains to prove his identity to complete the transaction. This requires making the assertion portable. Web services move SOAP messages with attached assertions, entity authentications. This is similar to an individual (message) traveling with a passport (assertion), visiting several countries (Web domains), and each country accepting as identification the same passport. Web domains can challenge an assertion, and there should be ways to prove the assertion. SAML solves the problem of Web single sign-on by allowing users to gain access to website resources in multiple domains without having to re-authenticate after initially logging on to the first domain. • In November 2002, SAML 1.0 became an OASIS standard; Version 1.1 was approved in September 2003 and SAML V2.0 was approved in March 2005. SAML is flexible, so it can be used with any XML file transferred within the enterprise or the Internet. It has been broadly implemented by all major Web access management vendors. 34 Web Services Security SAML Components Profile How the SAML assertions, protocols and bindings are combined to support a defined use case. Bindings How the SAML protocol maps onto the messaging or communications transport protocols. Protocol How assertions are obtained using Request and Response pairs. Assertions Asserts entity’s authentication authorization, and attribute information. Web Services XML XMLEnc XMLSig XKMS SAML WS-Security M. Mogollon – 01/08 - 35 The following is a description of SAML components and subcomponents: 1. Assertions: A package of information provided by an issuer that asserts the authentication, authorization, and attribute information of an entity. For example, an SAML assertion could state that the user is “John Doe”, the user has “Gold” status, the user’s email address is [email protected], and the user is a member of the “engineering” group. SAML defines three kinds of statements that can be carried within an assertion. o Authentication Statement: States that the specified subject was authenticated by a particular means at a particular time. Authentication statements are issued by the party that successfully authenticated the user. The party defines who issued the assertion, the authenticated subject, validity period, plus other authentication related information. o Authorization Statements: States that a particular authentication authority has granted or denied permission to a subject to access the specified resource. It defines what the subject is entitled to do at a specific resource. o Attribute Statement: Provides specific detail about the subject. It associates a subject with the supplied attributes. 2. Protocol: Defines a number of request/response protocols for obtaining assertions. The protocol is encoded in an XML schema as a set of request-response pairs. 3. Binding: Details exactly how the SAML protocol maps onto the messaging or communications transport protocols. For instance, the SAML specification provides a binding of how SAML request/responses are carried with SOAP exchange messages. 4. Profile: Defines how the SAML assertions, protocols, and bindings are combined to support a defined-use case. 35 Web Services Security SAML Push and Pull Profile Models Relying Party www.myhotel.com Asserting Party www.mytravel.com Relying Party www.myhotel.com Asserting Party www.mytravel.com Assertion As s User Browser/Artifact Profile (Push) Web Services XML XMLEnc er ti o n User Browser/POST Profile (Pull) XMLSig XKMS SAML WS-Security M. Mogollon – 01/08 - 36 • There are two SSO profiles used for SubjectConfirmation: Browser/Artifact Profile and Browser/POST Profile. • Both profiles assume the following: o A user has an authenticated session on the local source site (asserting party) using a standard commercial Web browser, using either HTTP or HTTPS. o The user wants to access a resource on the destination Web site and is directed there. o The destination Web site (relying party) needs to determine the identity and entitlements of the user. o The destination site can then make whatever authentication and authorization decisions it needs to, based on the received assertion(s). 36 Web Services Security SAML Artifact (Push) Profile Model Asserting Party Source Site (www.mytravel.com) Authentication Authority Application Portal SAML Request Responder Inter-Site Transfer Service 7 8 SAML Response Destination Site (www.myhotel.com) Artifact Receiver Service Remote Application Access Check 2 Access Check 4 Display Remote Application Links Credential Challenge 1 3 Access Source Site 6 5 User Login Select Remote Application Redirect to Destination + Cookie 9 Redirect with SAML Artifact User’s Browser Web Services XML XMLEnc XMLSig XKMS SAML WS-Security M. Mogollon – 01/08 - 37 The following steps describe the artifact confirmation method profile: 1. The user accesses the source Web site (mytravel.com). 2. The source Web site performs an access check and determines that the user does not have a current session and requires the user to be authenticated. As a result, the user is challenged to authenticate. 3. The user supplies back credentials, for instance, username and password. 4. If the authentication is successful, then a session is created for the user and the appropriate welcome screen of the portal application is displayed. 5. The user selects a menu option (or function) on the displayed screen that indicates that the user wants to access a resource or application on a destination Web site www.myhotel.com. This causes a HTTP request to be sent to the source site's inter-site transfer service. The request contains the target URL, in this case, myhotel.com. 6. The inter-site transfer service generates an assertion for the user while also creating an artifact that contains the source ID of the www.mytravel.com SAML responder, together with a reference to the assertion. The user’s Web browser sends the artifact to the destination Web site, myhotel.com. 7. On receiving the HTTP message, the artifact receiver, on the destination Web site, www.myhotel.com, extracts the source-ID and determines which responder needs to be contacted. The artifact receiver will therefore know that it has to contact the www.mytravel.com SAML responder at the prescribed URL. The www.myhotel.com artifact receiver sends an SAML request to the www.mytravel.com SAML responder containing the artifact supplied by the inter-site transfer service of www.mytravel.com. 8. The www.mytravel.com SAML responder supplies an SAML response message containing the assertion generated during step 7. 9. The artifact receiver, on the destination Web site, www.myhotel.com, sends a redirection message containing a cookie back to the user browser. The user browser sends the cookie, which identifies the session, back to the myhotel.com application where an access check is done to establish whether the user has the correct authorization to access the www.myhotel.com Web site database. 37 Web Services Security SAML Posted (Pull) Profile Models Asserting Party Destination Site (www.myhotel.com) Source Site (www.mytravel.com) Authentication Authority Application Portal Inter-Site Transfer Service Assertion Consumer Remote Application Access Check Access Check 2 4 1 3 Access Local Site 6 Display Remote Application Links Credential Challenge 5 User Login SAML Response with Assertion in HTPP Form Select Remote Application Redirect to Destination + Cookie 7 8 POST Form with Direct Assertion User’s Browser Web Services XML XMLEnc XMLSig XKMS SAML WS-Security M. Mogollon – 01/08 - 38 The following steps describe the POST confirmation method profile: 1. Same for artifact confirmation method profile. 2. Same for artifact confirmation method profile. 3. Same for artifact confirmation method profile. 4. Same for artifact confirmation method profile. 5. Same for artifact confirmation method profile. 6. The inter-site transfer service signs the user’s assertion and sends back to the user’s browser an SAML response that contains the user’s SAML assertion. 7. The user’s browser issues an HTTP POST form containing the SAML response and sends it to the destination party’s (www.myhotel.com) assertion consumer service. 8. The destination party's assertion consumer service validates the digital signature on the SAML response. If the digital signature is valid, it sends a redirect to the user’s browser causing it to access the destination application. An access check is made to establish whether the user has the correct authorization to access the www.myhotel.com Web site and its applications. 38 Web Services Security Web Services Security Model WS-Secure Conversation WS-Federation WSAuthorization WS-Policy WS-Trust WS-Privacy WS-Security SOAP Foundation • • Security model was proposed by IBM and Microsoft in April 2002. • Security model brings together formerly incompatible security technologies such as public key infrastructure, Kerberos, and others. • It also provides a broad set of specifications that cover security technologies, including authentication, authorization, privacy, trust, integrity, confidentiality, secure communications and auditing, across a wide spectrum of application and business topologies. Also proposed was a road map for developing a set of Web Service Security specifications to protect SOAP messages exchange in a Web service environment. Web Services XML XMLEnc XMLSig XKMS SAML WS-Security M. Mogollon – 01/08 - 39 • Figure above shows the Web services security stack that IBM and Microsoft are following. According to the whitepaper, this stack includes a message security model (WS-Security) that provides the basis for other security specifications. Layered on this, the policy layer includes a Web service endpoint policy (WS-Policy), a trust model (WS-Trust), and a privacy model (WSPrivacy). Follow-up specifications for federated security will include secure conversations (WSSecureConversation), federated trust (WS-Federation), and authorization (WS-Authorization). • The whitepaper describes the different layers as follows: o WS-Security: How to attach signature and encryption headers to SOAP messages. In addition, it describes how to attach security tokens, including binary security tokens such as X.509 certificates and Kerberos tickets, to messages. o WS-Policy: The capabilities and constraints of security (and other business) policies on intermediaries and endpoints (e.g. required security tokens, supported encryption algorithms, privacy rules) o WS-Trust: A framework for trust models that enable Web services to securely interoperate o WS-Privacy: A model for how Web services and requesters state privacy preferences and organizational privacy practice statements o WS-SecureConversation: How to manage and authenticate message exchanges between parties, including security context exchange and establishing and deriving session keys o WS-Federation: How to manage and broker the trust relationships in a heterogeneous federated environment, including support for federated identities o WS-Authorization: How to manage authorization data and authorization policies 39 Web Services Security Web Services Security Language • Describes how to attach signature and encryption headers to SOAP messages. • Describes how to attach security tokens, including binary security tokens such as X.509 certificates and Kerberos tickets, to messages. • Web Services are designed to work over any transport protocol, HTTP, TCP, UDP, email (SMTP), FTP. • Provides security when a message flows over different transport protocols and through multiple servers. • Portions of the message can be secure for different parties. Specific recipients of the message are allow to see certain parts of the message. Web Services XML XMLEnc XMLSig XKMS SAML WS-Security M. Mogollon – 01/08 - 40 • As stated in the security model whitepaper, WS-Security defines methods for embedding security in SOAP messages, e.g., credential exchange, message integrity, and message confidentiality. WSSecurity differs from SAML in that SAML defines how security assertions are expressed in XML format, and WS-Security defines how security is expressed in SOAP messages. • WS-Security states that security information should be contained in SOAP messages as follows: o If XML signature is used, the header should contain the signature information that conveys how the message was signed, the key that was used, and the resulting signature value. o If an element within the message is encrypted, the header should contain the encryption information that conveys the key that was used and how both parties arrived at the same secret key. Credentials, also called access authentication, identification, or security tokens, also should be within the headers. In wsse:Security, credentials are implemented in the header. o The encrypted message element should be contained in the message body. 40 Web Services Security SOAP Message Security SOAP Message HTTP Originator Intermediary SOAP Message TCP Recipient End-to-end SOAP security • Intermediary should not be able to — Alter the message (Insertion, Deletion, Modification) — Read the message (Confidentiality) — Falsify messages • Originator and recipient should not be able to repudiate the message. • Recipient should be able to determine if the message has changed (Integrity) Web Services XML XMLEnc XMLSig XKMS SAML WS-Security M. Mogollon – 01/08 - 41 41 Web Services Security WS-Security Syntax [1] [1a] [2] [2a] [3] [3a] [4] [4a] <S:Envelope xmlns:S11="..." xmlns:wsse="..."> <S:Header> <wsse:Security> <wsse:UsernameToken> <wsse:Username>Zoe</wsse:Username> </wsse:UsernameToken> <ds:Signature> <ds:Reference URI=#body”> <ds:Signature> <xenc:ReferenceList> <xenc:DataReference URI=”body”/> <xenc:ReferenceList> </wsse:Security> </S:Header> <S:Body> <xenc:EncryptedData Id=body” ype=”content”> </xenc:EncryptedData> </S:Body> </S:Envelope> Web Services XML XMLEnc XMLSig SOAP Envelope SOAP Security Header Security Header Block Security Tokens, XML Signatures, Key Reference List or Encrypted Key Security Header Block SOAP Body Encrypted Data XKMS SAML WS-Security M. Mogollon – 01/08 - 42 • The security header parent element, <wsse:Security>, provides a mechanism for attaching securityrelated information targeted at a specific recipient; this may be either the ultimate recipient of the message or an intermediary. • The security header parent element has the following child elements: o Security Token o XML Signature o XML Encryption Reference. 42 Web Services Security WS-Security – Security Tokens • Security Tokens are access mechanisms and methods used for authentication and authorization. • Passwords are a type of unsigned security tokens. • Signed security tokens are security tokens that are asserted and cryptographically signed by a specific authority (e.g., an X.509 certificate or a Kerberos ticket). • Security Tokens in WS-Security are grouped in the following way: — UserName Token (User ID and password) — BinarySecurity Token (X.509 certificates and Kerberos) — XML Tokens Web Services XML XMLEnc XMLSig XKMS SAML WS-Security M. Mogollon – 01/08 - 43 • What is the difference between security tokens and assertions? 43 Web Services Security WS-Security – XML Signature • Signature in WS-Security is simply the XML Signature placed in the security header of a SOAP message. • XML Signature in WS-Security can be used by the message recipient to — Authenticate or verify the security token, such as an X.509 certificate or SAML assertion. — Verify that the message has not been modified in transit, for message integrity. • It is possible to sign a message before encryption or to encrypt it first and then sign it. The way in which it is done needs to be indicated in the syntax by placing either the encryption or the signing element first in the syntax. Web Services XML XMLEnc XMLSig XKMS SAML WS-Security M. Mogollon – 01/08 - 44 If encryption is done first, then the syntax should be <S:Envelope xmlns:S11="..." xmlns:wsse="..."> [1] <S:Header> [1a] <wsse:Security> [1a1 [encryption element] [1a2] [signature element] </wsse:Security> </S:Header> [2] <S:Body> ...... <</S:Body> </S:Envelope> If signing is done first, then the syntax should be <S:Envelope xmlns:S11="..." xmlns:wsse="..."> [1] <S:Header> [1a] <wsse:Security> [1a1 [signature element] [1a2] [encryption element] </wsse:Security> </S:Header> [2] <S:Body> ...... <</S:Body> </S:Envelope> 44 Web Services Security WS-Security – Referent List or Encrypted Key. • ReferenceList points out which part of the message body was encrypted. — Used when the sender and the receiver of the SAML message use a shared secret key to encipher the message body, and there is a need to send the key. • EncryptedKey is used when the parties have not exchanged secret keys previously and it is necessary to transport the secret key in a secure manner. — Encipher or wrap the secret key for transport using a public key system. — A randomly generated symmetric key is encrypted using the recipient’s public key. Web Services XML XMLEnc XMLSig XKMS SAML WS-Security M. Mogollon – 01/08 - 45 EncryptedKey: <S:Envelope xmlns:S11="..." xmlns:wsse="..." xmlns:wsu="..." xmlns:ds="..." xmlns:xenc="..."> [1] <S:Header> [1a] <wsse:Security> [1a1] <xenc:EncryptedKey> ………….. [1a1a] <ds:KeyInfo> [1a1a1] <wsse:SecurityTokenReference> [1a1a1a] <ds:X509IssuerSerial> <ds:X509IssuerName>DC=ACMECorp, DC=com</ds:X509IssuerName> <ds:X509SerialNumber>12345678</ds:X509SerialNumber> </ds:X509IssuerSerial> </wsse:SecurityTokenReference> </ds:KeyInfo>………………..... </xenc:EncryptedKey>………………... </wsse:Security> </S:Header> [2] <S:Body> [2a] <xenc:EncryptedData Id="bodyID"> [2a1] <xenc:CipherData> [2a1a] <xenc:CipherValue>...</xenc:CipherValue> </xenc:CipherData> </xenc:EncryptedData> </S:Body> 45 Web Services Security References • Atkinson, B., et al. (2002). Web Services Security (WS-Security). Retrieved August 31, 2004, from http://www106.ibm.com/developerworks/webservices/library/ws-secure/ • Bartel, M., et, al. (2002). XML-Signature Syntax and Processing. Retrieved September 2, 2004, from http://www.w3.org/TR/xmldsig-core/. • Bellwood, T., et al. (2003). UDDI Version 3.0.1 Technical Specification. Retrieved September 14, 2004, from http://uddi.org/pubs/uddi_v3.htm • Bray, T., et al. (2004). Extensible Markup Language (XML) 1.0 (Third Edition). Retrieved August 23, 2004, from http://www.w3.org/TR/2004/RECxml-20040204/ • Chinnici, R., et al. (2004). Web Services Description Language (WSDL) Version 2.0. Retrieved September 27, 2004, from http://www.w3.org/TR/wsdl20/ • Hallam-Baker, P., et al. (2004). XML Key Management Specification (XKMS 2.0). Retrieved October 7, 2004 from http://www.w3.org/TR/xkms2/ • Hughes, J., et al. (2004). Security Assertion Markup Language (SAML) 2.0 Technical Overview, Working Draft 01. (Retrieved October 5, 2004, from http://xml.coverpages.org/SAML-TechOverviewV20-Draft7874.pdf Web Services XML XMLEnc XMLSig XKMS SAML WS-Security M. Mogollon – 01/08 - 46 46 Web Services Security References • Imamura, T., Dillaway, B., Simon, E., (2002). XML Encryption Syntax and Processing. Retrieved August 25, 2004, from http://www.w3.org/TR/xmlenc-core/ • Mitra, N., et al. (2003). SOAP Version 1.2 Part 0: Primer. Retrieved September 23, 2004 from http://www.w3.org/TR/2003/REC-soap12-part0-20030624/ • Nadalin, A., et al. (2004). Web Services Security: SOAP Message Security 1.0. Retrieved October 1, 2004, from http://docs.oasis-open.org/wss/2004/01/oasis200401-wss-soap-message-security-1.0.pdf • O’Neill, M., et al. (2003). Web Services Security. Berkeley, California:McGrawHill/Osborne. • Rosenberg, J., Remy, D. (2004). Securing Web Services with WS-Security. Indianapolis, Indiana: SAMS Publishing. • Security in a Web Services World: A Proposed Architecture and Roadmap. Version 1.0 A Joint White Paper from IBM Corporation and Microsoft Corporation, April 7, 2002. Retrieved October 8, 2004, from http://msdn.microsoft.com/library/default.asp?url=/library/enus/dnwssecur/html/securitywhitepaper.asp • Wolter, R. (2001). XML Web Services Basics. Microsoft Corporation. Retrieved September 13, 2004, from http://msdn.microsoft.com/library/default.asp?url=/library/enus/Dnwebsrv/html/webservbasics.asp?frame=true Web Services XML XMLEnc XMLSig XKMS SAML WS-Security M. Mogollon – 01/08 - 47 47 Web Services Security To Probe Further • Digital signatures for SOAP messages, a developerWorks tutorial by Jayanthi Suryanarayana, explains how to digitally sign and encrypt your SOAP messages for security. • The XML Security Suite: Increasing the security of e-business by Doug Tidwell presents some basics of Web security, describes the components of the XML Security Suite, and gives examples that illustrate how the technologies in the XML Security Suite increase the security of Web commerce. • The OASIS consortium site includes The XML Cover Pages: XML and Encryption, Robin Cover' active diary of activities and publications relevant to these issues. The site also features a draft document specifying the Security Assertion Markup Language (SAML). • The W3C working draft XML Encryption Requirements lists the design principles, scope, and requirements for the XML Encryption. It includes requirements as they relate to the encryption syntax, data model, format, cryptographic processing, and external requirements and coordination. • XML-Signature Requirements lists the design principles, scope, and requirements for the XML Digital Signature specification. It includes requirements as they relate to the signature syntax, data model, format, cryptographic processing, and external requirements and coordination. • Decryption Transform for XML signature specifies the "decryption transform," which enables XML signatures verification even if both signature and encryption operations are performed on an XML document. Web Services XML XMLEnc XMLSig XKMS SAML WS-Security M. Mogollon – 01/08 - 48 48 Web Services Security XML Encryption Encrypted Type Encrypted Data Encrypted Key Block Encryption Encrypting Method 3DES AES, 128, 192, 256 Stream Cipher Key Info Encrypted Key Agreement Method Wrapping the Key 3DES AES, 128, 192, 256 Transporting the Key RSA-v1.5 RSA-OAEP Key Name Retrieval Method Cipher Data Cipher Value Cipher Reference Web Services XML XMLEnc XMLSig XKMS SAML WS-Security M. Mogollon – 01/08 - 49 49 Web Services Security XML Key Registration Service Register Service Client Register Request The Web Service Provider or the Web Service Requester registers, or requests to recover, reissue or revoke their public keys and certificates. Register Response Recover Request Recover Response Reissue Request Reissue Response Revoke Request Revoke Response Web Services XML XMLEnc XMLSig XKMS SAML WS-Security M. Mogollon – 01/08 - 50 50 Web Services Security XML Key Information Service X-KISS PKI Services Trust Service Client Locate Request Locate Result Validate Request Validate Response The Web Service Requester requests the location and validation of the public keys and certificates of service Web Services XML XMLEnc XMLSig XKMS SAML WS-Security M. Mogollon – 01/08 - 51 51 ...
View Full Document

This note was uploaded on 05/26/2010 for the course TECH 6350 taught by Professor Mogollon during the Spring '10 term at University of Arkansas for Medical Sciences.

Ask a homework question - tutors are online