9 juillet 2014

1. 9 juillet 2014 DE 2010/65 - Scenarii d'authentification unique Comité de Pilotage

2. Agenda ► 1. Objectifs et déroulement du projet 2. Scenarii d'authentification unique 3 juillet 2014 - Confidentiel

3. Objectifs et déroulement du projet Le MEDDE souhaite dresser un bilan au niveau des SI portuaires concernés, et identifier des scenarii pour la mise en place d’authentification unique pour les déclarant naviguant entre ces différents SI portuaires. Contexte et objectifs • Analyse des documents existants (DE 2010/65, précédentes études…) • Réalisation des entretiens avec les représentants des 8 SI portuaires • Rédaction du bilan de l’existant • Identification et comparaison de 5 scenarii potentiels • Étude comparative de 2 scenarii Phases du projet (de fin mars à fin mai 2014) • 8 entretiens téléphoniques réalisés avec : • Escaleport (24 ports décentralisés), • Le GPM de Rouen • Le GPM de Bordeaux • Le GPM de Marseille • Le GPM du Havre • Le GPM de Nantes Saint-Nazaire • Le GPM de Dunkerque • Les CCI de Toulon, de Haute et Basse Corse • Une réunion avec les représentants de Cerbère • 3 groupes de travail avec les représentants des SI portuaires Entretiens et réunions réalisés 9 juillet 2014 - Confidentiel

4. Bilan de l’existantDes applications relativement similaires • Toutes les applications des PCS sont des applications Web • La majorité d’entre elles ont été développées par le SI Portuaire directement, et certaines sont en cours de refonte pour appliquer la Directive DE 2010/65 • La gestion des droits se fait partout sous forme de profils, souvent retrouvés dans l’ensemble des SI Portuaires (ex: capitainerie, consignataire, remorqueur, lamaneur…) • L’authentifications’effectue quasiment tout le temps localement dans l’application, avec un login/mot de passe propre à cette application • Soit stocké dans une base de donnée interne à l’application • Soit stocké dans un annuaire partagé avec d’autres applications du SI Portuaire • Soit stocké par Cerbère dans le cas d’Escaleport • Le login est souvent de la forme « nom » ou « pnom » mais les déclarants utilisent également souvent des comptes génériques par société 9 juillet 2014 - Confidentiel

5. Bilan de l’existantContraintes partagées • Administration • Gestion des habilitations • Fort besoin de réactivité (y compris nuit et week-end) et besoin de conserver les vérifications au niveau local (par ex. vérification SIRET) • Le portail doit être automatisé et ne pas nécessiter la mise en place de procédures lourdes d’administration • Chaque SI portuaire doit continuer à maîtriser ses profils et habiliter ses utilisateurs • La gestion globale des habilitations (octroi, modification) doit rester du ressort du SI portuaire • Authentification • Accès • E-scaleport doit rester protégé par Cerbère • Les identités ne doivent pas être centralisées : seul le couple login/mot de passe est nécessaire à l’authentification, et les autres informations sur l’identité doivent rester au niveau des SI portuaires • Le login / mot de passe est le mode d’authentification pressenti pour le portail d’authentification • Le niveau de sécurité ne doit pas être abaissé par la mise en place du portail d’accueil, un socle minimal doit être appliqué par les SI Portuaires (ex. complexité des mots de passe, comptes nominatifs uniquement) • L’accès direct au SI portuaire sans passer par le portail doit être maintenu 9 juillet 2014 - Confidentiel

6. Bilan de l’existant2 scénarii choisis parmi des familles de scénarii proposés • Coffre fort de mots de passe / agrégation de comptes • Authentification centralisée • Le portail (via un composant additionnel) permet à l’utilisateur de référencer ses comptes dans les SI Portuaires et de se connecter une seule fois • Ex: fonctionnement de MonServicePublic • L’authentification est centralisée et assurée par un composant, qui transmet l’information aux SI Portuaires Trop coûteux • Avec un nouveau composant • Avec Cerbère (syst. authent. du MEDDE) • Utilisation de sites tiers Trop coûteux • Les déclarants se connectent via un compte qu’ils possèdent sur un site tiers • Ex: La Poste, Facebook, Google… • Authentification partagée entre les ports • L’authentification est décentralisée : le portail renvoie (via un composant appelé IdP Proxy) les informations de connexion au port de rattachement du déclarant qui valide la connexion Dépendance avec le niveau de sécurité du tiers • Pas de connexion transparente mais un login unifié • L’authentification est réalisée par le SI portuaire mais l’utilisateur a un login commun à l’ensemble des SI portuaires (mais mot de passe différent) • Avec un nouveau composant IdP Proxy • Avec Cerbère comme IdP Proxy Pas de gain fonctionnel suffisant, trop d’administration au niveau du PCS IdP (Identity Provider) : composant assurant l’authentification et la fournissant à une application (Service Provider, ou SP) IdP Proxy : IdP déléguant la phase d’authentification à un IdP tiers 9 juillet 2014 - Confidentiel

