D.3. Web Service Fundamentals

D.3.1. SOA: Service Oriented Architecture

402. Service-oriented architecture (SOA) is a software architecture where functionality is grouped around business processes and packaged as interoperable services. SOA also describes IT infrastructure which allows different applications to exchange data with one another as they participate in business processes. The aim is a loose coupling of services with operating systems, programming languages and other technologies which underly applications. SOA separates functions into distinct units, or services, which are made accessible over a network in order that they can be combined and reused in the production of business applications. These services communicate with each other by passing data from one service to another, or by coordinating an activity between two or more services.

403. The following figure shows an overview about the internal and external Web Service Architecture:

Figure D.1. Overview – Internal and External Web Service Architecture

404. There are multiple definitions of SOA. The OASIS group and the Open Group have created formal definitions which can be applied to both the technology and business domains.

Open Group SOA Definition (SOA-Definition)
OASIS SOA Reference Model (SOA-RM)

405. In addition, SOA is an approach to architecture whereby business services are the key organizing principles that drive the design of IT to be aligned with business needs.

406. The following figure shows the Web Service Specification in an OSI Stack Model.

Figure D.2. Web Service Architecture – OSI Stack Model

407. On top of there are the applications (Server or Client applications). In the Web Service Architecture the UDDI (Universal Description Discovery and Integration) is signed as an application.

D.3.2. UDDI: Universal Description Discovery and Integration

408. The Universal Description, Discovery, and Integration (UDDI) protocol defines a standard method for publishing and discovering the network-based software components of a service-oriented architecture (SOA). The standard specifies protocols for accessing a registry for Web services, methods for controlling access to the registry, and a mechanism for distributing or delegating records to other registries. In short, a UDDI registry provides a standard based approach to locate a software service, to invoke that service, and to manage metadata about that service. The following figure shows the principle of the UDDI Architecture with SOAP (messaging) for the methods of the "Inquiry and Publisher API".

Figure D.3. UDDI Overview Architecture based on SOAP

409. The next figure shows the main extract of the UDDI Data Model (used in the "Data Pool").

Figure D.4. Main extract of the UDDI Data Model

410. An other very important feature is to exchange UDDI Data between different UDDI Registries for example as show in the next figure. In addition, it is necessary to distinguish between internal services and external offered services.

Figure D.5. UDDI illustration of Trading Partner Collaboration

D.3.3. WSDL: Web Services Description Language

411. Web Services Description Language (WSDL) is an XML-based Service / Interface Definition Language that separates function from implementation and enables design by SOA.

412. The value of WSDL is that it enables development tools and middleware for any platform and language to understand service operations and invocation mechanisms. For example, given the WSDL interface to a service that is implemented in Java, running in a HTTP-Server environment, and offering invocation through HTTP.

413. With SOAP, the WSDL specification is extensible and provides for additional aspects of service interactions to be specified, such as security and transactional.

414. The following figure shows the principle structure of a WSDL Document and its usage:

Figure D.6. WSDL Document Structure (with usage)

415. WSDL description contain:

Types – a container for data type definitions using some type system (such as XSD).
Message – an abstract, typed definition of the data being communicated.
Operation – an abstract description of an action supported by the service.
Port Type – an abstract set of operations supported by one or more endpoints.
Binding – a concrete protocol and data format specification for a particular port type.
Port – a single endpoint defined as a combination of a binding and a network address.
Service – a collection of related endpoints.

416. The WSDL Document format is based on XML as illustrated in the example figure below.

Figure D.7. Example of a WSDL Document Structure

D.3.4. SOAP: Simple Object Access Protocol

417. SOAP is an XML–based format for constructing messages in a transport PDU independent way and a standard on how the message should be handled. SOAP messages consist of an envelope that contains a header and a body. It also defines a mechanism for indicating and communicating problems that occurred while processing the message, which are known as SOAP faults.

Figure D.8. SOAP Message Structure

Figure D.9. SOAP Message Example

418. The headers section of a SOAP message is extensible and can contain many different headers that are defined by different schemas. The extra headers can be used to modify the behaviour of the middleware infrastructure. For example, the headers can include information about transactions that can be used to ensure that actions performed by the service consumer and service provider are coordinated.

419. The body section contains the content of the SOAP message. When used by Web services, the SOAP body contains XML – formatted data. This data is specified in the WSDL that describes the Web service.

420. Remark: The Header Block and the Body Block are in XML format, but contain customer designed content. SOAP doesn't define this content. For having standards it is necessary to define data models (including metadata of the content).

421. When talking about SOAP, it is common to talk about SOAP in combination with the transport protocol that is used to communicate the SOAP message. For example, SOAP that is transferred using HTTP is referred to as SOAP over HTTP or SOAP/HTTP.

422. The most common transport protocol that is used to communicate SOAP messages is HTTP. This is expected because Web services are designed to make use of Web technologies.

