État et cycle de vie
Périmètre et objectifs
Différents types d'objets de l'annuaire, tels que ceux figurant dans la branche ou=people, peuvent avoir plusieurs états. Chaque état matérialise une “étape” dans le cycle de vie de l'objet, en fonction d'éléments liés à ce qu'il est censé représenter.
Pour une personne, seront par exemple pris en compte son statut dans l'établissement, qu'il soit futur, présent ou passé, le fait qu'elle ait ou non “pris possession” de son compte informatique, ou qu'elle soit l'objet de restrictions, pour raisons disciplinaires ou autres.
A chaque état peut être associé, le cas échéant, des dates de début et de fin de validité, effectives ou prévisionnelles.
De même, des états et des dates de validité peuvent être définis pour des ressources associées à l'objet, pouvant avoir des cycles de vie différents : par exemple le fait de bénéficier d'une boîte mail, d'un accès à l'ENT, etc.
SupAnn définit des nomenclatures, des attributs et une classe d'objet permettant d’assurer le suivi de ces états.
Les objectifs sont les suivants :
- permettre au système d'annuaire, ou aux applications sous-jacentes, de contrôler la visibilité de l'objet ou de certains de ses attributs selon son état : présence dans l'annuaire « pages blanches », accessibilité via le protocole LDAP ou la fédération,… ;
- permettre aux mécanismes d'authentification et d'autorisation des personnes ou des applications d'adapter leur comportement en fonction de l'état du compte ou de la ressource ;
- permettre aux mécanismes de synchronisation et de notification internes de réaliser les opérations techniques nécessaires lors des différentes étapes du cycle de vie de l'objet ou des ressources associées ;
- permettre aux applications s’appuyant sur l’annuaire de connaître l’état du compte et d’avoir un comportement adapté en fonction de cette information ;
- permettre aux applications s’appuyant sur l’annuaire ou sur la fédération d'adapter leur stratégie de conservation des données en fonction des dates de validité de l'état.
Représentation de l’information
SupAnn définit les éléments suivants:
- une nomenclature pour codifier la ressource à laquelle se rapporte un état: l'entrée LDAP elle-même (qui dans le cas d'une personne, représente le compte qui lui est attribué), ou une de ses ressources associées ;
- deux nomenclatures pour codifier les états de manière hiérarchique :
- un état, qui ne peut avoir que trois valeurs: actif, inactif ou suspendu ;
- un sous-état, facultatif, permettant d'affiner la notion d'état en fonction des traitements souhaités ;
- deux attributs pour stocker ces informations :
- supannRessourceEtat, combinant la ressource et son état courant ;
- supannRessourceEtatDate, combinant ressource, état, et dates de validité.
- Une classe d'objet auxiliaire, supannRessource, permettant d'affecter ces deux attributs aux différentes catégories d'objet de l'annuaire (nouveauté SupAnn 2021).
La plupart des objets définis par SupAnn sont éligibles à cette modélisation du cycle de vie :
- les personnes (branche ou=people),
- les groupes de personnes (branche ou=groups),
- les entités et structures (branche ou=structures),
- les applications (branche ou=applications).
NOTE : pour des raisons historiques, les attributs supannRessourceEtat et supannRessourceEtatDate sont déjà déclarés dans la classe supannPerson. Il n'est donc pas nécessaire de faire appel à la classe auxiliaire supannRessource pour les objets de la branche ou=people, contrairement aux autres catégories.
Nomenclatures
Ressource
La nomenclature des ressources est utilisée pour l'étiquette (cf. Les attributs étiquetés) des attributs supannRessourceEtat et supannRessourceEtatDate.
SUPANN définit les valeurs suivantes:
Étiquette | Ressource concernée |
---|---|
{COMPTE} | l'objet LDAP lui-même : le compte de l'utilisateur ou de l'application, le groupe ou la structure représentés |
{MAIL} | la boîte de messagerie électronique attribuée à l'objet : la boîte individuelle de la personne, celle réservée aux membres du groupe… |
Cette nomenclature est semi-ouverte: l'établissement peut étendre cette liste avec des valeurs pour ses usages propres. Voir: Espace de nommage des étiquettes.
État
État | Description |
---|---|
A | actif : la ressource ou le compte est opérationnel |
I | inactif : la ressource ou le compte existe, mais n'est pas opérationnel |
S | suspendu : la ressource ou le compte est opérationnel, mais l'utilisateur n'y a pas accès |
- L'état inactif englobe tous les cas où une ressource existe sans être active: par exemple, un compte ou une boîte mail créée par anticipation, mais n'ayant pas encore été activé; ou un compte qui a expiré depuis peu, mais n'a pas encore été supprimé. Le sous-état permet de différencier ces cas de figure. Lorsqu'une ressource est inactive, le service qu'elle est censée assurer n'est pas rendu : par exemple, une boîte mail n'acceptera pas de courrier entrant.
- L'état suspendu correspond aux cas où l'usage d'un compte ou d'une ressource active est délibérément bloqué, en général de manière indépendante de son cycle de vie « naturel » ; par exemple à la suite d'un usage abusif, d'une intrusion ou d'une sanction disciplinaire. Le sous-état précise le motif de la suspension. Le service continue d'être assuré comme si la ressource était active (exemple: la réception de mail est possible), mais l'accès est refusé à l'utilisateur. Il s'agit en général d'un état appliqué temporairement pour pallier un problème.
Cette nomenclature est fermée.
Sous-état
SUPANN définit les valeurs suivantes :
Sous-état | Description | État principal associé |
---|---|---|
États du cycle de vie naturel du compte, dans l'ordre d'échéance: | ||
SupannPrecree | Compte créé par anticipation, mais qui n'est pas encore opérationnel | I |
SupannCree | Compte opérationnel, mais dont l'utilisateur n'a pas encore pris possession | I |
SupannAnticipe | Compte opérationnel et accédé par l'utilisateur, en anticipation de sa date de début d'activité | A |
SupannActif | Compte opérationnel et accédé par l'utilisateur en activité régulière | A |
SupannSursis | Compte opérationnel et accédé par l'utilisateur, en sursis après sa date de fin d'activité | A |
SupannExpire | Compte qui n'est plus opérationnel, la date de fin d'activité et le sursis éventuel étant dépassés, mais dont les échéances de suppression ne sont pas encore atteintes | I |
SupannInactif | Compte non opérationnel (sans en préciser la raison) dont les échéances de suppression ne sont pas encore atteintes | I |
SupannSupprDonnees | Compte expiré ayant atteint l'échéance de suppression des données | I |
SupannSupprCompte | Compte expiré en instance de suppression définitive | I |
États de verrouillage pouvant intervenir à différents stades du cycle: | ||
SupannVerrouille | Compte verrouillé (sans en préciser la raison) | S ou I en fonction de la politique de l'établissement |
SupannVerrouAdministratif | Compte verrouillé pour une raison administrative (suspension de compte, abus de charte…) | S ou I en fonction de la politique de l'établissement |
SupannVerrouTechnique | Compte verrouillé pour une raison technique (détection d'homonyme, suspicion de compte piraté…) | S ou I en fonction de la politique de l'établissement |
Cette nomenclature est semi-ouverte: chaque établissement est libre d'utiliser des valeurs personnalisées préfixées différemment. Les valeurs personnalisées ne doivent pas débuter par “Supann”, ne doivent pas contenir de “:” et ne doivent pas être constituées uniquement de chiffres.
La pratique recommandée par SupAnn pour préfixer les sous-états locaux est d'utiliser un domaine représentatif de l'établissement enregistré dans le DNS en .fr, sans le .fr.
Exemple :
Si l'établissement “Université Exemple” est propriétaire des domaines DNS univ-exemple.fr, u-ex.fr et example-university.eu, elle DEVRAIT utiliser le préfixe “univ-exemple” ou “u-ex”, mais pas “example-university”.
Les valeurs personnalisées sont destinées à un usage local uniquement.
Si des nouvelles valeurs de sous-états doivent être partagées entre plusieurs établissements ou revêtent un intérêt commun, celles-ci peut être proposée au groupe de travail SUPANN pour normalisation : voir Évolution des recommandations.
Diagramme séquentiel des sous-états
Attributs
supannRessourceEtat indique l'état courant, et optionnellement son sous-état, pour une ressource donnée. L'identifiant de la ressource est indiqué sous forme d'étiquette. La syntaxe est de la forme:
{RESSOURCE}État[:SousÉtat]
Il peut être nécessaire, en fonction des ressources qui viennent chercher l’information de l’annuaire, de doubler l’information: une valeur contenant l'état seul, et une valeur contenant l'état et son sous-état associé.
{COMPTE}A {COMPTE}A:SupannSursis {COMPTE}I {COMPTE}S:SupannVerrouTechnique
supannRessourceEtatDate contient les mêmes informations plus, éventuellement, celles relatives aux dates de début et de fin dans l’état :
{RESSOURCE}État:[SousÉtat]:[DateDébut]:[DateFin]
Les informations de sous-état, de date de début et de date de fin sont facultatives. Le format de la date est de type AAAAMMJJ.
NOTE : cet attribut n'est pas limité à l'état courant. Il peut également contenir des valeurs correspondant à des états passés ou futurs, dans la mesure où aucun recouvrement de plage de validité n'existe entre des états contradictoires pour la même ressource.
Compte actif sans information complémentaire
{COMPTE}A:::
Compte actif en période de sursis avec date de début et de fin du sursis
{COMPTE}A:SupannSursis:20170912:20171212
Compte actif avec date de début, mais sans date de fin connue
{COMPTE}A::20170825:
Compte actif en activité régulière, date de début non spécifiée, mais avec date de fin connue
{COMPTE}A:SupannActif::20171231
Exploitation
Contrôle de la visibilité et de l’authentification au niveau de l’annuaire
OpenLDAP, ainsi que d’autres services d’annuaires, permet de limiter la visibilité d’un objet et sa capacité d’authentification selon la valeur d'un ou plusieurs de ses attributs.
L'exemple de configuration suivant montre comment utiliser le supannRessourceEtat pour contrôler la visibilité des objets dans OpenLDAP, à l’aide d’ACLs de type filter.
- slapd.conf
# exceptions: pas de restrictions pour administrateurs, applications... access to * by group="cn=acl.dit.admin,ou=applicationGroups,dc=univ-x,dc=fr" write by group="cn=acl.dit.read,ou=applicationGroups,dc=univ-x,dc=fr" read by * break # aucun accès aux comptes inactifs access to filter="(supannRessourceEtat={COMPTE}I*)" by * none # pas d'authentification pour les comptes suspendus access to filter="(supannRessourceEtat={COMPTE}S*)" attrs=userPassword by * none # sinon: authentification sur userPassword access to attrs=userPassword by self write by anonymous auth by * none # et lecture de tout le reste access to * by * read