SECTION III: EMCS CENTRAL SERVICES ARCHITECTURE

Transcription

1 SECTION III: EMCS CENTRAL SERVICES ARCHITECTURE ECP1-ESS-TESS-03-SECTION-III-EMCS-CENTRAL-SERVICES-ARCHITECTURE-v3.00.doc Page 1 of 33

2 TABLE OF CONTENTS Table of Contents 1 Introduction Scope Document Structure Central Services Overview Introduction Communicating Parties SEED EMCS CS/RD CS/MIS ETA EMCS/CO Support Services NEA MSA Users Economic Operators NCTS CS/RD EUROPA/DDS Central Services Business Communication Channels [BCC] Central Services Infrastructure Communication Channels [ICC] EMCS Central Services System Architecture Central Services Architecture Introduction EMCS Central Service Bus Introduction Features CEA Integration Requirements Central Services Gateway CCN Bridge Secure Reverse Proxy (SRP) EMCS/CO Web Portal Business Process Execution Engine Flow Control Engine Central Services Back-end Applications SEED Central Services/Reference Data (CS/RD) Central Services/Management Information System (CS/MIS) Excise Test Application (ETA) EUROPA/DDS EMCS Services COTS ECP1-ESS-TESS-03-SECTION-III-EMCS-CENTRAL-SERVICES-ARCHITECTURE-v3.00.doc Page 2 of 33

3 LIST OF FIGURES List of Figures FIGURE 1: SCOPE OF EMCS CENTRAL SERVICES... 4 FIGURE 2: COMMUNICATING PARTIES... 5 FIGURE 3: CENTRAL SERVICES BUSINESS COMMUNICATION CHANNELS... 7 FIGURE 4: BUSINESS COMMUNICATION CHANNEL CEA TO EUROPA/DDS [BCC14]... 8 FIGURE 5: BUSINESS COMMUNICATION CHANNEL ECOP TO EUROPA/DDS [BCC17].. 8 FIGURE 6: CENTRAL SERVICES INFRASTRUCTURE COMMUNICATION CHANNELS... 9 FIGURE 7: EMCS CENTRAL SERVICES SYSTEM ARCHITECTURE FIGURE 8: CENTRAL SERVICES ARCHITECTURE OVERVIEW FIGURE 9: CENTRAL SERVICES COMPONENTS INTEGRATION FIGURE 10: EMCS CENTRAL SERVICE BUS FIGURE 11: CENTRAL SERVICES GATEWAY FIGURE 12: CENTRAL SERVICES GATEWAY SYSTEM ARCHITECTURE FIGURE 13: CCN BRIDGE FIGURE 14: SECURE REVERSE PROXY (SRP) FIGURE 15: CENTRAL SERVICES PORTAL FIGURE 16: BUSINESS PROCESS EXECUTION ENGINE FIGURE 17: FLOW CONTROL ENGINE FIGURE 18: CENTRAL SERVICES BACK-END APPLICATIONS FIGURE 19: EXCISE TEST APPLICATION (ETA) FIGURE 20: CS/ETA COMMUNICATION CHANNELS ECP1-ESS-TESS-03-SECTION-III-EMCS-CENTRAL-SERVICES-ARCHITECTURE-v3.00.doc Page 3 of 33

4 1 Introduction 1.1 Scope TESS Section III specifies the IT architecture of the EMCS Central Services (see Figure 1), as a part of the overall specification activities of the project. The IT architecture establishes the core architectural principles and design choices, and identifies the main subsystems that together form the EMCS Central Services. 1.2 Document Structure This document is structured as follows: Figure 1: Scope of EMCS Central Services Chapter 1... Introduction provides a description of the scope and structure of this Section. Chapter 2... Central Services Overview provides a summary of the offered services, the description of the involved communicating parties, and the description of the communication channels established between these parties to access the services offered by the Central Excise Applications (CEA). Chapter 3... Central Services Architecture provides a description of the various components (i.e. EMCS Central Service Bus, Central Services Gateway, EMCS/CO Web Portal, Business Process Execution Engine, Flow Control Engine, Central Services Back-end Applications, and EUROPA/DDS EMCS Services) that together form the Central Services Architecture. ECP1-ESS-TESS-03-SECTION-III-EMCS-CENTRAL-SERVICES-ARCHITECTURE-v3.00.doc Page 4 of 33

