Dossier Technique. Détail des modifications apportées à GRR. Détail des modifications apportées à GRR Le 17/07/2008. Page 1/10

Transcription

1 Dossier Technique Page 1/10

2 Sommaire : 1. REPONSE TECHNIQUE A LA DEMANDE Prise en compte de la dernière version de phpcas Gestion de la connexion à GRR Récupération des attributs de l utilisateur depuis l annuaire LDAP Gestion de la correspondance profil / statut Connexion à GRR d un nouvel utilisateur Connexion à GRR d un utilisateur déjà connu Purge des comptes et des réservations Modification de l entête de GRR Boutons de connexion/déconnexion originels Accès aux paramètres des comptes utilisateurs 10 Page 2/10

3 1. REPONSE TECHNIQUE A LA DEMANDE 1.1. Prise en compte de la dernière version de phpcas GRR supporte l authentification SSO avec CAS mais celui-ci est livré de base sans la librairie phpcas qui permet de mettre en place ce mécanisme. Il a donc fallu télécharger la librairie phpcas (en version , la version stable actuelle) à cette adresse et décompresser le contenu de l archive dans un répertoire nommé «CAS» à l intérieur du répertoire de l application web GRR. Il est a noter qu un bug dans le fichier «cas.php» de la librairie phpcas (survenant avec certaines versions de php 5) a été corrigé pour pouvoir réaliser l intégration Gestion de la connexion à GRR Cette partie regroupe plusieurs demandes : la récupération des attributs des utilisateurs depuis l annuaire LDAP, la correspondance entre profil de l utilisateur (LDAP) et son statut (GRR), la connexion d un nouvel utilisateur à GRR, et la connexion d un utilisateur déjà connu Récupération des attributs de l utilisateur depuis l annuaire LDAP Pour récupérer ces attributs, la solution mise en place a été l utilisation de la fonctionnalité CAS V3, solution que le GIP RECIA nous avait demandé de privilégier. Modification de la configuration du serveur CAS : Modification du fichier «deployerconfigcontext.xml» : Modification du bean «attributerepository» afin de récupérer des attributs supplémentaires dans l annuaire LDAP. Modification du bean «serviceregistrydao afin d indiquer au serveur CAS quels sont les attributs à renvoyer, et pour quelle(s) application(s). Modification de la jsp «casservicevalidationsuccess.jsp» : Ajout dans le XML attestant la réussite de l authentification de l utilisateur, de l ensemble des attributs spécifiés précédemment dans le bean «attributerepository» (parcours dynamique des attributs de la map avec leur propriété key). Modification de la librarie phpcas : Modification du fichier «client.php» : Modification de la fonction «validatept()» effectuant la lecture du XML renvoyé par le serveur CAS suite à l authentification de l utilisateur. Rajout de l encodage en UTF8 du XML de réponse de CAS (variable $text_response), pour permettre la récupération d attributs comportant des accents et des caractères spéciaux. Rajout du décodage UTF8 des champs pour permettre ensuite l affichage dans l application GRR. Page 3/10

4 (exemple : $this->setuid(utf8_decode($uid[0]->get_content()));) Ajout de la lecture des différents attributs retournés en plus des attributs de base. Ajout des différentes variables avec leurs getters et setters, liés aux attributs lus dans le XML. Modification du fichier «cas.php» : Ajout des getters liés aux attributs lus depuis la fonction «validatept()» du fichier «client.php». Modification du fichier «include\cas.inc.php» : Récupération et mapping dans des variables PHP des nouveaux attributs récupérés par le serveur CAS. En plus des noms, prénoms et s, les attributs ENTPersonFonctions et preferedlanguage sont récupérés. l attribut ENTPersonFonctions est utilisé pour établir la correspondance avec le statut GRR, et preferedlanguage est utilisé pour sélectionner la langue par défaut de l utilisateur s il est présent. Ces deux derniers attributs nécessitent un traitement avant de pouvoir être utilisés. L attribut ENTPersonFonctions contient deux informations à récupérer : le code de la fonction, et son libellé. Deux fonctions «recuperer_codefonction» et «recuperer_libellefonction» ont donc été créées dans le fichier «fonctionsajoutees.inc.php». De plus, une fonction nommée «traiter_language» permettant le traitement de l attribut LDAP «preferedlangage» a été réalisée dans ce même fichier. Ces fonctions sont appelées à la fin du fichier «include\cas.inc.php» comme le montre le code suivant : Page 4/10

