Les paragraphes suivants regroupent par «profil» les listes d'attributs utilisables pour décrire une personne :

• Le tronc commun: contient les attributs qui peuvent/doivent être présents dans toutes les entrées de personnes quel qu'en soient les profils;
• Le profil "Personne ressource": donne la liste des attributs relatifs aux “personnes ressources” (enseignants, chercheurs, personnels administratifs et techniques, etc);
• Le profil "Apprenant": précise les attributs propres aux apprenants (étudiants, élèves, stagiaires en formation…);
• Le profil "Externe": précise les attributs applicables aux personnes non-membres de l'établissement (invités, prestataires, membres externes de jury, visiteurs, lecteurs de bibliothèques, etc).

On entend par profil multiple les cas où :

• une personne a plusieurs statuts (par exemple enseignant et étudiant) ;
• un personnel a plusieurs rôles ou fonctions (par exemple responsable d’UFR, responsable d’une maîtrise) ;
• un étudiant prépare plusieurs diplômes ;
• un étudiant suit une formation en relation avec plusieurs disciplines (par exemple en math et physique) ;
• un personnel est affecté à plusieurs structures.

Problème : dès qu'une personne a plusieurs profils, il y a risque de perdre l'association entre des informations corrélées. Par exemple, le diplôme, et le niveau dans le diplôme, s'ils sont stockés dans des attributs distincts. Ce problème est lié à la nature non relationnelle d'un annuaire LDAP.

Plusieurs solutions techniques ont été envisagées par le groupe de travail SupAnn pour parer à cette perte d'information :

• attribut composite : regrouper les informations liées dans un seul attribut dont le contenu devient structuré. Par exemple : ”<rôle>|<structure>” (ex. “directeur|UFR de maths”) ou ”<rôle>|<DN>” (ex. “directeur|ou=12345,o=98765,dc=univ-truc,dc=fr”) ou ”<diplôme>|<discipline>|<étape>”. Avantage : information accessible en une seule recherche. Inconvénient : les applications doivent savoir “décortiquer” cet attribut.
• pointer vers des objets (situés ailleurs dans l'annuaire) décrivant le “profil” correspondant. Exemple : un objet “formation” contenant au moins les trois informations diplôme, discipline et étape. Cet objet est instancié autant de fois qu'il y a d'instances de formations dans l'établissement. Avantage : cela peut rejoindre un autre besoin (description des formations dans l'annuaire). Inconvénient : recherches indirectes (pour rechercher les étudiants en biologie il faut repérer tous les objets formation dont la discipline est biologie puis rechercher les personnes ayant un pointeur sur ces objets).
• croiser plusieurs informations contenues dans l'annuaire. Exemple : croiser l'information “rôle” d'une personne avec le contenu de la branche des structures pour savoir de quelle entité elle est directeur par exemple.
• solution hybride : les informations sont à la fois inscrites dans des attributs séparés et regroupées dans un attribut spécifique composite. Inconvénient : il faut veiller à la cohérence entre les attributs.
• utilisation de groupes : à chaque profil correspond un groupe auquel appartiennent les personnes ayant ce profil.
• utilisation d'alias remontant des structures vers les personnes : des objets alias dans les feuilles de la branche des structures, des inscriptions des étudiants, des inscriptions des personnes dans les applications de gestion, etc… pointent sur les entrées de personnes appartenant à l'entité avec des attributs associés à l'alias décrivant la fonction.
• pointeurs vers les entrées de personnes depuis une branche contenant la description des formations ou des fonctions.

Le groupe de travail a retenu la solution des attributs composites. Les attributs de ce type regroupent les valeurs de plusieurs attributs, dans un ordre défini, séparées par une séquence spécifique. Voir : Les attributs composites.