ajout des specifications des cas d'usage

report/draft_report002.md

@@ -60,6 +60,84 @@ Paul Marillonnet
 
 ### Description des cas d'usage
 
+* Première partie : description de l'existant
+=============================================
+
+Nous étudierons ici une architecture logicielle telle qu'il est possible d'en trouver au sein d'une entreprise de structure standard.
+
+Plusieurs référentiels d'identités sont présents au sein de l'entreprise, utilisé par les différents services métier.
+
+Ainsi, les Ressources Humaines stockent les données d'identités des employés à l'aide d'un système de gestion de base de données relationnelle (SGBDR ou *RDBMS*).
+
+Un annuaire de type Active Directory (implémentation LDAP propriétaire Microsoft) est mis en place pour différents usages. Il sert à l'authentification des employés à leurs postes client, mais aussi à la vérification des permissions pour le montage d'un système de fichier réseau (partition NFS).
+
+Un serveur de mail (Microsoft Exchange) rassemble aussi les boîtes email des utilisateurs, et un serveur PABX est chargé des la commutation des numéros de téléphone internes attribués à chacun des employés.
+
+Finalement, un serveur d'impression dispose de données utilisateurs pour la gestion des quotas et des permissions d'accès aux imprimantes de l'entreprise.
+
+
+* Deuxième partie : approche fonctionnelle
+==========================================
+
+Deux documents pour la description fonctionnelle.
+
+**`arch06.odg` est le schéma d'architecture fonctionnelle désirée pour le cas d'usage.**
+
+**`sequence05.dia` est le diagramme de flux de la procédure d'approvisionnement et de synchronsation.**
+
+L'approvisionnement d'utilisateur étudié ici sera celui dans le backoffice, destiné aux agents de l'entreprise. Il ne s'agit donc pas d'une base des clients, seulement des employés.
+Différents éléments et briques logicielles sont à prendre en compte dans le cas de ce scénario :
+- La gestion de la base RH
+- Cette gestion implique une création dans l'AD
+- La mise en place de l'annuaire AD permet la connexion de l'employé à son poste client
+- De même l'AD permet l'accès à un système de fichiers partagé (par exemple, de type NFS)
+- La création d'un compte email (par exemple un serveur IMAP ou SMTP)
+- L'accès aux serveurs d'impression (CUPS)
+
+La problématique de l'approvisionnement comporte certains obstacles techniques.
+Ainsi, on ne sait pas à quel(s) groupe(s) appartient l'employé lorsqu'il est ajouté dans l'annuaire Active Directory.
+Après ajout dans l'AD, une intervention humaine est requise pour placer le nouveau profil dans les groupes adéquats.
+Cette intervention sera effectuée par un.e administrateur/administratrice AD, averti.e par courriel de la création d'un nouveau compte.
+
+Le workflow comprendra aussi création la création du profil dans le serveur PABX (téléphonie privée).
+Les mêmes problèmes surviennent alors : on ne sait pas à l'avance dans quel bureau se situe l'employé dont on crée le compte.
+L'action d'ajout dans le PABX sera alors associée elle aussi à une intervention humaine, qui consistera simplement à demander à l'administrateur téléphonie le numéro de téléphone associé au compte.
+
+Le cas d'usage sera complété par le déploiement d'une plateforme Publik, et le compte créé sera aussi provisionné dans l'IDP Authentic de la plateforme.
+Comme précédemment, la notification se fait par envoi d'un email, destiné à l'administrateur Publik, afin d'avertir ce dernier de la création d'un compte
+
+Il faudra déterminer si l'ensemble des actions décrites ci-dessus peut être formalisé dans un unique *workflow*.
+Au sein du ou des *workflows*, il faudra alors ordonner les différentes actions entre elles.
+Nous pouvons d'ores et déjà ordonnancer certaines des étapes du workflow : il faut d'abord renseigner l'adresse email du nouveau compte dans le méta-annuaire.
+La procédure de création sera ensuite complétée par un ajout dans la base Exchange (outil de messagerie Microsoft).
+Il faudra par la suite mentionner l'adresse email dans la plateforme Publik. On viendra aussi modifier la base RH pour préciser l'adresse email créée.
+
+Par ailleurs, le numéro de téléphone est provisionné dans Exchange, ainsi que dans la base RH et dans Publik. Il faudra déterminer si l'approvisionnement de ces différentes données utilisateur peut être effectué dans le même *workflow*.
+
+Dans un second temps, nous abordons le cas où l'utilisateur demanderait à changer de nom d'usage. Le changement de nom doit être initié dans la base RH, car c'est elle qui centralise les données d'identité.
+Une notification à l'administrateur concernant le changement est envoyée par email.
+Il ne s'agit pas d'un changement complet dans la base RH, seulement de l'ajout d'un alias pour toutes les données impactées par la demande de changement (nom, email, username, _etc_). L'utilisateur restera ainsi joignable sous ses anciennes données d'identité.
+
+Un dernier cas d'usage sera aussi pris en compte afin de venir compléter cette étude.
+Dans ce cas d'usage, le point de départ est l'ajout d'une entrée utilisateur dans l'annuaire de messagerie. Qu'il s'agisse ou non d'un système de règles dans l'annuaire de messagerie, le meta-annuaire de synchronisation doit être en mesure d'aller pousser l'adresse dans la RH.
+
+
+* Troisième partie : problématiques techniques
+==============================================
+
+Adoptons maintenant un point de vue plus technique pour l'élaboration de ce scenario d'utilisation.
+Des mécanismes de duplication sont mis en place dans l'infrastructure de gestion des identités. La base Active Directory est ainsi répliquée vers un annuaire OpenLDAP. Sur cet annuaire s'exécute une application Web de type 'Pages blanches'.
+L'interconnexion entre les deux annuaires est réalisée à l'aide de LSC (*LDAP Synchronization Connector*).
+
+Les modifications de la base RH étant à l'origine de la plupart des procédures de synchronisation, nous devons aussi déterminer la façon dont sont détectées ces modifications. La base de données RH est implementée en SQL, par exemple postgreSQL.
+
+On implémentera donc un script python, chargé de détecter ou de surveiller les changements dans la base. Ce script rendra compte des événements d'ajout, de modification ou de suppression d'entrées dans la table des profils (les événements remontés seront du type "Création de UserA", "Modification de UserB", "Suppression de UserC"). Ce script s'exécutera en tâche de fond (processus de type _daemon_), surveillant les changements apportés à la base.
+
+On placera le même type de daemon pour surveiller les éventuels changements apportés par les agents à l'annuaire de téléphonie.
+On rappelle que la notion de *workflow* implique nécessairement des actions humaines. Les demandes d'intervention d'agents seront prises en charge pour l'outil w.c.s.
+L'application w.c.s devra alors implémenter un connecteur LDAP, afin de s'interfacer avec l'AD et l'annuaire de téléphonie.
+On ajoutera à cela un connecteur vers l'API d'Authentic 2 (l'interface actuelle de w.c.s. avec A2 étant pour l'instant incomplète).
+
 ### Démonstrateur avec LSC (*LDAP Synchronization Connector*)
 
 ### Analyse de la couverture du besoin avec les outils Entr’ouvert