288.
289. The World Wide Web Consortium (W3C) is an international consortium aiming to enable the full scope of possibilities for and to ensure continuous growth of the World Wide Web by standardization (protocols and guidelines).
290. The challenge when creating open, standardized service endpoints and a standardized SOA-(ESB-) infrastructure is the development of lists of standards that a SOA-environment must support. This list of standards should form a kind a profile in order to create a uniform access to the service-endpoints.
291. There are efforts by the W3C, to define a profile – the WS-I Basic Profile – that could be used as basis for a service-endpoint.
292. However, not all capabilities/requirements related to overarching and shared services of a SOA-(ESB-) infrastructure, e. g. related to registry, repository or policies are included in the standards.
293. Generally a SOA (ESB) must not support all standards. But the more a SOA (ESB) is employed overarchingly in heterogeneous IT-sceneries, the more the extended WS* - Specifications gain importance.
294. The following table summarizes the capabilities, the existing technologies and the associated related WS* -Specifications in an overview.
| SOA capability | Existing ESB Technology | Related WS*-Specification |
|---|---|---|
| Secure Communication Channel | SSL, HTTPS | WS-Security, WS-Secure Conversation |
| Authentication | PKI Digital Certification | WS-Trust, SAML, WS-Federation |
| Message Payload Encryption and Signature | Standard Cipher Suites | WS-Encryption WS-Signature |
| Access Control List | LDAP, JMX, proprietary | XACML |
| Publish and Subscribe | JMS, proprietary | WS-Notification, WS-Eventing |
| Service Endpoint Description | WSDL, LDAP, JNDI, proprietary | WSDL, WS*-Policy, SOAP 1.2 F and P |
| Reliable Messaging | JMS, proprietary MOM | WS-ReliableMessaging |
| Itinerary-based Routing | WSDL, proprietary | WSDL, WS-Addressing |
| Business Process Orchestration | Proprietary | WS-BPEL, WS-Choreography, proprietary |
| Transaction | JTA, JCA, XA, proprietary | WS-Coordination WS-Transaction WS-Atomic Transaction WS-Business Activity, WS-CAF |
295. As ESB-profile for open, standardized service-endpoints the WS-I Basic Profile V1.1 (an extension of the WS-I Basic Profile V1.0) including some extensions with the following parts could be a good choice:
WS-I Web Service Basic Profile, v1.1:2nd ed. 2006
WS-I Simple SOAP Binding Profile v1.0:2004
296. The following standards are included:
Simple Object Access Protocol (SOAP) 1.1;
RFC2616: Hypertext Transfer Protocol -- HTTP / 1.1;
RFC2965: HTTP State Management Mechanism;
Extensible Markup Language (XML) 1.0 (Second Edition);
Namespaces in XML 1.0;
XML Schema Part 1: Structures;
XML Schema Part 2: Data types;
Web Services Description Language (WSDL) 1.1;
UDDI Version 2.04 API Specification;
UDDI Version 2.03 Data Structure Reference;
UDDI Version 2 XML Schema;
RFC2818: HTTP Over TLS;
RFC2246: The TLS Protocol Version 1.0;
The SSL Protocol Version 3.0;
RFC2459: Internet X.509 Public Key Infrastructure Certificate and CRL Profile.
297. For interoperability reasons further standards should be included, that are currently neither within the WS-I Profile nor in the NATO ADatP-34 NISP-Vol2-v2:
TCP (IETF STD 7:1981, RFC0793:1981 updated by RFC3168:2001);
UDP (IETF STD 6:1980, RFC0768:1980);
XML Encryption Syntax and Processing (W3C Recommendation 10 December 2002);
XML Signature Syntax and Processing Second Edition (W3C Recommendation 10 June 2008);
Security Assertion Markup Language, SAML v1.1 (OASIS);
XKMS: XML Key Management Specification (W3C Note 30 March 2001);
XACML eXtensible Access Control Markup Language Version 2.0 (OASIS Standard, 1 Feb 2005).
298. The examination of standards to be considered gives the following requirement for an open, standardized service-endpoint of the reference environment for services (SRE):
The open, standardized procedures for access and provision of service-endpoints provided through an ESB (ESB-stub and SOA-(ESB-) infrastructure) must be based on an extended WS-I profile.
299. Besides the standardized service-interfaces (open service-endpoints), the service layer of the SOA-model encompasses the mechanisms for service administration as well as specialized services. In the broader sense the specialized services are cross-functions for an ESB.
300. To make services work it takes more than SOAP, WSDL and UDDI. Services must work with different security-levels. Complex processes between several services must be able to execute related roll-back-mechanisms as transactions. Also routing and general Quality-of-Service rules are of importance in a global infrastructure
301. Further on services must be labeled with defined Service Level Agreements in order to sufficiently define their quality features.
302. A global service-architecture, that provides a SOA-(ESB-) infrastructure for services, can be illustrated as a layer-model composed of a Core Layer and a Higher Layer.
Core Layer: The core layer of the architecture comprises XML and SOAP. XML is the basis of all formats and protocols. As a default SOAP can be transferred via TCP / IP and HTTP. The flexibility of SOAP also allows other transfer protocols.
Higher Layer: The higher layer comprises for example a directory-service (Registry) and security-services (X.509 or SAML). This layer is composed of a variety of additional products and consists of standards like e.g. the WS*-Specification: WS*-Security, WS-ReliableMessaging, WS-Reliable or WS*-Transaction.
303. Now we look at services that are necessary for the provision of a service (service infrastructure). They are the SOA-(ESB-) infrastructure.
304. From the SOA-perspective the specialized services, that form the SOA-(ESB-) infrastructure, are also „just services“, which in turn are based on SOA-mechanisms.
305. Under consideration of the SRE capability 3 (The reference environment for services (SRE) is based on different classifications of the providers (service classes)) the specialized services of the SOA-(ESB) infrastructure form a superior, self-sufficient service-class on the ESB. A service of the specialized services of the SOA-(ESB-) infrastructure is either self-sufficient (does not use further services), or uses only services of self-sufficient service sub-classes of the SOA-(ESB-) infrastructure.
306. The necessary SOA-(ESB-) infrastructure (specialized services) resulting from the use of services leads to the following capabilities/requirements for the ESB:
For the use of a service the consumer as well as the provider needs information (e.g. service description) and infrastructure-services (e.g. policies) that have to be provided by the SOA-(ESB-) infrastructure.
The services of the SOA-(ESB-) infrastructure by themselves form a service, that is based on the ESB-mechanisms in an analog manner to the application-services (provider) and which are necessary for the provision of an application-service.
The services of the SOA-(ESB-) infrastructure constitute service-classes (e.g. the core services of a directory service and the security services), that are structured hierarchically, and are either self-sufficient or must be based on services of self-sufficient service-classes.
307. The next two chapters deal with the essential components like the directory service (Registry and Repository) and the services and the procedure for the area of security. A SOA-(ESB-) infrastructure comprises much more specialized services that are being used by consumers and providers and further specialized services that are necessary to ensure operations of an ESB-configuration.
308. As these further specialized services fulfill specific tasks they are not dealt with in detail in this chap-ter. Rather, they are described in more detail in the respective subject areas. There, the correspond-ing capability requirements will be derived.
309. Currently, the following core series are recommended for the tact ESB:
310. One of the functions of a Registry and Repository System is the cataloging of all service information. A Registry and Repository System regulates first and foremost the collaboration of management and monitoring tools which in turn enable run-time policies or Service Level Agreements (SLAs) to be monitored. To this end, the Registry and Repository System automatically analyses run-time data. The registry must be closely interlocked with the ESB, as well as with the management and monitoring tools.
311. Due to the fact that in the military field, mobile and stationary systems are employed and that larger and smaller platforms are necessary in the application, SRE prefers the inclusion of separate Registry and Repository Systems.
312. In doing so, the ESB Service Repository, is used more for configuration management (Metadata Re-pository). The ESB Service Repository supports the whole life cycle of processes, policies and services. Conversely, the ESB Service Repository is used as an operational service of the SOA (ESB) and hereby supports the administration, control, search and definition of services throughout the life-span of the ESBs.
313. A synchronization mechanism transmits the relevant service definitions from the ESB Service Repository (master with the WSDL and policy description) to the ESB Service Registry.
314. The service definition for the service registry is specified in [1].
315. The security services are sub-divided into the following separate services:
316. The Authentication Service encapsulates the respective functionalities necessary to determine the identity of the entity. For those who login to an SOA associated system this means, for example, the implementation of a single sign-on concept. Therefore, the user only has to login once even if he uses different entry points for SOA services. His identity and downstream (supporting services) is provided insofar as this complies with the current process definition. Therefore, subject to the security regulations, various authentication measures may be required:
Username and Password
X.509 Certificate e.g. on a Smartcard for equipment
X.509 Certificate for Services
317. The Authentication Service verifies the log on information of the entity. With people, the test is carried out using the directory service. Should the test turn out positive, a security confirmation in accordance with the standard ‘Security Assertion Mark-up Language’ (SAML) is issued. By using this service, the identity of an entity is confirmed, possibly even beyond the borders of trustworthy organizations.
318. Furthermore, the Authentication Service verifies certain fundamental properties of the considered entity in the form of attributes. For people this is, for example, the degree of VS authority, their mili-tary rank or current position. These defined properties, together with the security regulations, are consulted when deciding to allow access to a resource.
319. The service definition for the authorization service is specified in [2], the security token service in [6].
320. As described in the previous section, the identity of an entity is generally determined by a certificate.
321. Via the Access Control Service (Authorization Service) of the SOA (ESB) Infrastructure, user authorization to resources (a resource is a service including operation) relating to identification / role is checked, permission granted to the entity and accordingly signed by the Access Control Service.
322. The service definition for the access control service is to be specified.
323. If different security domains (for example, different nations or national domains) wanted to collaborate, certain trust relationships must be defined. These include, among others, the establishment of trust connections between SOA PKIs of the organizations involved.
324. The Domain Service – a component of an SOA PKI – supports this in observing the following tasks which can also be directly taken over by the synchronization:
Registration and accreditation of a co-operating organization,
Publication of information through existing trust connections,
Transformation of security attributes between the individual information areas of the part-ner organizations.
325. The service definition for the domain controller service is specified in [7].
326. The SOA PKI is a system which provides an infrastructure for the creation and distribution of digital certificates. Furthermore, the SOA PKI maintains its own revocation list (block) for certificates (public key) and synchronizes the revocation list between security domains. In the distribution of certificates, generally only public keys are assigned.
327. Additionally, there is a requirement for the dynamic generation of key material within the interplay of SOA Services, such as the signing and encrypting of tasks with an asymmetric key pair.
328. With the help of the ‘XML Key Management Specification’ (XKMS) service, SOA PKI compliant public key applications are provided to the applications and validated.
329. The SOA PKI components are divided into two service areas:
Public Key Infrastructure (PKI)
By means of the SOA PKI, certificates are created and distributed, the certification and life-cycle management of keys carried out and the central revocation lists managed. The PKI is a hierarchical CA [4] structure and controls the trust connections between CAs.
The service definition for the SoaPki service is specified in [3], the GenKey service is specified in [5].
XML Key Management Specification (XKMS)
The XML Key Management Specification (XKMS) defines a protocol for a trust service which provides the functions of a PKI (Public Key Infrastructure). XKMS consists of the following two components:
XML Key Information Service Specification (X-KISS) defines methods to search for and validate public keys. Its goal is to minimize the complexity of the key search and validation for the users by means of the X-KISS syntax. This then provides the Access Control Service (authorization) with methods for searching and validating and forwards these to an underlying PKI.
XML Key Registration Specification (X-KRSS defines methods to register, reissue and revoke keys.
330. The SOA PKO is indeed an infrastructure component but one which is not necessarily attached to the SOA (ESB) Infrastructure. It is only contacted by the SOA (ESB) Infrastructure at specific times, such as upon initial operation or when adding users/hardware components.
331. The service definition for the XKMS service is specified in [4].