5 2 Central Services Overview 2.1 Introduction The Central Excise Applications (CEA) provide application services, that are made centrally available (i.e. in the Common Domain) to MSA and Economic Operators. At MSA level, the interactions with the CEA are achieved through the CCN Network. At Economic Operators level, the interactions with the CEA are achieved through EUROPA via Internet. 2.2 Communicating Parties Figure 2 identifies all parties that make use of the EMCS Central Services. These parties may be either located in the National Domain, the External Domain or the Common Domain SEED Figure 2: Communicating Parties The System for Exchange of Excise Data (SEED) is located in the Common Domain. It provides management and dissemination services regarding information on the Economic Operators register. This is a vital part of the EMCS Central Services because the core business processes of EMCS depend on it EMCS CS/RD The EMCS Central Services/Reference Data (CS/RD) is located in the Common Domain. It provides management and dissemination services regarding common Reference Data CS/MIS The Central Services/Management Information System (CS/MIS) is located in the Common ECP1-ESS-TESS-03-SECTION-III-EMCS-CENTRAL-SERVICES-ARCHITECTURE-v3.00.doc Page 5 of 33

6 Domain. It provides the facilities to assist the monitoring and the reporting on the operations of EMCS. This is performed by collecting, distributing and publishing EMCS business and technical statistics (including availability statistics) and by providing information on movements (ARC follow-up) ETA The Excise Test Application (ETA) is located in the Common Domain. It is used for mode-2 testing (see ACS [R5] NEA testing modes) against the NEA located in the premises of the MSA EMCS/CO Support Services The Central Operation (EMCS/CO) services are the services proposed by the Excise Computerization Project (ECP) to provide the Member State Administrations (MSA) with operational and technical support during EMCS implementation and operation. The role of the EMCS/CO consists also of the management of the applications providing the central services. The Central Operation Specifications (COS [R6]) describe the organisation and activities of the Central Operation Services NEA The National Excise Application (NEA) encompasses the systems that are located in the National Domain. It regularly maintains a relation with the Central Services in order to provide data generated at the National Administration level or to obtain data managed centrally MSA Users MSA Users (including Excise Liaison Officers (ELO), Excise officers, Excise verification officers, Control officers and Customs officers) use workstations located in the National Domain. They make use of the Central Services through the Common Domain communication infrastructure Economic Operators Economic Operators use workstations located in the External Domain. They make use of the Central Services through EUROPA (see EUROPA/DDS) in order to obtain limited access to excise information relating to other operators NCTS CS/RD The NCTS CS/RD application offers the functionality of managing customs offices (maintenance, download, updates, etc.) and NCTS reference data. To support the EMCS CS/RD, the NCTS CS/RD application has to manage a common list of offices (custom and excise). Excise Offices are specified by defining an additional excise role. MSAs interact directly with NCTS CS/RD for all operations relating to creation, modification and deletion of offices. This is done independently from, and without impact or any interaction with the EMCS CS/RD application EUROPA/DDS EUROPA is the official web site for the European Union and hosts a diverse set of publications and services, intended for public users. EUROPA is used to offer a limited set of EMCS Central Services: ECP1-ESS-TESS-03-SECTION-III-EMCS-CENTRAL-SERVICES-ARCHITECTURE-v3.00.doc Page 6 of 33

