atexo
publicité
Dossier d'Architecture Technique Version 1.4 ATEXO – V-PARIS – EPM - DAT001 Ville de Paris EPM Dossier d'Architecture Technique ATEXO, tous droits réservés Page 1 sur 27 Dossier d'Architecture Technique Version 1.4 ATEXO – V-PARIS – EPM - DAT001 IDENTITE DU DOCUMENT Client Ville de Paris Affaire EPM Titre Dossier d'Architecture Technique Référence ATEXO – V-PARIS – EPM - DAT001 Etat Final Version 1.4 Du 12/11/2015 Dernière page 26 EVOLUTION DU DOCUMENT Date Version Rédacteur Commentaires 17/12/2013 1.0 Exploitation ATEXO Initialisation du document 23/05/2014 1.1 Exploitation ATEXO Mise à jour 12/02/2015 1.3 Exploitation ATEXO Mise à jour – nouveaux flux pour lien avec Maximilien 12/11/2015 1.4 Exploitation ATEXO Mise à jour – précisions sur les flux des échanges APPROBATION DE LA VERSION Entreprise ou Service Nom Visa V-PARIS ATEXO Equipe produit DIFFUSION DE LA VERSION Entreprise ou Service Destinataires Fonction Pour action Pour info V-PARIS ATEXO ATEXO, tous droits réservés Equipe produit X Page 2 sur 27 Dossier d'Architecture Technique Version 1.4 ATEXO – V-PARIS – EPM - DAT001 Table des matières 1 INTRODUCTION ................................................................................................. 5 1.1 2 ANALYSE DES BESOINS .................................................................................. 6 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 3 4.6.1 4.6.2 4.6.3 INTRODUCTION ............................................................................................. 11 CYCLE DE DÉVELOPPEMENT........................................................................... 11 OUTILS ET MÉTHODES DE CONSTRUCTION ET DE L’APPLICATION ........................ 11 DESCRIPTION DES ENVIRONNEMENTS ............................................................. 11 RESPONSABILITÉS ET GESTION DES ENVIRONNEMENTS .................................... 12 DESCRIPTION DES TRANSPORTS / CIRCUIT DE LIVRAISON .................................. 12 Composants applicatifs ............................................................................................... 12 Configuration ............................................................................................................... 12 Paramétrage métier ..................................................................................................... 12 ARCHITECTURE LOGICIELLE ........................................................................ 13 5.1 5.2 5.3 5.4 5.4.1 5.4.2 5.4.3 5.4.4 6 PRÉ-REQUIS MATÉRIELS ET LOGICIELS DU POSTE DE TRAVAIL ............................. 9 DESCRIPTION LOGICIELLE DU POSTE DE TRAVAIL ............................................... 9 USAGE DES POSTES DE TRAVAIL....................................................................... 9 PAYSAGE APPLICATIF ................................................................................... 11 4.1 4.2 4.3 4.4 4.5 4.6 5 TYPOLOGIE DES UTILISATEURS ......................................................................... 6 BESOINS EN ACCÈS ......................................................................................... 6 BESOINS EN PERFORMANCES ........................................................................... 6 PLAGE D'OUVERTURE DU SERVICE .................................................................... 6 PROGRAMMATION DES INDISPONIBILITÉS ........................................................... 7 PROTECTION DES DONNÉES ............................................................................. 7 BESOINS EN TERMES DE SÉCURITÉ ................................................................... 7 CONTRAINTES D’EXPLOITATION ........................................................................ 8 EXIGENCES DU POSTE DE TRAVAIL .............................................................. 9 3.1 3.2 3.3 4 OBJECTIFS DU DOCUMENT ............................................................................... 5 PRÉSENTATION ............................................................................................. 13 VUE DES FLUX PHYSIQUES ............................................................................. 14 FLUX RÉSEAU ............................................................................................... 14 LISTE, VERSIONS ET CARACTÉRISTIQUES DES COMPOSANTS LOGICIELS ............. 15 Système d’exploitation ................................................................................................ 15 Serveur Web................................................................................................................ 15 Serveur de base de données ...................................................................................... 15 Serveur d’application et composants associés ........................................................... 15 ARCHITECTURE PHYSIQUE ........................................................................... 17 6.1 6.2 6.3 6.3.1 6.3.2 6.3.3 HÉBERGEMENT ............................................................................................. 17 RÉPARTITION DES FONCTIONS LOGIQUES SUR LES SERVEURS ........................... 17 ARCHITECTURE PHYSIQUE DE PRODUCTION ..................................................... 17 Schéma ....................................................................................................................... 17 Accès ........................................................................................................................... 18 Applications externes .................................................................................................. 18 ATEXO, tous droits réservés Page 3 sur 27 Dossier d'Architecture Technique Version 1.4 ATEXO – V-PARIS – EPM - DAT001 6.4 6.5 6.5.1 6.5.2 7 ARCHITECTURE PHYSIQUE DE RECETTE .......................................................... 18 DIMENSIONNEMENT MATÉRIEL ........................................................................ 18 Dimensionnement recommandée par ATEXO ............................................................ 18 Volumétrie de stockage ............................................................................................... 18 INTERFACES AVEC LES SYSTÈMES EXTERNES ........................................ 20 7.1 ECHANGES AVEC LA SOLUTION LOCAL TRUST MPE ..................................... 20 Nommage des fichiers : ................................................................................................................ 21 7.2 ECHANGES AVEC LA PLATE-FORME MAXIMILIEN ............................................... 22 7.3 ECHANGES AVEC LES SERVICES CENTRALISÉS FOURNIS PAR ATEXO .................. 23 7.3.1 Messagerie sécurisée ................................................................................................. 24 7.3.2 Concentrateur d’annonces .......................................................................................... 24 7.4 ECHANGES AVEC LES INTERFACES FINANCIÈRES DE LA VILLE DE PARIS ............. 24 8 PRINCIPES DE SÉCURITÉ .............................................................................. 25 8.1 8.2 9 PLATES-FORMES SERVEURS .......................................................................... 25 POSTES V-PARIS ........................................................................................ 25 ANNEXE 1 : DESCRIPTION DES ÉCHANGES WSSO ................................... 26 ATEXO, tous droits réservés Page 4 sur 27 Dossier d'Architecture Technique Version 1.4 ATEXO – V-PARIS – EPM - DAT001 1 INTRODUCTION 1.1 Objectifs du document Ce document est le dossier d'architecture technique de la solution EPM mise en œuvre pour la V-PARIS. Il présente dans un premier temps l'analyse des besoins exprimés par la V- PARIS puis les architectures applicatives et logicielles. Dans un second temps, il décrit l’architecture physique recommandée pour chaque environnement ainsi que le dimensionnement matériel respectif. Enfin, il précise les modalités d'exploitabilité de la solution. ATEXO, tous droits réservés Page 5 sur 27 Dossier d'Architecture Technique Version 1.4 ATEXO – V-PARIS – EPM - DAT001 2 ANALYSE DES BESOINS 2.1 Typologie des utilisateurs Les différents types d’utilisateurs accédant à la solution sont : Les agents de la V- PARIS (mode accès INTRANET) Utilisateur Type d’accès/action Utilisateurs internes V-PARIS Zone contrôlée de l’application / accès à Applicatif l’application en fonction de l’identité et du rôle attribué à l’identité 2.2 Vérification l’identité de Besoins en accès La solution fonctionne en client léger (navigateurs Web) et est accessible uniquement depuis l'Intranet. Aucun utilisateur n’aura accès à la solution EPM sans être préalablement enregistré et authentifié. 2.3 Besoins en performances La solution devra garantir une ergonomie d’utilisation compatible avec la bonne pratique et les standards industriels des applications web. 2.4 Plage d'ouverture du service La solution est accessible pendant les heures ouvrées de bureau entre 06h et 21h30. Le tableau suivant précise les plages d'ouvertures du service et le support associé: Plage Période Contrainte Plage d'ouverture du 6h00 – 9h00 les jours ouvrés hors Pas de support service indisponibilité programmée pour opération de maintenance Plage d'ouverture du 9h00 – 18h00 les jours ouvrés Accès à l’application service hors indisponibilité programmée en mode nominal. pour opération de maintenance Accès au support pour rétablissement de l’application en cas de dysfonctionnement ATEXO, tous droits réservés Page 6 sur 27 Dossier d'Architecture Technique Version 1.4 ATEXO – V-PARIS – EPM - DAT001 Plage Période Contrainte Plage d'ouverture du 18h00 – 21h30 les jours ouvrés Pas de support service hors indisponibilité programmée pour opération de maintenance Plage de fermeture 2.5 Complément à 24h 7 jours sur 7 Aucune garantie de la plage précédente d’accès à l’application Programmation des indisponibilités Les arrêts de l’application pendant la plage d’ouverture seront planifiés d’un commun accord entre la V-PARIS et ATEXO. 2.6 Protection des données En cas de dysfonctionnement majeur impliquant une perte de la cohérence des données applicatives, les dispositifs de sauvegarde mis en place permette de restaurer l’état de l’application et ses données à J-1. 2.7 Besoins en termes de sécurité La sécurité de la plate-forme EPM est assurée par les services d’identification, de contrôle d’accès et d’habilitations. L’accès à l’ensemble des interfaces Web de la plateforme est restreint par la mise en place d’un système d’authentification des utilisateurs basé sur un contrôle de login/mot de passe. Les choix d’architecture et des composants participent à la sécurité de l’application au travers des points suivants : Niveau application : o Utilisation de frameworks connus et maintenus o Pas de parsing «maison» des données fournies par l'utilisateur o Gestion stricte des droits d'accès par utilisateur dans l'application o Stockage des fichiers envoyés hors arborescence applicative o Pas d'accès SQL à la base par l'application – utilisation exclusive d'objets mappés par Hibernate Niveau Infrastructure : o Rupture protocolaire http(s) AJP sur le frontal web o Limitation de la taille des entêtes intrinsèque au protocole AJP ATEXO, tous droits réservés Page 7 sur 27 Dossier d'Architecture Technique Version 1.4 ATEXO – V-PARIS – EPM - DAT001 Contraintes d’exploitation 2.8 Des contraintes d’exploitations spécifiques à la solution sont identifiées: L’ordre d’arrêt et de démarrage des serveurs obéit à des contraintes précises Les changements de paramétrage techniques nécessitent le redémarrage de l’application Leurs modalités pratiques seront précisées dans le Dossier d’Exploitation. ATEXO, tous droits réservés Page 8 sur 27 Dossier d'Architecture Technique Version 1.4 ATEXO – V-PARIS – EPM - DAT001 3 EXIGENCES DU POSTE DE TRAVAIL 3.1 Pré-requis matériels et logiciels du poste de travail L’application est accessible via une URL de connexion qui pointe ensuite vers des URL de navigation. Cette URL est gérée par le DNS de la V-PARIS. Les URL définies par la V-PARIS sont les suivantes : Environnement URL Recette Pré-production (utilisé pour l’infocentre) Formation Production L’application fonctionne sur un poste de travail équipée d’un navigateur IE à partir de la version 7 ou Firefox à partir de la version 3. Le poste de travail doit avoir java version 7 minimum d’installé. Son bon fonctionnement implique d’autoriser les cookies, l’exécution du Javascript, l’exécution des applets Java, l’ouverture de fenêtres pop-up sur une URL de l’application. La visualisation des documents PDF nécessite la présence d’un viewer de PDF, Acrobat Reader ou équivalent. L’intégration du viewer PDF dans le navigateur Internet est préférable, pour simplifier la lecture des documents PDF. Si l’utilisateur a besoin d’imprimer les documents produits par l’application, l’accès à une ressource d’impression locale au poste de travail est nécessaire. 3.2 Description logicielle du poste de travail Aucun logiciel spécifique n’est nécessaire pour accéder à l’application. L’ensemble des contenus et programmes (javascript, applets) de l’application est téléchargé via les mécanismes standards de navigation Web. 3.3 Usage des postes de travail Les postes de travail sont utilisés pour : Naviguer sur l’application en HTTPS Manipuler des objets Web à travers le navigateur, Javascript, applets Java, images, documents PDF, formulaires html Enregistrer, à la demande de l’utilisateur et via les mécanismes du système d’exploitation qui s’interfacent en standard avec les navigateurs, des ATEXO, tous droits réservés Page 9 sur 27 Dossier d'Architecture Technique Version 1.4 ATEXO – V-PARIS – EPM - DAT001 documents bureautiques (PDF, formats compatibles office (.doc, .rtf, csv, xls, ppt, images Jpeg, tiff, ou gif, etc)) sur son poste de travail Manipuler ces mêmes documents, ouvrir, modifier, imprimer, les télécharger ou les déposer sur le serveur ATEXO, tous droits réservés Page 10 sur 27 Dossier d'Architecture Technique Version 1.4 ATEXO – V-PARIS – EPM - DAT001 4 PAYSAGE APPLICATIF 4.1 Introduction Ce chapitre présente le paysage applicatif de développement, intégration, déploiement, qualification et mise en production. 4.2 Cycle de développement Les développements sont réalisés par les développeurs sur leur poste de travail où ils disposent d’instances locales des composants logiciels. Après passage des tests unitaires individuels, les développements sont ensuite livrés via subversion pour la construction globale de l’application et l’intégration continue des développements sur la plate-forme d’intégration continue. Des tests unitaires d’intégration sont alors réalisés à chaque nouvelle construction de l’application via le logiciel Sélénium. Les résultats de ces tests seront livrés avec la version d’epm. Chaque version stable issue du processus de développement est ensuite livrée sur plate-forme de tests Usine pour l’exécution des tests Usine. Lorsque les tests Usine sont concluants, une version est gelée et livrée à la V-PARIS pour passage en environnement de recette puis de production. Chaque passage d’un environnement à un autre donnera lieu à un GO/NoGO de la V-PARIS. En cas de NoGo, les anomalies constatées conjointement par la V-PARIS et ATEXO donneront lieu à un correctif et une nouvelle livraison via une version supérieure. Celle-ci intégrera les évolutions de la version initiale afin de se limiter à une seule livraison. 4.3 Outils et méthodes de construction et de l’application L’outil MAVEN est utilisé pour générer les builds applicatifs à partir de la gestion de version assurée par Subversion. Les builds sont réalisés sur la plate-forme d’intégration continue ATEXO. Ils sont conçus de manière à séparer les fichiers de configuration de l’arborescence du code. Chaque build livré à la V-PARIS est associé à un numéro de version principal. Ce numéro de version est propagé dans l’ensemble des manifestes des composants livrés. La livraison comporte la documentation d’installation, les sources ainsi que les sources compilées de l’application ainsi que les éventuels scripts de mises à jour de la base de données et fichiers de configurations externes. 4.4 Description des environnements Les environnements de développement, d’intégration continue et de tests Usine sont sous l’entière responsabilité d’ATEXO. Ils sont, par conséquent, hors périmètre du présent document. ATEXO, tous droits réservés Page 11 sur 27 Dossier d'Architecture Technique Version 1.4 ATEXO – V-PARIS – EPM - DAT001 Les autres environnements sont installés sur les plates-formes de la V-PARIS. Chaque environnement sera installé sur un serveur distinct. L’objectif de ces environnements est le suivant : o Environnement de recette : version n+1 ou n. Le but est d’y réaliser la recette fonctionnelle. Il est également destiné à la recette technique et à la validation des livrables. o Environnement de formation : version n. Environnement opérationnel o Environnement de pré-production : version n. Environnement opérationnel o Environnement de production : version n. Environnement opérationnel 4.5 Responsabilités et gestion des environnements Les environnements de développement, intégration continue et recette Usine sont sous la responsabilité d’ATEXO. Les environnements clients sont opérés par la V-PARIS qui assure l'hébergement et l'exploitation de la solution (fourniture matérielle, électrique et réseau, supervision ainsi que la sauvegarde de ces environnements). 4.6 Description des transports / circuit de livraison 4.6.1 Composants applicatifs Les composants d’installation sont téléchargés sur les serveurs de la V-PARIS. L’archive comportera l’ensemble des objets compilés et des fichiers de configuration, ainsi qu’un document précisant la procédure d’installation ou de migration depuis un environnement existant. L’installation des composants applicatifs sur les différents environnements s’effectue à partir d’une source commune, avec des versions adaptées, si nécessaire, à chaque environnement, en fonction du cycle de validation des livraisons – la version de recette peut, par exemple, être différente de la version de production. 4.6.2 Configuration La configuration est propre à chaque environnement. Elle ne sera donc pas transportée entre les environnements. Chaque environnement maintient sa propre configuration. Une traçabilité des modifications apportées à la configuration sera assurée pour permettre la propagation de ces modifications entre les environnements. 4.6.3 Paramétrage métier Le paramétrage métier sera transporté entre les environnements. Une attention particulière sera apportée aux éventuelles différences de version entre les environnements. Le transport du paramétrage pourra être réalisé, selon les cas : Par transport des fichiers de paramétrage Par l’exécution de scripts SQL ATEXO, tous droits réservés Page 12 sur 27 Dossier d'Architecture Technique Version 1.4 ATEXO – V-PARIS – EPM - DAT001 5 ARCHITECTURE LOGICIELLE 5.1 Présentation L'architecture logicielle de l'application EPM est la suivante : Les modules sont classés par catégories : Composant EJB : Noyau Composant Connecteur : Connecteur et Transporteur Composants métiers EPM Rédaction, Commission Composant transactionnel EPM: Rédaction, Noyau Composant Statistiques EPM: Base de données Statistiques : Administration, Statistiques, Passation, Les modules se connectent à différentes instances de la base de données à travers JDBC: Instance Rédaction utilisée uniquement par le module rédaction. Instance Workflow utilisée par le module noyau Instance Métier utilisée par le module noyau Instance Connecteur utilisée par le module connecteur Instance Statistiques utilisée par le module de statistiques ATEXO, tous droits réservés Page 13 sur 27 Dossier d'Architecture Technique Version 1.4 ATEXO – V-PARIS – EPM - DAT001 5.2 Vue des flux physiques Exemple de flux physique avec accès à un module métier Le schéma ci-dessus présente un schéma général d’interaction entre un utilisateur et l’application EPM : Les modules web (Passation, Commission, …) communiquent avec les services communs du Noyau via les mécanismes d’appels EJB distant (IIOP). Les modules web et le Noyau communiquent avec la base de données en JDBC (à travers la couche de persistance objet présentée dans la vue logique). Le Noyau intègre les fonctions de stockage documentaire qui utilisent le système de fichiers montés sur le serveur correspondant. 5.3 Flux réseau Flux Source Destination Protocole Module de publicité - suivi* (preprod) EPM concentrateurannonces-moltest.local-trust.com http tcp/80 Module de publicité - suivi* (prod) EPM concentrateurannonces-mol.localtrust.com http tcp/80 Module de publicité - publicité* (preprod) EPM concentrateurannonces-test.localtrust.com http tcp/80 Module de publicité - publicité* (prod) EPM concentrateurannonces.local- http tcp/80 ATEXO, tous droits réservés Page 14 sur 27 Dossier d'Architecture Technique Version 1.4 ATEXO – V-PARIS – EPM - DAT001 trust.com Messagerie sécurisée* (preprod) EPM messageriesecuriseepreprod.localtrust.com Messagerie sécurisée* (prod) EPM messageriesecurisee.localtrust.com http tcp/80 Mise à jour logicielle* EPM update.local-trust.com http tcp/80 Mails sortants (option relais interne) EPM IP du relai interne smtp tcp/25 Mails sortants (option sans relais interne) EPM all smtp tcp/25 Synchronisation du temps EPM IP serveur NTP (interne ou sur internet) ntp udp/123 Résolution DNS EPM IP serveur DNS dns tcp/53 et udp/53 Envoi vers la démat M13 APACHE DMZ DEMAT : m13.paris.fr tcp/8895 Réception depuis la démat M13 APACHE DMZ EPM tcp/11080 Réception depuis la démat M13 M13 APACHE DMZ tcp/15001 Envoi vers la démat Maximilien EPM marches.maximilien.fr https tcp/443 http tcp/80 Les flux marqués d’un astérisque (*) peuvent transiter par un serveur proxy en mode non authentifié uniquement. Les flux avec le proxy sont à détailler dans ce cas. 5.4 Liste, versions et caractéristiques des composants logiciels 5.4.1 Système d’exploitation EPM est déployé sur le système d’exploitation Linux en version 64 bits. L’installation doit être une installation minimale. Aucun composant logiciel ne doit être installé, à part SSH. Tous les composants logiciels spécifiques utilisés seront fournis par ATEXO. Il doit être possible de faire les mises à jour de ce système d’exploitation via les paquets fournis sur les dépôts de la distribution. 5.4.2 Serveur Web Le serveur HTTP utilisé est Apache HTTP Server 2.2. Il est couplé au serveur d’application (Tomcat) à l’aide du module Mod_proxy. Le serveur Apache héberge la charte graphique et fait office de frontal Web de l’ensemble des modules métiers. 5.4.3 Serveur de base de données ATEXO, tous droits réservés Page 15 sur 27 Dossier d'Architecture Technique Version 1.4 ATEXO – V-PARIS – EPM - DAT001 Le serveur de base de données utilisé est PostgreSQL en version 9.X 5.4.4 Serveur d’application et composants associés Les versions initiales des composants sont les suivantes (ces versions seront amenées à évoluer si besoin) : Composant Version Commentaire Apache Tomcat 7.0.X Installé par ATEXO JSDK Sun 7 Installé par ATEXO OpenOffice.org 3.3 Installé par ATEXO ATEXO, tous droits réservés Page 16 sur 27 Dossier d'Architecture Technique Version 1.4 ATEXO – V-PARIS – EPM - DAT001 6 ARCHITECTURE PHYSIQUE 6.1 Hébergement Les serveurs nécessaires au développement sont tous localisés dans les locaux d’ATEXO. L’hébergement est assuré par la V-PARIS, que ce soit pour les environnements de recette ou de production. Tous les environnements sont dédiés à l'application. 6.2 Répartition des fonctions logiques sur les serveurs Les principales caractéristiques des différents types de modules sont les suivantes : Type de module Configuration serveur (serveur d’application ou base de données) Composants métiers EPM Serveur d’application Tomcat Composant transactionnel EPM Serveur de base de données Postgresql, configuration orientée transaction Composant statistiques EPM Serveur de base de données Postgresql, configuration orientée statistiques Composant transporteur EPM Serveur d’application Tomcat Composant documents EPM Volume NAS L’intégralité des modules est déployée sur le même serveur (plate-forme matérielle) dans deux serveurs Tomcat distincts : Un tomcat contenant l’ensemble des modules métiers, et le module noyau. Un tomcat contenant les modules chargés des échanges avec LOCAL TRUST MPE. 6.3 Architecture physique de production 6.3.1 Schéma L'architecture de la solution retenue pour le CLIENT repose sur une machine virtuelle VmWare dédiée qui héberge l'ensemble des composants techniques de la solution EPM. Le schéma ci-dessous décrit les principales caractéristiques de l’architecture physique mise en œuvre : ATEXO, tous droits réservés Page 17 sur 27 Dossier d'Architecture Technique Version 1.4 ATEXO – V-PARIS – EPM - DAT001 6.3.2 Accès L’accès à l’application est réalisé par la mise en place d’un serveur Apache. Il s’interconnecte au serveur EPM par le connecteur mod_proxy. 6.3.3 Applications externes L’accès à LOCAL TRUST MPE s’effectue par échange de fichiers asynchrones par l’intermédiaire du module « transporteur » (transfert https avec authentification forte). 6.4 Architecture physique de recette L’environnement de recette est identique à l’environnement de production. 6.5 Dimensionnement matériel 6.5.1 Dimensionnement recommandée par ATEXO Equivalent à 4 CPU à 2,5 Ghz 6 Go RAM. Extensible à 8Go au besoin ultérieurement. 6.5.2 Volumétrie de stockage Pour la partie applicative : 40Go sur une seule partition. Pour le stockage des fichiers : montage CIFS sur un NAS. Cette partition doit être extensible facilement car la volumétrie augmente de manière ATEXO, tous droits réservés Page 18 sur 27 Dossier d'Architecture Technique Version 1.4 ATEXO – V-PARIS – EPM - DAT001 exponentielle. A titre indicatif, les données occupaient au total 100Go en 2011, 150Go en 2012 et 500Go en 2013. ATEXO, tous droits réservés Page 19 sur 27 Dossier d'Architecture Technique Version 1.4 ATEXO – V-PARIS – EPM - DAT001 7 INTERFACES AVEC LES SYSTEMES EXTERNES 7.1 Echanges avec la solution LOCAL TRUST MPE Lorsque la solution LOCAL TRUST MPE est utilisée pour les fonctionnalités de dématérialisation entreprises, une interface est mise en œuvre pour les échanges entre les deux plates-formes. Les environnements suivants de LOCAL TRUST MPE sont accessibles depuis EPM: Un environnement de production accédé depuis l’environnement de production EPM. Un environnement de recette accédé depuis l’environnement de recette EPM. Les types d'échanges entre l'application EPM et la plate-forme LOCAL TRUST MPE sont les suivants : Transfert de messages entre EPM vers LOCAL TRUST MPE o Publication de DCE sur LOCAL TRUST MPE o Publication au BOAMP Transfert de messages entre LOCAL TRUST MPE et EPM o Registre des questions entreprises o Registre des dépôts des entreprises o Plis (candidatures et offres) o Registre des retraits DCE o Suivi de l’envoi au BOAMP Messages de fonctionnement o Acquittement (envoyé pour chaque message) o Message de contrôle Le fonctionnement des échanges est décrit dans le schéma ci-dessous: ATEXO, tous droits réservés Page 20 sur 27 Dossier d'Architecture Technique Version 1.4 ATEXO – V-PARIS – EPM - DAT001 Les échanges entre EPM et Local Trust MPE sont chiffrés avec SSL et sécurisés via une authentification HTTPS mutuelle. Ils nécessitent donc la mise en place de certificats SSL « techniques ». ATEXO prend en charge la fourniture de ces certificats. Ces certificats doivent être mis à jour tous les 2 ans. Nommage des fichiers : Les fichiers messages sont nommés de la manière suivante : PREFIX composé de trois caractères indiquant plate-forme émettrice suivi du caractère ‘~’‘ suivi de trois caractères indiquant plate-forme destinataire : o EPM pour l’application EPM o DEM pour l’application DEMAT PREFIX composé de trois caractères indiquant l’environnement dans lequel l’application se trouve : o REC pour l’environnement de recette o FOR pour l’environnement de formation o PRE pour l’environnement de pré-production o PRO pour l’environnement de production PREFIX composé de 2 caractères indiquant la nature du message : o AR : message d’acquittement o MM : message métier o MC : message de contrôle PREFIX composé de 4 caractères représentant le type de message o AAPC : annonce BOAMP o PDCE : Publication du DCE o MDCE : modification du DCE o REGR : envoi des registres de retraits o REGD : envoi des registres dépôts. o REGQ : envoi des registres des questions Identifiant EPM de la consultation ATEXO, tous droits réservés Page 21 sur 27 Dossier d'Architecture Technique Version 1.4 ATEXO – V-PARIS – EPM - DAT001 La composition de la date est : yyyy_MM_jj_hh_mm_ss PREFIX de 4 caractères représentant le numéro de message envoyé. Ce compteur est remis quotidiennement à 0 (à minuit). Exemple de noms de fichiers : EPM~DEM~REC~MM~AAPC~REFCONSULTATION~DATE~0001.zip DEM~EPM~REC~AR~AAPC~REFCONSULTATION~DATE~0001.zip EPM~DEM~REC~MM~PDCE~REFCONSULTATION~DATE~0001.zip DEM~EPM~REC~AR~PDCE~REFCONSULTATION~DATE~0001.zip EPM~DEM~REC~MM~MDCE~REFCONSULTATION~DATE~0001.zip DEM~EPM~REC~AR~MDCE~REFCONSULTATION~DATE~0001.zip EPM~DEM~REC~MC~DATE~0001.zip DEM~EPM~REC~MC~DATE~0001.zip 7.2 Echanges avec la plate-forme Maximilien Les flux d’échanges avec la plate-forme de dématérialisation vers Maximilien sont différents. Tout passe par une connexion HTTPS initiée par EPM à destination d'un WebService hébergé sur Maximilien. Il n'y a aucune connexion entrante vers EPM initiée par Maximilien. C'est EPM qui va se charger d'envoyer ses documents directement à Maximilien, ainsi que d'aller interroger périodiquement Maximilien en lui demandant si des nouveaux dépôts / retraits / questions ont été créés. Le schéma ci-dessous correspond à la situation après la migration sur Maximilien : ATEXO, tous droits réservés Page 22 sur 27 Dossier d'Architecture Technique Version 1.4 ATEXO – V-PARIS – EPM - DAT001 7.3 Echanges avec les services centralisés fournis par Atexo Plusieurs services centralisés, hébergés par ATEXO, sont utilisés par la solution EPM. Il faut donc que les machines puissent accéder aux adresses suivantes : Pour les environnements de recette et préproduction : - http://concentrateur-annonces-mol-test.local-trust.com/ - http://concentrateur-annonces-test.local-trust.com/ - http://messagerie-securisee-preprod.local-trust.com/ Pour l’environnement de production : - http://concentrateur-annonces-mol.local-trust.com/ - http://concentrateur-annonces.local-trust.com/ - http://messagerie-securisee.local-trust.com/ De plus, la mise à jour de l’application nécessite un accès à l’URL suivante : - http://update.local-trust.com/ ATEXO, tous droits réservés Page 23 sur 27 Dossier d'Architecture Technique Version 1.4 ATEXO – V-PARIS – EPM - DAT001 7.3.1 Messagerie sécurisée - Ce module permet les échanges de mails avec les entreprises, et se distingue du module interne EPM lié aux fonctions agent (messages d’alertes, mails de confirmation …). - Il est mutualisé et déjà installé chez ATEXO. - Il doit être accessible sur Internet par les entreprises (l’application cliente n’étant pas directement exposée à Internet) - Les entreprises y accèdent via une application en PHP sur Internet. Concentrateur d’annonces 7.3.2 ATEXO s'appuie sur le Module de publicité MarchesOnline (MOL 2.0) édité et opéré en marque blanche par le Groupe Moniteur. Ce module de publicité dispose de l'agrément de la DILA pour la transmission des avis aux différents supports de publication par flux XML. Le service de Concentrateur d'annonces est interfacé à l'application via l'interface générique de la solution progicielle (cf. diagramme des flux réseau). 7.4 Echanges avec les interfaces financières de la Ville de Paris Plusieurs échanges sont prévus avec les interfaces financières de la Ville de Paris via des fichiers plats : - go - siha - alize Ces échanges seront décrits plus en détails dans le dossier d’exploitation. ATEXO, tous droits réservés Page 24 sur 27 Dossier d'Architecture Technique Version 1.4 ATEXO – V-PARIS – EPM - DAT001 ATEXO, tous droits réservés Page 25 sur 27 Dossier d'Architecture Technique Version 1.4 ATEXO – V-PARIS – EPM - DAT001 8 PRINCIPES DE SECURITE 8.1 Plates-formes serveurs Les principes de sécurité suivants sont appliqués pour la plate-forme serveur : Les serveurs applicatifs se trouvent dans la zone LAN de la V-PARIS. Ils ne sont accessibles que depuis l'intérieur du SI. Les accès RLOGIN et TELNET sont fermés Les services non nécessaires au fonctionnement du système ne sont pas installés Les ports réseau non utilisés sont fermés Les droits sur les systèmes de fichiers sont limités à ce qui est nécessaire aux différents comptes applicatifs Les services s’exécutent sur des comptes spécifiques non root L’accès à la base de données PostgreSQL est filtré. Seuls les serveurs applicatifs sont autorisés L’accès aux ressources applicatives est contrôlé au niveau applicatif par des mécanismes de gestion des rôles 8.2 Postes V-PARIS Les principes de sécurité suivants sont appliqués pour les postes clients : Les sessions ont une durée de vie limitée et sont gérées par des cookies de session Les zones de saisie des mots de passe sont protégées par un mécanisme de masquage des caractères Les échanges et interactions avec l’utilisateur sont protégés au niveau applicatif Protection des données GET/POST Protection contre les attaques – cross-scripting, injection SQL, cookies etc. Une version de Java 1.7 sera nécessaire pour ouvrir correctement les plis. ATEXO, tous droits réservés Page 26 sur 27 Dossier d'Architecture Technique Version 1.4 ATEXO – V-PARIS – EPM - DAT001 9 ANNEXE 1 : DESCRIPTION DES ECHANGES WSSO Exploitation du WSSO L’application EPM s’appuie sur le système d’authentification unique (SSO) de la VILLE DE PARIS. Ainsi chaque module d’EPM proposant une interface graphique, intègre une fonctionnalité permettant de récupérer les informations transmises par WSSO lorsqu’un utilisateur, y étant autorisé par WSSO, accède au dit module. A partir de la référence utilisateur fournie par WSSO, le module appelle un service hébergé par le Noyau d’EPM afin d’obtenir les caractéristiques de l’utilisateur ainsi que les droits qui lui sont associés. Administration des utilisateurs En amont de l’exploitation de l’authentification unique des utilisateurs, il est nécessaire de déclarer ces utilisateurs auprès de WSSO. Pour se faire EPM s’appuie sur l’outil fournit par la VILLE DE PARIS permettant de rechercher un utilisateur dans le référentiel unifié et d’en obtenir son identifiant WSSO. Cet identifiant est pris en compte par EPM pour être intégré au référentiel utilisateur propre à EPM. Ainsi, chaque utilisateur EPM bénéficie d’un identifiant connu de WSSO. Sur ce référentiel utilisateur, EPM offre un mécanisme d’habilitations permettant de définir les droits d’accès aux différents modules et aux fonctionnalités associées. Quotidiennement, un traitement EPM construit les fichiers de paramétrages destinés à WSSO et fournit la liste des utilisateurs habilités à accéder aux modules via leurs applications WEB. Ainsi, à partir de l’unique référentiel utilisateur, EPM produit plusieurs fichiers de paramétrage WSSO. Chaque fichier est destiné à une unique application WEB, identifiée dans WSSO, et correspondant à un module. ATEXO, tous droits réservés Page 27 sur 27