5 Gestion de la correspondance profil / statut Il a été demandé d offrir à l administrateur la possibilité de faire correspondre le profil d un utilisateur (appelé fonction dans l annuaire LDAP), et un statut dans l application GRR. Pour cela, une nouvelle table nommée «grr_correspondance_statut» a été créée. Cette table comprend 3 champs, le code de la fonction, son libellé, et le statut GRR qui lui sera associé. Les informations nécessaires concernant la fonction sont lues dans l annuaire LDAP, dans l attribut «ENTPersonFonctions», qui est un champ multivalué constitué de 5 valeurs. Le code de la fonction et son libellé sont respectivement les 2 ème et 3 ème champs. En plus de la création de la nouvelle table, les modifications effectuées sont les suivantes : Modification du fichier «admin_col_gauche.php» : Ajout de la nouvelle entrée dans le menu, avec contrôle du niveau de droits requis. Création du fichier «admin_corresp_statut.php» : Création d une page permettant de lister les correspondances profil ldap / statut grr déjà connues par l application. Cette page donne la possibilité à l administrateur de supprimer, avec une invite de confirmation javascript, les entrées de son choix de la table des correspondances. De plus, un formulaire d ajout permet d ajouter manuellement des correspondances (Pour l'ajout automatique, Cf.section 1.2.3). Enfin, l administrateur peut, pour une fonction, modifier le statut GRR associé. Cette action n a en revanche aucun impact sur les utilisateurs CAS déjà connus de GRR. Page 5/10

6 Connexion à GRR d un nouvel utilisateur Quand un utilisateur se connecte pour la première fois à GRR via CAS, celui-ci est ajouté à la table des utilisateurs et est invité à remplir ses informations personnelles. Il a été demandé que les champs de la table soient renseignés automatiquement avec les informations de l utilisateur contenues dans l annuaire LDAP. Pour ce faire, une fois les attributs récupérés à l aide du XML produit par le serveur CAS (Cf. section 1.2.1), les opérations suivantes ont été effectuées : Modification du fichier «index.php» : Il a été nécessaire de passer en paramètre à la fonction «grr_opensession()» les données récupérées par phpcas lors de l authentification de l utilisateur par le serveur CAS. Pour cela, une variable de type tableau, nommée $tab_login a été utilisée. Modification de la fonction «grr_opensession» du fichier «include\session.inc.php» : Que l utilisateur soit présent ou non dans la base locale de GRR, il a été nécessaire de récupérer, grâce à la variable $tab_login citée précédemment, les données lues depuis LDAP (nom, prénom, , code de fonction, libellé de fonction, langage par défaut). Lorsque l utilisateur n est pas présent dans la base, celui-ci est ajouté. Il a donc fallu modifier la requête d insertion en base, pour y intégrer les nouveaux champs récupérés, comme le langage par défaut et le statut. Le principe de déduction de ces deux champs avant l insertion en base est abordé par la suite. Conformément à la demande, la première connexion de l utilisateur est aussi le moment où son statut est calculé, en utilisant la table de correspondances. Il a été demandé d appliquer un test lors de cette première connexion : si la fonction de l utilisateur ne possède pas d entrée dans la table de correspondance (c'est-à-dire que l application ne saura pas quel statut lui donner), alors une entrée doit être créée pour cette fonction, et le statut «visiteur» doit lui être associé. L administrateur pourra par la suite changer le statut associé à cette fonction. (Cf. section 1.2.2) La fonction réalisant ce test lors de la première connexion a été réalisée dans le fichier «fonctionsajoutees.inc.php» et se nomme «effectuer_correspondance_profil_statut()». Elle est appelée juste après la récupération des informations de l utilisateur comme le montre le code ci-dessous : Il faut noter que si la fonction «effectuer_correspondance_profil_statut()» prend en paramètre le libellé de la fonction en plus de son code, c est pour qu elle puisse réaliser l ajout au cas où la fonction ne soit pas encore connue par GRR. Page 6/10

7 Si la fonction existe dans la table de correspondance, l utilisateur sera créé avec le statut correspondant. Concernant le langage (attribut preferedlanguage), si l attribut existe, alors les deux premiers caractères sont testés, et en fonction de ceux-ci, l utilisateur se verra attribuer comme langue par défaut «fr», «en», «it», «es», ou «de». La fonction réalisant ce traitement a été créée dans le fichier «fonctionsajoutees.inc.php» et se nomme «traiter_language». Remarque : la conséquence de l attribution automatique des champs est qu au lieu d arriver sur la page de mise à jour de son profil, l utilisateur se verra directement redirigé vers l accueil de l application GRR (l ensemble des données étant rapatriées depuis l annuaire, il ne lui est plus nécessaire de compléter son profil) Connexion à GRR d un utilisateur déjà connu A la base, GRR ne procède à aucun contrôle de cohérence entre les informations de l annuaire LDAP et les informations stockées dans la table des utilisateurs de GRR. Il a été demandé d effectuer un contrôle des champs nom, prénom, et pour vérifier qu ils n ont pas été modifiés. Si ceux-ci ont changé, alors il a été demandé de mettre à jour la table des utilisateurs. Modification de la fonction «grr_opensession» du fichier «include\session.inc.php» : Si l utilisateur est présent dans la base, la fonction a été modifiée pour qu un contrôle de cohérence soit effectué entre les données de la base et celles de l annuaire. Pour cela, une requête SELECT a été effectuée sur les noms, prénoms, et s, pour l utilisateur connecté, et ces champs sont ensuite comparés avec les données réelles de l annuaire. Si une modification est détectée, une requête UPDATE est effectuée pour rétablir la cohérence. Remarque : Les données provenant de cas sont évidemment récupérées de la même manière qu au point précédent, en utilisant la variable $tab_login. Page 7/10

8 1.3. Purge des comptes et des réservations Il a été demandé pour le passage d une année à l autre, que l administrateur puisse effectuer une purge des comptes et des réservations. De plus, une invite de confirmation pour rappeler le caractère important de l opération a été demandée. Conformément à la demande, il a donc été rajouté un élément dans le menu «Utilisateurs et Accès», nommé «Purge des comptes et réservations». Pour cela, les opérations suivantes ont été effectuées : Modification du fichier «admin_col_gauche.php» : Ajout de la nouvelle entrée dans le menu, avec contrôle du niveau de droits requis. Création du fichier «admin_purge_accounts.php» : Création d un formulaire avec texte explicatif de l action, un bouton de validation, et une invite de confirmation javascript. Modification des fichiers de langue (language\lang.fr, language\lang.en, etc) : Ajout des chaines correspondant au titre de l élément de menu et au texte explicatif. Ajout d une fonction dans le fichier personnalisé «include2\fonctionsajoutees.inc.php» : Cette fonction, «supprimerreservationsutilisateursext()», effectue la suppression des utilisateurs de source «ext» et de toutes les dépendances. La fonction effectue les suppressions nécessaires dans les tables suivantes : grr_entry : table des réservations, grr_entry_moderate : table des réservations modérées grr_repeat : table des périodicités pour les réservations grr_j_mail_user_room : table de jointure des utilisateurs à avertir par mails grr_j_user_area : table de jointure des utilisateurs ayant accès aux domaines restreints grr_j_user_room : table de jointure des utilisateurs gestionnaires de ressources grr_j_useradmin_area : table de jointure des utilisateurs administrateurs de domaines. Ajout d une fonction Javascript dans le fichier personnalisé «include2\fonctions.js» : La fonction «confirmpurge()» se charge d afficher une invite de confirmation javascript, proposant à l utilisateur de continuer son action, ou d annuler l opération, en rappelant son caractère important et irréversible. Remarque : Il a été précisé dans la demande qu aucune connexion ne devait exister lors de l exécution de cette opération, ce qui est bien sur indispensable. Or, il faut savoir que GRR possède une fonction permettant d empêcher tout utilisateur de se connecter à l application, mais aussi de déconnecter tous les utilisateurs présents sur l application, en fermant leur session. Les administrateurs ne sont bien entendus pas concernés. L administrateur devra donc utiliser cette fonctionnalité avant de lancer la purge. L accès à cette fonctionnalité de désactivation des connexions utilisateurs se fait de la façon suivante : Page 8/10

9 Dans le menu Général à gauche, suivre le lien Configuration Générale, puis choisir en haut l onglet Sécurité/Connexions, choisir ensuite désactiver les connexions puis cliquer sur Envoyer Modification de l entête de GRR L application étant intégrée au portail, il ne faut donc pas donner à l utilisateur la possibilité de se déconnecter de l application. L application a donc été modifiée afin d ôter cette fonctionnalité, puisqu elle se fera par le portail. Pour cela, l opération suivante a été effectuée : Modification du fichier «include\functions.inc.php» : La fonction «print_header()», en charge de l affichage de l entête de l application, a été modifiée. Les lignes responsables de l affichage du lien de déconnexion ont été mises en commentaires Boutons de connexion/déconnexion originels L application sera à l intérieur du portail, couplée avec CAS, il a donc été demandé de masquer le bouton de connexion des pages dans lesquelles il apparait. De plus, il a été demandé de rediriger tout appel direct à la page «login.php» vers le serveur CAS pour l authentification de l utilisateur. Enfin, conformément à la demande, un mécanisme permettant une connexion directe à GRR, sans passer par CAS, a été mis en place. L utilisation d une variable dans un fichier de configuration, comme préconisé, a été privilégiée. Pour cela, les opérations suivantes ont été effectuées : Modification du fichier «include\functions.inc.php» : Les lignes responsables de l affichage du lien de connexion dans la fonction «print_header» ont été mises en commentaires. Modification du fichier «include\config.inc.php» : Ajout d une variable $sso_block qui pourra être mise à true ou à false par l administrateur, afin de permettre ou non l accès à la page de login classique de GRR lorsque l on accède directement à la page «login.php». Modification du fichier «login.php» : Ajout d un test de la variable «$sso_block», qui redirige l utilisateur sur la page du serveur CAS si la variable est à false, ou qui affiche la page de login propre à GRR dans le cas contraire. Plus précisément, l utilisateur est redirigé sur la page «index.php», et c est ensuite cette page qui se charge d afficher la page de login CAS si l utilisateur n est pas déjà authentifié. Page 9/10

10 1.6. Accès aux paramètres des comptes utilisateurs La page de gestion d un compte utilisateur permet de modifier tous les champs d un compte. Or, puisque les champs sont à présent récupérés depuis l annuaire LDAP (pour les utilisateurs provenant de CAS), il a été demandé d empêcher ces utilisateurs de modifier leurs informations nom, prénom et . Pour cela, les opérations suivantes ont été effectuées : Ajout d une fonction dans le fichier personnalisé «include2\fonctionsajoutees.inc.php» : Cette fonction «IsAllowedToModifyNameFirstNam ()» vérifie si l utilisateur provient ou non d une source externe. Modification du fichier «my_account.php» : Appel de la fonction «IsAllowedToModifyNameFirstNam ()» dans un test, pour afficher les informations de l utilisateur en version modifiable ou non. Page 10/10