7 The validation of excise authorisations provided by SEED. Consultation and download of the Customs Offices List (COL) provided by NCTS CS/RD and including Excise Offices List (EOL). ARC Follow-up provided by CS/MIS. Download of E-Form Templates (see TESS Section IV Chapter 4 EMCS Start-up Kit). The EUROPA channel is made available to all public users. EUROPA does not require users to be authenticated. Confidential information will not be offered by EUROPA. Note: EUROPA, the European Commission web portal is accessible at Central Services Business Communication Channels [BCC] Figure 3 describes the EMCS Business Communication Channels (BCC) established between the various communicating parties. Only Business Communication Channels involved by the Central Services are considered hereafter. Figure 3: Central Services Business Communication Channels Those Business Communication Channels can be considered differently according to the involved domain: Common Domain. [BCC14] CEA to EUROPA/DDS ECP1-ESS-TESS-03-SECTION-III-EMCS-CENTRAL-SERVICES-ARCHITECTURE-v3.00.doc Page 7 of 33

8 Figure 4: Business Communication Channel CEA to EUROPA/DDS [BCC14] This channel supports the information exchanges between CEA and EUROPA/DDS in order to provide a diverse set of publications and services, intended for public users. National Domain. NEA and MSA users use the communication channels provided by the EMCS Common Domain Architecture (see TESS Section II EMCS Common Domain Architecture), including: [BCC6]... NEA to SEED. [BCC7]... SEED to NEA. [BCC8]... MSA Users to EMCS/CO Support Services. [BCC9]... MSA Users to SEED. [BCC10]... EMCS CS/RD to NEA. [BCC11]... MSA Users to CS/RD. [BCC12]... NEA to CS/RD EMCS. [BCC13]... EMCS/CO Support Services to MSA Users. [BCC19]... NEA to CS/MIS. [BCC20]... CS/MIS to NEA. [BCC23]... MSA Users to CS/MIS. External Domain. [BCC17] Economic Operator to EUROPA/DDS Figure 5: Business Communication Channel EcOp to EUROPA/DDS [BCC17] This channel provides interactive exchanges between users in the External Domain (Economic Operators) and EUROPA. It requires high performance of response time since it tightly links user s interfaces and interactive applications. It addresses the use case UC1.30 (Consultation of registration information by economic operators). ECP1-ESS-TESS-03-SECTION-III-EMCS-CENTRAL-SERVICES-ARCHITECTURE-v3.00.doc Page 8 of 33

9 2.4 Central Services Infrastructure Communication Channels [ICC] Figure 6 shows the Infrastructure Communication Channels [ICC], which are used to establish the business relationship between communicating parties consuming Central Services. Only Infrastructure Communication Channels interfacing with the Central Services are considered hereafter. Figure 6: Central Services Infrastructure Communication Channels ECP1-ESS-TESS-03-SECTION-III-EMCS-CENTRAL-SERVICES-ARCHITECTURE-v3.00.doc Page 9 of 33