7. Agenda 1. Objectifs et déroulement du projet ► 2. Scenarii d'authentification unique 2. 1 Scenario 1.a : authentification centralisée avec Cerbère 2. 2 Scenarii 2.a et 2.b : IdP Proxy Confidentiel - 3 juillet 2014

8. Scenario 1.a : authentification centralisée avec Cerbère Principe et cinématique d’usage • Les SI Portuaires sont protégés par Cerbère. Le déclarant s’authentifie à Cerbère, qui valide l’accès grâce à son référentiel et se charge de propager cette authentification aux SI Portuaires Principe Cinématique • Le déclarant accède au portail et sélectionne le port auquel il souhaite accéder OU BIEN le déclarant va sur l’adresse du SI Portuaire protégée par Cerbère Le déclarant peut accéder directement au SI portuaire 3 avec un login/mot de passe local 2. L’application portuaire est protégée par Cerbère, elle renvoie l’utilisateur sur celui-ci 3. L’utilisateur saisit son login / mot de passe Cerbère Portail d’accueil Cerbère 4. Cerbère fournit un jeton d’authentification que le SI portuaire accepte puisqu’il fait confiance à Cerbère, le SI Portuaire ouvre la session associée LDAP Agent compatible Cerbère SI portuaire 3 SI portuaire 1 SI portuaire 2 5. S’il sélectionne un autre port, l’utilisateur est connecté de façon transparente 9 juillet 2014 - Confidentiel

9. Scenario 1.a : authentification centralisée avec Cerbère Principe et cinématique d’initialisation • L’utilisateur doit se faire créer : • Un ou plusieurs comptes dans les SI Portuaires, qui sont habilités par le SI Portuaire • Un compte Cerbère (créé par lui-même ou de manière centralisée) Principe Cinématique 3. Le compte Cerbère est créé avec la même adresse mail que celui du SI portuaire (soit par l’utilisateur, soit par le SI Portuaire 1) 1. Le déclarant demande un compte au SI portuaire 1 Cerbère 4. Si l’utilisateur demande accès à un autre SI portuaire, son compte doit y être créé avec la même adresse email que celle de son compte Cerbère. Le SI Portuaire 2 l’habilite lui-même 2. Le compte SI portuaire 1 est crée et habilité au sein du SI portuaire 1 SI portuaire 1 SI portuaire 2 9 juillet 2014 - Confidentiel

10. Scenario 1.a : authentification centralisée avec CerbèrePoints-clés du scénario • Prérequis • Points d’attention et risques • Chaque SI portuaire se base sur Cerbère pour l’authentification, par conséquent, chaque SI portuaire doit installer un module permettant d’accepter les messages provenant de Cerbère (et prévoir une autre URL d’accès non protégée pour les personnes souhaitant y accéder directement avec un compte local au SI Portuaire) • Un travail préparatoire sur les comptes doit être réalisé avant la transmission de la liste des comptes à créer dans Cerbère • Les SI portuaires doivent faire confiance à Cerbère pour tout ce qui relève de l’authentification • Les utilisateurs doivent créer et se connecter à Cerbère pour définir leur mot de passe Cerbère • L’utilisateur aura plusieurs login/mot de passe(1 pour Cerbère et un par SI portuaire auquel il se connecte) et risque d’être peu à l’aise 9 juillet 2014 - Confidentiel

11. Scenario 1.a : authentification centralisée avec CerbèrePoints-clés du scénario • Les fonctionnalités de Cerbère (infrastructure, service, self-service) sont déjà disponibles • Chaque SI portuaire bénéficie du niveau de sécurité de Cerbère, en cours de qualification RGS • Le MEDDE peut fournir le module à installer sur le SI Portuaire dans la plupart des cas • Chaque SI portuaire peut se raccorder à Cerbère à son rythme • Avantages • Inconvénients • Au lancement du chantier, une création de masse des comptes déjà présents dans les SI portuaires est à prévoir • La création d’un compte doit être effectuée au niveau central (par l’utilisateur ou sur demande du SI portuaire) en plus du niveau local • Coûts & planning Coût de mise en place : 223 j/h dont 20 par PCS Coût récurrent additionnel : 0,5h / nouvel utilisateur pour les PCS Planning de mise en œuvre : un peu moins de 2 mois par SI Portuaire, parrallélisable 9 juillet 2014 - Confidentiel

12. Agenda 1. Objectifs et déroulement du projet ► 2. Scenarii d'authentification unique 2. 1 Scenario 1.a : authentification centralisée avec Cerbère 2. 2 Scenarii 2.a et 2.b : IdP Proxy Confidentiel - 3 juillet 2014

