État et cycle de vie

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.

SupAnn définit les éléments suivants:

  1. 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 ;
  2. deux nomenclatures pour codifier les états de manière hiérarchique :
    1. un état, qui ne peut avoir que trois valeurs: actif, inactif ou suspendu ;
    2. un sous-état, facultatif, permettant d'affiner la notion d'état en fonction des traitements souhaités ;
  3. deux attributs pour stocker ces informations :
    1. supannRessourceEtat, combinant la ressource et son état courant ;
    2. supannRessourceEtatDate, combinant ressource, état, et dates de validité.
  4. 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 :

  1. les personnes (branche ou=people),
  2. les groupes de personnes (branche ou=groups),
  3. les entités et structures (branche ou=structures),
  4. 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.

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 :

Aucune des valeurs de sous-états n'est obligatoire; chaque établissement peut choisir la granularité qui lui convient en ne retenant que le sous-ensemble de valeurs correspondant à son modèle de gestion. En revanche, il est demandé de ne pas dévoyer les valeurs de leur usage prévu.
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.

Ce diagramme est un exemple de mise en œuvre destiné à illustrer l'enchaînement logique des sous-états. Selon sa logique métier, chaque établissement peut choisir de “sauter” ou d'ignorer certains états, ou prévoir des transitions supplémentaires (par exemple: un retour de supannSupprDonnees à supannCree en cas de “résurrection” d'un compte ancien).

Diagramme des états

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é.

Exemples :
{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.

Exemples :
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

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.

Cet exemple est une illustration minimaliste à adapter selon la politique d'accès et le contexte de l'établissement. Il n'est notamment pas tenu compte ici des différents niveaux de visibilité des attributs ou des branches, ni des méthodes d'authentification autres que celles basées sur le userPassword.
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
  • Dernière modification : 2021/12/03 09:58