10 Infrastructure Communication Channels relaying on the Common Domain Infrastructure are depicted in TESS Section II and categorised as following: CCN/CSI Services.... [ICC1], [ICC4], [ICC5], [ICC15] and [ICC16]. Web Services and Web Interface.... [ICC2], [ICC6], [ICC11] and [ICC17]. -based Interface.... [ICC3], [ICC7], [ICC8], [ICC18] and [ICC19]. Additional Infrastructure Communication Channels are required to communicate with other parties: NCTS CS/RD using CCN/CSI Services... [ICC21] and [ICC22]. EUROPA/DDS using CCN/CSI Services... [ICC20]. EMCS/CO Workstations using Web Interface... [ICC14]. Economic Operator using EUROPA through the Internet.... [ICC26]. The various ICC are combined according to the addressed Central Services (see TESS Section II 6.3 EMCS Services Interfacing). Consequently, not all ICC need to be always implemented for each BCC. 2.5 EMCS Central Services System Architecture Figure 7 presents an overview of the system architecture showing the operational environment of the EMCS Central Services architecture. Communicating Parties (see 2.2 Communicating Parties) are mapped to hardware and software resources supporting the operation of the EMCS. In this section, particular attention is given to the environment and the architectural components in terms of the location, placing of applications and physical communication links providing accesses to the Central Excise Applications and Services. The main components addressed by the EMCS Central Services System Architecture and identified in Figure 7 are the following: The EMCS Central Services communicating parties, including: SEED (see SEED) providing facilities for managing, storing, notifying, disseminating and consulting information on the Economic Operators register. EMCS CS/RD (see Central Services/Reference Data (CS/RD)) providing management and dissemination services regarding common Reference Data. EMCS CS/MIS (see Central Services/Management Information System (CS/MIS)) providing the facilities to assist the monitoring and the reporting on the operations of EMCS. ETA (see Excise Test Application (ETA)) used for mode-2 testing (see ACS [R5] NEA testing modes) against the NEA located in the premises of the MSA. Bridge CA/VA (see TESS Section II Bridge CA/VA), a key component of the EMCS Common Domain PKI (CDPKI). EMCS/CO Web Portal (see 3.4 EMCS/CO Web Portal) providing the single and unified interface offering to users (including EMCS/CO Workstations) a secure access to various central sources of information and applications. ECP1-ESS-TESS-03-SECTION-III-EMCS-CENTRAL-SERVICES-ARCHITECTURE-v3.00.doc Page 10 of 33

11 EUROPA and DDS (see 3.8 EUROPA/DDS EMCS Services), hosting a diverse set of publications and services, intended for public users and protected by a Firewall and Reverse Proxy. NCTS CS/RD, The Central Services Gateway (see 3.3 Central Services Gateway) is the single point of contact of the EMCS Central Services infrastructure. It encompasses: CCN Bridge (see CCN Bridge) in charge of the asynchronous traffic regulation. Secure Reverse Proxy (SRP) (see Secure Reverse Proxy (SRP)) in charge of the HTTP traffic regulation. EC Mail Transfer Agent (MTA) that routes the traffic to Internet or the LCMS. The Central Services Gateway regulates the messages exchanged with the Common Domain Infrastructure including: CCN Gateway offering both CCN/CSI Services (see TESS Section II 3.3 CCN/CSI Services) and CCN Intranet Services (see TESS Section II 3.4 CCN Intranet Services). Local CCN Mail System (LCMS) offering CCN Mail 2 services (see TESS Section II 3.5 CCN Mail 2 Services). The National Domain communicating parties (see TESS Section IV Standard Excise Application Architecture) including: National Excise Application (NEA), providing the EMCS services at the national level. It communicates with other NEA and the Central Services using the services offered by the NDCP. Excise Office and ELO Workstations, offering user interfaces for the interactions with the NEA, through the National Network, and the Central Services, through the NDCP. National Mail Transfer Agent (MTA) that routes the traffic to the LCMS. Those elements communicate through the Common Domain infrastructure using the NDCP (see TESS Section II National Domain Connection Point (NDCP)) including the national CCN Gateway, the Local CCN Mail System (LCMS), the Security Devices, such as a firewall (F/W) and encryption device, and the Customer Premises Router (CPR), establishing the TCP/IP link to the CCN backbone. The External Domain communicating parties (see TESS Section IV Standard Excise Application Architecture) including: Economic Operator Workstation addressing the NEA as well as EUROPA through the Internet. Certification Authority (CA) and Principal CA participating to the PKI (see TESS Section II Certificate Management). ECP1-ESS-TESS-03-SECTION-III-EMCS-CENTRAL-SERVICES-ARCHITECTURE-v3.00.doc Page 11 of 33

12 Figure 7: EMCS Central Services System Architecture ECP1-ESS-TESS-03-SECTION-III-EMCS-CENTRAL-SERVICES-ARCHITECTURE-v3.00.doc Page 12 of 33

