wiki:LATMOS::Account::Bases

Fonctionnement

Une base de comptes représente une méthode d'accès générique à un quelconques moyen de stocker des informations.

L'accès à une base suit toujours le schéma suivant:

  1. instanciation: incluant le passage des paramètres nécessaires dont le type de la base. Ce type permettra de charger le code spécifique d'accès à cette base (Ad, Unix, ...)
  2. chargement (load): entrainant soit la lecture des données, soit la connection à la base
  3. Accès ou modification des informations
  4. commit ou rollback assurant dans le cas des bases supportant des transactions la validation des modifications ou l'annulation (pour certaines bases ces fonctions n'ont pas d'action mais doivent être appeléss).

Contenu

Objets

Les bases sont composéss de plusieurs types d'objets, chaque objet représente un élément indissociable dans la base.

Les objets sont composés:

  • d'un type intrinsèque (user, group, ...)
  • d'un identifiant unique (id)
  • d'attributs

Chaque base est en mesure d'annoncer les types d'objet qu'elle est capable de gérer, cette liste peut dans certains cas être vide et aucun type d'objet n'a obligation d'exister dans tous les types de bases.

Il est possible de récupérer la liste des identifiants uniques par type d'objet, cet identifiant n'est pas unique dans la base, en revanche il ne peut apparaître pour plusieurs objets de même type.

L'accès à un objet se fait donc en précisant à la fois le type d'objet voulu et son identifiant.

Attributs

Les attributs supportés dépendent évidement de la base accédée. De même que pour les types d'objet, cette liste est fournie par la base par type d'objet et il n'y a aucune garantie que cette liste ne soit pas vide.

Fonctionnement des attributs

On distinguera deux types d'attributs:

  • les attributs simple dont la valeur est lue/écrite directement dans/à partir de la base (exemple: le nom de famille 'sn')
  • les attributs générés à partir d'autres attributs: certains attributs ne sont qu'une répétition d'un autre ou simplement une autre manière de présenter la même information, dans un tel cas la valeur de l'attribut est générée dynamiquement par le code (ces attributs sont souvent en lecture seule cf Permissions)

Rien ne garantit qu'un attribut doivent exister pour un type d'objet donné, en revanche la sous base accédée peut imposer l'existence de tel ou tel attribut, de son format ou encore une unicité.

Nom des attributs

Par convention et dans la mesure du possible les attributs portent le nom de leurs équivalents LDAP. En effet ldap fournit déjà des noms uniques avec une signification documentée de chaque attribut, réutiliser ces noms évite de dupliquer un travail lourd déjà largement éprouvé.

Une liste exhaustive des attributs et de leurs dépendances se trouve ici.

Permissions

(Ce paragraphe ne concerne pas les ACLs utilisateurs).

Chaque attribut présent dans une base est accessible soit en lecture, soit en écriture, soit les deux.

Tout les attributs sont normalement accessible en lecture, en revanche nombre d'attributs ne sont pas disponibles en écriture, en voici les raisons:

  • la base de donnée sous-jacente en interdit l'écriture
  • l'attribut est généré à partir d'un ou plusieurs autres attributs, voire d'autres objets dans la base (dans ce cas il faut modifier ces derniers)
  • le code pour le gérer serait complexe et sans utilité
  • on ne veut pas modifier cet attribut, juste pouvoir le lire (interdiction artificielle)

Cas spécifique des attributs de mot de passe

Le mot de passe constitue toujours un problème dès qu'on parle d'interopérabilité. Aucune base de compte n'aborde le problème de la manière interdisant les échanges de sa valeur.

Bien que les attributs de mot de passe soit parfois gérés, chaque base fournit une fonction spécifique pour saisir le mot de passe à partir de sa valeur non chiffrée.

Échange d'information entre bases

La synchronisation peut se faire entre n'importe quelle base. Elle est basée sur la concordance entre les deux bases des:

  • types d'objets
  • identifiants d'objets
  • attributs supportés

Les types d'objets et attributs non supportés par la base de départ ou d'arrivée sont ignorés.

La synchronisation fonctionne ainsi:

  1. listing des types d'objets
  2. Pour chaque type d'objets en commun
    1. listing des objets
    2. Effacement des objets inexistants
    3. création des nouveaux objets
    4. surcharge des attributs des objets en commun
  3. commit
  4. exécution du script de post-synchronisation (si besoin)

Convention

Objets courants

Objets Description identifiant unique nom ldap de l'id
User utilisateurs login uid / cn
Group groupe d'utilisateur groupname cn
Last modified 15 years ago Last modified on 09/28/09 13:21:40