423. However, SOAP can also be communicated using JMS as a transport service. When using JMS, the address of the Web service is expressed in terms of a JMS connection factory and a JMS destination. Although using JMS provides a more reliable transport mechanism, it is not an open standard, requires extra and potential expensive investment, and does not interoperate.

424. SOAP is just XML and HTTP combined to send and receive messages over the Internet. It is not constrained by the application language (Java, C#, Perl) or the platform (Windows, UNIX, Mac), and this makes it much more versatile than other solutions.

425. There are many successful implementations of the basic Web services standards, particularly SOAP and WSDL but many aspects of service interaction and integration are not directly supported by basic standards, such as security, transactional, delivery assurance, and process modelling – for example.

D.3.5. WEB Service Security

D.3.5.1. XML Encryption

426. XML Encryption is a W3C Standard to encrypt XML. It is done in such a way that the encrypted data remains and can be treated as XML. It uses both asymmetric and symmetric encryption algorithms, symmetric to encrypt the data and asymmetric to encrypt the symmetric session key. Both the session key and the cipher data are stored together in an XML element called EncryptedData. The EncryptedData element contains a series of child elements that describe the algorithms used during the encryption process, as well as containing key information and the cipher data.

427. The followings XML example illustrates a simple example of the XML Encryption:

428. Consider the following fictitious payment information, which includes identification information and information appropriate to a payment method (e.g., credit card, money transfer, or electronic check):

Figure D.10. XML Encryption

429. This markup represents that John Smith is using his credit card with a limit of $5,000USD. Smith's credit card number is sensitive information! If the application wishes to keep that information confidential, it can encrypt the CreditCard element:

Figure D.11. XML Encryption

430. By encrypting the entire CreditCard element from its start to end tags, the identity of the element itself is hidden. (An eavesdropper doesn't know whether he used a credit card or money transfer). The CipherData element contains the encrypted serialization of the CreditCard element.

D.3.5.2. XML Signature

431. XML Signature (also called XMLDsig, XML-DSig, XML-Sig) is a W3C recommendation that defines an XML syntax for digital signatures. XML signatures can be used to sign data –a resource– of any type, typically XML documents, but anything that is accessible via a URL can be signed. An XML signature used to sign a resource outside its containing XML document is called a detached signature; if it is used to sign some part of its containing document, it is called an enveloped signature; if it contains the signed data within itself it is called an enveloping signature.

432. XML digital signatures are represented by the Signature element which has the following structure (where "?" denotes zero or one occurrence; "+" denotes one or more occurrences; and "*" denotes zero or more occurrences):

Figure D.12. XML Signature

433. Within an XML document, signatures are related to local data objects via fragment identifiers. Such local data can be included within an enveloping signature or can enclose an enveloped signature. Detached signatures are over external network resources or local data objects that reside within the same XML document as sibling elements; in this case, the signature is neither enveloping (signature is parent) nor enveloped (signature is child). Since a Signature element (and its ID attribute value/name) may co-exist or be combined with other elements (and their IDs) within a single XML document, care should be taken in choosing names such that there are no subsequent collisions that violate the ID uniqueness validity constraint [XML].

D.3.5.3. XML Token

434. A security token represents the user's claims and it's used by the Authentication Service for authenticate him. There are two kinds of security tokens:

X.509 certificate
SAML Assertion

435. In this document we discuss only the "SAML Assertion" in an additional point (not the X.509 certification).

436. The following XML example shows a SAML Token:

Figure D.13. SAML Token

437. The following figure shows the three XML security methods code in a SOAP (XML) Message.

Figure D.14. SOAP Security based on XML Encryption & Signature & Token

D.3.5.4. XKMS: XML Key Management Specification

438. The XKMS specifies protocols for distributing and registering public keys, suitable for use in conjunction with the proposed standard for XML Signatures [XML-SIG] and an anticipated companion standard for XML encryption. The XML Key Management Specification (XKMS) comprises two parts – the XML Key Information Service Specification (X-KISS) and the XML Key Registration Service Specification (X-KRSS):

XML Key Information Service Specification (X-KISS) : A protocol to support the delegation by an application to a service of the processing of Key Information associated with an XML signature, XML encryption, or other public key. Its functions include the location of required public keys and describing the binding of such keys to identification information.
XML Key Registration Service Specification (X-KRSS): A protocol to support the registration of a key pair by a key pair holder, with the intent that the key pair subsequently is usable in conjunction with the XML Key Information Service Specification or higher level trust assertion service such as XML Trust Assertion Service Specification (XTASS).

439. The underlying PKI may be based upon a different specification such as X.509/PKIX, SPKI or PGP – proposal: X.509/PKIX.

440. Example for X-KISS:

441. The client is attempting to send an encrypted XML document and requires the public key encryption parameters of the recipient.

Figure D.15. SOAP Security based on XML Encryption & Signature & Token

D.3.5.5. SAML: Security Assertion Markup Language / SAML Architecture

D.3.5.5.1. SAML: Security Assertion Markup Language

442. Security Assertion Markup Language (SAML) is an XML-based standard for exchanging authentication and authorization data between security domains, that is between an identity provider (a producer of assertions) and a service provider (a consumer of assertions). SAML is a product of the OASIS Security Services Technical Committee.

443. The normal use case of SAML is support the Single Sign-On (SSO) issue, but SAML is also used for Identity Federation. SSO represents the ability of a user to authenticate in one domain and use resources in another domain WITHOUT re-authenticating. SAML is an XML Framework for exchanging security information over the internet. It enables different security services systems to INTEROPERATE.

444. The core SAML specification defines the structure and content of both assertions and protocol messages used to transfer this information. The next Figure illustrates the relationship between these basic SAML concepts.

445. SAML assertions carry statements about a principal that an asserting party claims to be true. The valid structure and contents of an assertion are defined by the SAML assertion XML schema. Assertions are usually created by an asserting party based on a request of some sort from a relying party, although under certain circumstances, the assertions can be delivered to a relying party in an unsolicited manner. SAML protocol messages are used to make the SAML-defined requests and return appropriate responses. The structure and contents of these messages are defined by the SAML-defined protocol XML schema.

Figure D.16. Basic SAML Concepts

446. An assertion is a claim made by someone about someone else. SAML assertions are structured as a series of statements about a subject: Authentication, Attribute, Authorization Decision, or by an own customized statements. SAML defines three kinds of statements that can be carried within an assertion:

Authentication statements: These are created by the party that successfully authenticated a user. At a minimum, they describe the particular means used to authenticate the user and the specific time at which the authentication took place.
Attribute statements: These contain specific identifying attributes about the subject (for example, that user "John Doe" has "Gold" card status).
Authorization decision statements: These define something that the subject is entitled to do (for example, whether "John Doe" is permitted to buy a specified item).

447. The following example shows a common portion Assertion:

Figure D.17. Assertion

448. An assertion contains one or more statements and some common information that applies to all contained statements or to the assertion as a whole. A SAML assertion is typically carried between parties in a SAML protocol response message, which itself must be transmitted using some sort of transport or messaging protocol.

449. The next Figure shows a typical example of containment: a SAML assertion containing a series of statements, the whole being contained within a SAML response, which itself is carried by some kind of protocol.

Figure D.18. Relationship of SAML Components and Protocol Container

450. The means by which lower-layer communication or messaging protocols (such as HTTP or SOAP) are used to transport SAML protocol messages between participants is defined by the SAML bindings.

451. SAML defines a number of generalized request/response protocols:

Authentication Request Protocol
Single Logout Protocol
Assertion Query and Request Protocol
Artifact Resolution Protocol
Name Identifier Management Protocol
Name Identifier Mapping Protocol

452. SAML profiles are defined to satisfy a particular business use case, for example the Web Browser SSO profile. Profiles typically define constraints on the contents of SAML assertions, protocols, and bindings in order to solve the business use case in an interoperable fashion.

D.3.5.5.2. SAML Architecture (Web Security Architecture)

453. The following figure shows the chain of an access to a Service or to a Resource and the co-operation with the IT Security Services. The main SAML IT Security Services are:

Policy Enforcement Point (PEP): A Policy Enforcement Point (PEP) at the resource provider formulates an authorization decision request (SAML or XACML) using the attributes and other information in the security context. The PEP sends this request to a Policy Decision Point.
Policy Decision Point (PDP): The Policy Decision Point (PDP) combines the information in the request with policy obtained from a central policy store. The PDP renders an access control decision, which is returned to the PEP.
Policy retrieval point (PRP): The component from which applicable policies may be retrieved. The communication protocol between PDP and PRP is XACML.
Policy Administration Point (PAP): A Policy Administration Point (PAP) maintains authorization policy in a central location. The policy store is made available to the PRP for access control decisions.
Policy Information Point (PIP): A Policy Information Point validates the specific attributes that are used for authorization.

Figure D.19. SAML Architecture (Overview)

454. The step sequence by an access of a client is:

1. Login based on a certificate;
2. Before an access the user needs may be some keys, which he can get via the Public Key Infrastructure using for example XKISS.
3. Service Consumer invokes a Service which was published earlier. The user (consumer) sends a request (SOAP message) via the Middleware Service Broker to the Provider. The SOA Middleware forwards the request to the PEP.
4. The PEP (Policy Enforcement Point) will capture the requirement for a service and pass the SAML onto the PDP for authentication and authorization validation of the obligation service.
5. The PDP receives the 'Authorization Decision Request' and requests a 'Policy Query' to the PRP. The PRP response with a 'Policy Statement'.
6. In addition the PDP checks some more, the User, Resource, and/or Context Attributes via some additional 'Statement Services'.
7. Based on the check results (Policy and Statements) the PDP decides the access (permit, deny, not applicable or indeterminate).
8. The PEP receives the access result, triggers the logging and the flow control.
9. If all access requests are valid, the PEP forwards the user request to the provider.
10. The Service Provider supports the user request.