Fonctionnement

Un base de compte 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 dee 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 transaction la validation des modification ou l'annulation (pour certaines base ces fonctions n'ont pas d'action mais doivent être appelés).

Contenu

Objets

Les bases sont composés de plusieurs type 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 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 dans toutes les type 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 type 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 lu/é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é dynamiquement par le code (ces attributs sont souvent en lecture seule cf LATMOS::Account::Bases)

Rien ne garanti 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 fourni déjà des noms unique avec une signification documentée de chaque attribut, réutiliser ces noms évite de dupliquer un travail lourd déjà largement éprouvé.

Permissions

(Ce paragraphe ne concerne pas les ACLs utilisateurs).

Chaque attributs 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 disponible 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, voir 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 fourni une fonction spécifique pour saisir le mot de passe à partir de sa valeur non chiffrée.

Convention

Objets courants

Objets	Description	identifiant unique	nom ldap de l'id
User	utilisateurs	login	uid / cn
Group	groupe d'utilisateur	groupname	cn