13 3 Central Services Architecture 3.1 Introduction Figure 8 illustrates the Central Services Architecture. All those services are hosted in the Common Domain by the EC Data Centre, which provides a single access point through the Central Services Gateway (see 3.3 Central Services Gateway) regulating all communications between communicating parties (see 2.2 Communicating Parties) using the available infrastructure communication channels (see 2.4 Central Services Infrastructure Communication Channels [ICC]). ECP1-ESS-TESS-03-SECTION-III-EMCS-CENTRAL-SERVICES-ARCHITECTURE-v3.00.doc Page 13 of 33

14 3.2 EMCS Central Service Bus Introduction Figure 8: Central Services Architecture Overview The exchanges with external communicating parties are managed by the Central Services Gateway (see 3.3 Central Services Gateway). However the Central Services Gateway is not built to "directly" interact with all internal Central Services components. Therefore there is a need for an intermediate component, the EMCS Central Service Bus, that would allow integrating the Central Services Gateway and the internal Central Services components in a reliable, managed and scalable way. ECP1-ESS-TESS-03-SECTION-III-EMCS-CENTRAL-SERVICES-ARCHITECTURE-v3.00.doc Page 14 of 33

15 Figure 9: Central Services Components Integration This is the goal of the EMCS Central Service Bus, which provides features (see Features) that are used to ease the development and the deployment of EMCS central services. Part of processing (such as message validation, security, message transformation, intelligent messaging brokering, etc) is deported from applications to these services. This will ease the development of new applications (or Services) that will reuse generic services offered by the Service Bus through its valued-added services Features The Service Bus is a middleware solution that implements the backbone of a loosely coupled, event-driven SOA. Figure 10: EMCS Central Service Bus In this context, service components expose well-defined, atomic and message driven interfaces for sharing data between applications, in a highly distributed environment. Those data are exchanged through synchronous (request/reply) and asynchronous (send/receive) communication channels over standard communication protocols (e.g. SOAP, HTTP, HTTPS, JMS, SMTP, POP3, IMAP4 and FTP). The messaging backbone the bus is capable of scaling up to handle a very large number of applications and services and a very high volume of message traffic. The backbone is ECP1-ESS-TESS-03-SECTION-III-EMCS-CENTRAL-SERVICES-ARCHITECTURE-v3.00.doc Page 15 of 33

16 compliant with the Java Message Service (JMS) specification and based on Message-Oriented Middleware (MOM). Such middleware is able to process synchronous, asynchronous as well as publish/subscribe communication patterns. Therefore, the scalability is easy to achieve because this distributed infrastructure is loosely coupled, hardware- and OS-independent. The Service Bus is designed (see 3.9 COTS) to connect and streamline applications, data and business systems across the network within a loosely coupled architecture. For that purpose, the Service Bus supports the development of composite applications that may involve new code built on top of existing applications such as legacy applications (e.g. NCTS CS/RD, SEED v0, etc.). In addition to the business services provided by the back-end applications (see 3.7 Central Services Back-end Applications), the service bus will integrate the following architectural components: EMCS/CO Web Portal (see 3.4 EMCS/CO Web Portal) that integrates the user interface and exposes services through a single point of access. Flow Control Engine (see 3.6 Flow Control Engine) that mainly manages the Coordination Protocol (see TESS Section II) with communicating parties (i.e. NEA) including preventive message queuing, sequencing and acknowledgment. It implements also other detection and prevention measures such as message validation at syntactic level and exception handling. Moreover, security requirements including confidentiality and integrity are also implemented at this level. Business Process Execution Engine (see 3.5 Business Process Execution Engine) that provides the Business Process Orchestration of the business process sequences, which is required to perform the exchange of messages with communicating parties. Moreover, the Service Bus presents the following characteristics: Security: The Security Server provides mechanisms to secure data exchange between consumers and producers of services such as: authorisation, authentication, and data encryption. Transformation: This service is embedded within the Service Bus to achieve message transformation. Its goal is to convert the message to one expected by the target system. This operation is not only linked to XML transformation (i.e. through XSLT) but also to other format (e.g. EDIFACT). Routing: This service determines the network destination of messages by converting logical destination to the specific Uniform Resource Identifier (URI). Directory Services: The directory serves as storage for service definitions accessible via UDDI, users data accessible via LDAP, schema, etc. Service Management: In addition to the Security Server, the Service Management s function is used to remotely monitor, configure and control the network activity of the Service Bus (e.g. security threat, availability of services, loading indication, auditing, etc). To achieve that, it supports instrumentation agents such as JMX, and provides logging, auditing and statistics capabilities CEA Integration Requirements In a Service-Oriented Architecture, the cornerstone is the standardisation of the interfaces in order to publish services in an unambiguous, common and predictable way. Therefore, the ECP1-ESS-TESS-03-SECTION-III-EMCS-CENTRAL-SERVICES-ARCHITECTURE-v3.00.doc Page 16 of 33