13. Scenarii 2.a et 2.b : IdP Proxy Principe et cinématique d’usage • Chaque déclarant est rattaché à un port. L’IdP Proxy s’assure de l’authentification du déclarant auprès de ce port, puis transporte l’information d’authentification vers le port souhaité. L’IdP Proxy ne stocke aucun login/mot de passe et ne fait que rediriger les connexions. Principe Cinématique • Le déclarant accède au portail • 2. Il choisit son port de rattachement (ici SI portuaire 1) Le déclarant peut accéder directement au SI portuaire 3 avec le login et mot de passe du SI portuaire 3 5. L‘IdP Proxy crée un jeton de session pour le déclarant IdP Proxy 3. Le SI portuaire 1 demande le login/mot de passe 4. Le SI portuaire questionne sa base de données, puis valide l’authentification 6. Le portail redirige le déclarant vers le SI portuaire demandé, avec le jeton de session prouvant son authentification Module acceptant le jeton Module d’authentification SI portuaire 2 SI portuaire 3 SI portuaire 1 9 juillet 2014 - Confidentiel

14. Scenarii 2.a et 2.b : IdP ProxyPrincipe et cinématique d’initialisation • Chaque SI portuaire continuant à gérer ses comptes exclusivement, le scenario 2 ne requiert aucune action supplémentaire lors de la phase d’initialisation Principe Cinématique 1. Le déclarant demande un compte au SI portuaire 3. Si le déclarant demande un accès à un autre SI portuaire, son compte doit y être créé avec la même clé dans un attribut prédéfini (ex: email) 2. Le compte est créé et habilité avec une clé unique dans un attribut prédéfini (ex: email) SI portuaire1 SI portuaire 2 • Deux choix se présentent pour jouer le rôle d’IdP Proxy: utiliser Cerbère (scénario 2.a) ou utiliser un nouveau composant (2.b) 9 juillet 2014 - Confidentiel

15. Scenarii 2.a et 2.b : IdP ProxyPoints-clés du scénario 2 • Prérequis • Points d’attention et risques • Chaque SI portuaire doit installer deux modules différents : un pour assurer l’authentification, l’autre pour réceptionner les jetons fournis par l’IdP Proxy • Cerbère subit une forte évolution dans les deux scenarii, en particulier dans le 2.a • Chaque utilisateur doit être rattaché à un SI portuaire et connaître son port de rattachement • Cerbère doit déléguer l’authentification aux SI portuaires, par conséquent, les SI portuaires doivent assurer un niveau de sécurité au moins équivalent • Scénario 2.a : dépendance avec les autres évolutions prévues autour de Cerbère : l’évolution de Cerbère nécessaire pour démarrer le scénario peut ne pas être prioritaire et réalisable dans les délais souhaités 9 juillet 2014 - Confidentiel

16. Scenario 1.a : authentification centralisée avec CerbèrePoints-clés du scénario 2 • Pas de pré-enregistrement dans Cerbère en comparaison du scénario 1 • Chaque SI portuaire reste maître de ses identités et de l’authentification • Avantages • Inconvénients • Davantage d’intégration que pour le scénario 1 • Si 2.a : tributaire des arbitrages et priorisations des évolutions autour de Cerbère • Si 2.b : infrastructure à mettre en place et maintenir • Coûts • Coût de mise en place scénario 2.a : 334 j/h dont 25 par PCS • Coût de mise en place scénario 2.b: 340 j/h dont 25 par PCS + coût de 2 serveurs (hypothèse: produit OpenSource) • Coût récurrent additionnel : - 2.a : non évaluable - 2.b : 44j/h MCO par an + coût exploitation 2 serveurs (+ option: 3€/an/user pour le support d’une SSII) • Planning de mise en œuvre : • 2.a : 10 mois à partir du lancement de l’évolution de Cerbère + + raccordement des SI Portuaires (4/5 mois, parallélisable) • 2.b : 8 mois pour mise en place de l’infrastructure + raccordement des SI Portuaires (4/5 mois, parallélisable) 9 juillet 2014 - Confidentiel

17. Synthèse Ergonomie utilisateur initialisation Ergonomie utilisateur usage Coût Risques Délai de mise en place pour le 1er PCS 1 • Authentification centralisée Cerbère Une étape supplé-mentaire SSO 223 j/h (65 MEDDE, 21 / PCS) Déjà en place 2 mois • L’authentification est centralisée et assurée par un composant, qui transmet l’information aux SI Portuaires 2.a • Authentification déléguée avec Cerbère Pas de chan-gement Choix du port à faire 334 j/h (134 MEDDE, 25 / PCS) Délai d’évo-lution Cerbère 10 mois • L’authentification est déléguée et relayée par Cerbère, qui transmet l’information aux SI Portuaires 2.b • Authentification déléguée avec un autre composant Pas de chan-gement Choix du port à faire 340 j/h (140 MEDDE,25 / PCS) + MCO Nouvelle infras-tructure 8 mois • L’authentification est déléguée et relayée par un nouveau composant, qui transmet l’information aux SI Portuaires 9 juillet 2014 - Confidentiel

18. www.solucom.fr Contact Catherine KHERIAN Consultante Senior Tel : +33 (0)1 49 03 25 64 Mobile : +33 (0)6 76 29 07 68 Mail : catherine.kherian@solucom.fr Charif MESSARY Consultant RMS Tel : +33 (0)1 49 03 25 64 Mobile : +33 (0)6 76 29 07 68 Mail : catherine.kherian@solucom.fr