Apache Tomcat (En Automatique)
Total Page:16
File Type:pdf, Size:1020Kb
Université de Poitiers Institut Universitaire de Technologie de Châtellerault Département Réseaux et Télécommunications Licence professionnelle Métiers des Réseaux Informatiques et Télécommunications Spécialité Administration des Réseaux Multimédia RAPPORT D’INSTALLATION Présenté par : Baptiste MOINE Promotion 2016-2017 Apprenti au Centre Hospitalier Henri LABORIT Sujet du rapport : Projet CAS – Installation de CAS Server v5 Sauf mention contraire, ce rapport est mis à disposition selon les termes de la licence https://creativecommons.org/licenses/by-nc-sa/4.0/ TABLE DES MATIÈRES Table des matières.................................................................................................................1 Note........................................................................................................................................2 Introduction.............................................................................................................................3 Tickets................................................................................................................................3 Échanges HTTP.................................................................................................................4 Architecture............................................................................................................................5 Préparation du système.........................................................................................................6 Configuration du nom d’hôte..............................................................................................6 Configuration de OpenSSH-Server...................................................................................7 Installation des dépendances................................................................................................9 Apache Tomcat (en automatique)......................................................................................9 Apache Tomcat (en manuel)............................................................................................11 JRE (« Java Runtime Environment ») et JDK (« Java Development Kit »).....................19 Apache Maven.................................................................................................................20 Installation de CAS...............................................................................................................22 Application et adaptation du modèle Maven....................................................................22 Compilation de CAS.........................................................................................................38 Ajout d’un frontal avec Apache HTTP..................................................................................41 Installation........................................................................................................................41 Fichiers de configuration d’Apache HTTP.......................................................................42 Configuration....................................................................................................................44 Tests.................................................................................................................................54 Création d’un environnement de test pour l’authentification sans multifacteur...................57 Installation d’Active Directory sous Windows Server 2016.............................................58 Configuration du service DNS..........................................................................................62 Configuration de l’annuaire..............................................................................................63 Génération d’un keytab....................................................................................................66 Installation de Kerberos sur le serveur CAS....................................................................67 Mise à jour du chemin d’authentification de CAS............................................................71 Ajout de miletrie.lan au registre de services....................................................................73 Intégration d’un ordinateur client au domaine miletrie.lan...............................................74 Configuration du navigateur pour autoriser SPNEGO.....................................................74 Déploiement d’une application de test basée sur phpCAS.............................................75 Test de l’authentification Kerberos sur Appli1..................................................................84 Analyse protocolaire.........................................................................................................84 Baptiste MOINE 1 Installation de CAS Server v5 NOTE Les informations suivantes ne sont pas nécessairement représentatives d’une installation ou configuration optimale et ne s’appliquent que dans un contexte défini, ainsi, il est primordial de comprendre le fonctionnement de chacune de ces configurations et de procéder le cas échéant à une adaptation / extension de ces dernières afin d’être cohérent avec l’environnement dans lequel cette installation est faite. Pour des raisons de confidentialité relatives à l’éthique et au secret professionnel, certaines informations ont potentiellement été extraites / falsifiées. Baptiste MOINE 2 Installation de CAS Server v5 INTRODUCTION CAS (pour « Central Authentication Service ») est, comme l’indique son nom, un serveur d’authentification centralisé basé sur la technologie SSO (« Single Sign-On ») orienté vers les applications WEB. Cette solution est mature et a été déployée dans de nombreuses universités américaines. Tickets Pour fonctionner, CAS est basé sur différents tickets (ou « cookies ») et s’appuie principalement sur le protocole HTTP pour l’échange de ces derniers. TGC (« Ticket-Granting Cookie ») ou TGT (« Ticket Granting Ticket ») Le TGC se présente sous la forme d’un cookie de session HTTP, il permet au client (p. ex., navigateur WEB) d’indiquer à CAS ou à l’application, l’identifiant de session associée à notre authentification, si le client ne supporte pas l’ajout de cookie, l’authentification sera exigée à chaque appel au serveur CAS. Ce cookie joue un rôle crucial dans le mécanisme d’authentification unifiée, c’est pourquoi il peut être sujet à des tentatives de vol (« magic cookie theft ») lors d’une attaque par détournement de session (« Session Hijacking »). Une attaque par Session Hijacking est souvent issue de l’exploitation d’une vulnérabilité de type XSS (« Cross-Site Scripting ») permettant à un attaquant de procéder à l’utilisation détournée d’une API (« Application Programming Interface » ou interface de programmation) côté client afin, par exemple, d’exécuter du code JavaScript et dérober une copie du magic cookie. Des attaques telles que le MitM (« Man in the Middle ») permettant l’analyse de paquets ne nous étant pas nécessairement destinés (« sniffing »). Pour faire face aux attaques de type Session Hijacking, ce cookie est écrit en RAM et expire à la fermeture du navigateur WEB, utilise le drapeau (« flag ») HTTPOnly pour empêcher l’accès par les API côté client (p. ex., JavaScript) ainsi que le Secure Flag indiquant au navigateur d’utiliser une communication HTTPS pour l’échange de ce cookie avec l’application. ST (« Service Ticket ») Le ST est un ticket à usage unique généré par le serveur CAS et permettant l’authentification du client sur une application WEB. Il est échangé entre le client et l’application WEB l’application par l’intermédiaire d’une requête HTTP GET, l’application récupère ensuite l’identifiant associé à ce client en envoyant ce ticket au serveur CAS. PT (« Proxy Ticket ») Le PT est un ticket utilisé comme un ST par l’application WEB, mais permet l’authentification de l’utilisateur sur un service auquel il n’a pas d’accès direct. L’authentification est alors déléguée (principe du proxy) au serveur CAS qui est alors capable de supporter l’utilisation de mécanismes supplémentaires (p. ex., autorisation, attributs). PGT (« Proxy Granting Ticket ») Le PGT est envoyé par le serveur CAS au proxy CAS, il permet au serveur proxy de demander au serveur CAS la génération d’un PT pour l’authentification sur une application WEB. Baptiste MOINE 3 Installation de CAS Server v5 Échanges HTTP 1. La requête initiale du client WEB à l’application nécessitant une authentification est redirigée vers l’URL login du serveur CAS avec une URL de retour (serviceid ou « callback ») en paramètre du GET ; 2. Le serveur CAS procède à l’authentification du client en utilisant le mécanisme local d’authentification puis redirige le client vers l’application d’origine en utilisant le serviceid en utilisant le mécanisme de redirection HTTP, le TGC est alors enregistré par le client HTTP (s’il est accepté) ; 3. L’application WEB reçoit le ST lors de la redirection du client en paramètre de la requête GET ; 4. L’application établit une communication HTTP directe avec le serveur CAS et envoie son URL et le ST envoyé par le client. Le serveur CAS valide le ticket et le marque comme expiré après avoir retourné l’UID (« User IDentificator ») du client. L’authentification de l’utilisateur sur l’application WEB est valide jusqu’à l’expiration du TGC. En mode proxy, si le ST est validé, le serveur retourne un identifiant de PGT (PGT-id) en complément. Baptiste MOINE 4 Installation de CAS Server v5 ARCHITECTURE La majeure partie des