17 EMCS Central Service Architecture proposes the following standards: Web Services. Web Services are defined using WSDL. WSDL is an XML format for the description of network services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information. WSDL is extensible to allow description of endpoints and their messages regardless of what message formats or network protocols are used to communicate. JMS. The Java Message Service (JMS) provides a standard Java-based interface to the message services of a MOM (Message Oriented Middleware). With JMS, both Publish- Subscribe Messaging and Point-To-Point are supported as well as Request-Reply Messaging. JMS defines the concept of a Topic or a Queue as the target for a Message. Topics are used for Publish-Subscribe Messaging. Queues are used for Point-to-Point Messaging. JMS provides also support for distributed transactions between Central Services components. Each Central Excise Application must expose its services through those standards, either directly or using adapters wrapping the internal service interface. ECP1-ESS-TESS-03-SECTION-III-EMCS-CENTRAL-SERVICES-ARCHITECTURE-v3.00.doc Page 17 of 33

18 3.3 Central Services Gateway The Central Services Gateway is the single point of contact of the EMCS Central Services infrastructure. It is in charge of transforming the invocation protocols to the internal ones. This transformation is achieved through the services provided by: The CCN Bridge (see CCN Bridge), which manages the asynchronous exchanges with Common Domain Relay (i.e. CSI, SMTP and POP3). The Secure Reverse Proxy (see Secure Reverse Proxy (SRP)), which manages HTTP/S exchanges with the Common Domain Relay. Figure 11: Central Services Gateway Figure 12 depicts an overview of the system architecture that supports the Central Services Gateways. This shows how the components are mapped to hardware and software resources. Figure 12: Central Services Gateway System Architecture CCN Bridge The CCN Bridge is a component of the Central Services Gateway in charge of the ECP1-ESS-TESS-03-SECTION-III-EMCS-CENTRAL-SERVICES-ARCHITECTURE-v3.00.doc Page 18 of 33

19 asynchronous traffic regulation. It provides standard and homogeneous interface for the backend services, in particular the Flow Control Engine (see 3.6 Flow Control Engine), namely JMS (see CEA Integration Requirements). Figure 13: CCN Bridge Typically, the asynchronous paradigm of CCN is accessible using the CSI Client Stack (see TESS Section II 2.5 CCN/CSI Services) that must be installed on the Application Platform. It offers high Quality of Service but unfortunately it has also the following disadvantages: It requires proprietary client stack supported on a limited set of platforms. It provides an interface (CSI) that is not standard (i.e. requiring developer s specific skills) and that does not allow a standard integration of the Common Domain infrastructure. It does not support transaction management (XA) that is generally useful on the application side to make CCN resources (i.e. CCN queues) participating in a transaction together with other resources (e.g. RDMBS). Even if CSI is considered as a de facto standard in the Common Domain, it is not an industry standard and it cannot be seen as such regarding applications integration. The Central Services Architecture is centred on the EMCS Central Service Bus (see 3.2 EMCS Central Service Bus). The bus provides message delivery services, based on standards (including JMS). Therefore, the interface for the CCN asynchronous paradigm should be JMS that provides a standard client API delimiting distributed transactions and offering the ability of a resource to participate in a distributed transaction. The CCN Bridge provides protocol transformations between CSI, used to communicate with external communicating parties (e.g. NEAs, NCTS CS/RD, DDS, etc.), and JMS, used to interact with the Central Services components. Moreover, CCN Mail 2 (see TESS Section II 3.5 CCN Mail 2 Services) is used for human-tomachine interactions or machine-to-machine interactions, typically as fallback solutions in the case where CCN/CSI (the recommended channel) is not available. In order to preserve the Central Services from this issue, the CCN Bridge provides protocol transformations between LCMS (SMTP, POP3 and IMAP4), part of the Common Domain Relay, and JMS, the standard Message Service used in the Central Services Architecture. Note: The COTS proposed for the Central Service Bus (see 3.9 COTS) supports the routing of -based exchanges (POP/SMTP/IMAP). Therefore, the CCN Bridge should only regulate the CSI-based exchanges. ECP1-ESS-TESS-03-SECTION-III-EMCS-CENTRAL-SERVICES-ARCHITECTURE-v3.00.doc Page 19 of 33

