retrait spec en doublon

doc.md

@@ -1394,71 +1394,6 @@ bibliographie (titre, source, date, auteurs)
 extrait de code source (il faut que ce soit pertinent, ou URLs vers un dépot public)
 diagramme et schémas ? Non dans les corps de chap
 
-description détaillée LDAP, Kerberos
-===============
-
-Mikaël : plusieurs scenarii pourraient être étudiés ici
-Le changement d'adresse ne constitue pas un exemple suffisamment complet car seule la base RH est modifiée, il n'y a donc pas de synchronisation en tant que telle.
-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.
-
-Mik me conseille d'aller voir la doc concernant le champ Sub de OIDC.
-Nous insistons sur la restriction du cas d'utilisation. On s'occupe ici seulement des agents, pas des employés (ces derniers ne faisant pas partie des acteurs du *workflow*).
-
-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.
-
-Qu'en est-il du numéro de téléphone ?
-On le provisionne 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é.
-
-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'interconnection 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).
-
-Un second 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.
-
-Enfin, un troisième cas d'usage reste à définir. Il devra en tout cas cerner la problématique la remontée de la modification d'un numéro.
-
-=======
-
-
-
 ### Exemple "haut-niveau"
 //TODO doc commerciale des concurrents
 Cas d'usage pour la doc fonctionnelle
@@ -1540,7 +1475,6 @@ Ils sont au total au nombre de quatre, c'est-à-dire les diagrammes :
 - prévisionnel mi-parcours, réalisé à la moitié de la durée du projet
 - final. C'est planning réel une fois le projet réalisé.
 
-# Entr'ouvert
 # Ecriture d'un connecteur Passerelle
 La création d'un nouveau connecteur doit d'abord être précédée d'une phase de lecture du code de Passerelle, afin de comprendre la structuration des connecteurs fournis par l'application.