20 3.3.2 Secure Reverse Proxy (SRP) The Secure Reverse Proxy (SRP) is a component of the Central Services Gateway in charge of the HTTP traffic regulation. It provides the following features: Reverse Proxying The SRP proxies on behalf of the back-end HTTP server and not on behalf of the outside client s request (as a proxy would), hence the term reverse. It is an application proxy for servers using the HTTP protocol. It acts as a gateway to an HTTP server or HTTP server farm by acting as the final IP address for requests from the outside. A firewall should work tightly with the SRP to protect it from unwanted access from the external world and to ensure that only the SRP can access the HTTP servers located behind it. From the outside client s point of view, the SRP is the actual and only HTTP server. Instead of multiple machines directly handling the requests from clients, a single machine is responsible for accepting and redirecting the requests to the real servers. This means that a single domain continues to appear as a single machine, while still having the flexibility of multiple machines working behind the scenes to honour the actual requests. Security As security device, the SRP implements the authentication, authorisation and accounting measures necessary to fulfil the EMCS security requirements at the Central Services level regarding web-based interoperability. Figure 14: Secure Reverse Proxy (SRP) Consequently, it discharges the rest of the infrastructure from an important part of the security aspects establishing a so-called Implicit Trusted Zone. In this zone, the various services, in particular the EMCS/CO Web Portal (see 3.4 EMCS/CO Web Portal), can proceed securely by only dealing with functional requirements, keeping to the SRP the responsibility of the security. This solution provides an easy way to change or adapt the authentication mechanism (e.g. using X509-Certificate rather than login/password) without impacting the back-end services. Moreover, it hides eventually heterogeneous authentication mechanisms, possible mix of security measures according to the trust level of the partner s origin (e.g. Common Domain or Internet). ECP1-ESS-TESS-03-SECTION-III-EMCS-CENTRAL-SERVICES-ARCHITECTURE-v3.00.doc Page 20 of 33

21 However, in order to be able to fulfil requested services, back-end applications need often to identify the requesting party. Therefore, the SRP inserts the identity deduced from the authentication mechanism (e.g. using cookie) in the request before forwarding it to the back-end server. Load Balancing In addition to the above considerations, the SRP can distribute the load to several servers, each server serving its own application area. Caching The reverse proxy can offload the back-end web servers by caching static content, such as images. Proxy caching of this sort can often satisfy a considerable amount of website requests, greatly reducing the load on the central web server. However, the implementation of the caching mechanism must not affect the security of the system. Note: The sequence of exchanges between the SRP and the HTTP Proxy (specifically with regards to the authentication phase) is described in the SESS [R9]. ECP1-ESS-TESS-03-SECTION-III-EMCS-CENTRAL-SERVICES-ARCHITECTURE-v3.00.doc Page 21 of 33