Chargement d’un rôle

Un rôle permet de gérer les autorisations d’accès dans l’Ead2. Lorsqu’un utilisateur se connecte, on va récupérer les informations le concernant, lui attribuer un rôle et donc lui donner accès aux actions associées à ce rôle.

rôle

Un rôle est un couple nom-libellé. Il permet de lier un ensemble de permission à un profil utilisateur. Le rôle admin est le rôle d’administrateur du serveur Un rôle:

[role]
admin=administrateur d'un serveur
permission

Une permission est une association entre un rôle et le nom d’une action qui permet à un utilisateur ayant le rôle ‘rôle’ d’accéder à l’action. L’administateur définit plus haut à accès à l’action ‘status’. Une permission:

[permission]
status=admin

Dans le fichier ead2/backend/lib/eadserver.py, la classe Amon (c’est historique) sert de serveur xmlrpc. C’est dans cette classe que l’on charge les roles dans un role_manager par le biais d’un parse_and_update_roles, que l’on applique à tous les fichiers de rôles disponibles:

parse_and_update_roles(self.role_manager, join(CONFIG_DIR, 'roles.ini'))
parse_and_update_roles(self.role_manager, join(CONFIG_DIR, 'roles_%s.ini' % module_name))
for niveau_gestion in ['local', 'acad']:
    parse_and_update_roles(self.role_manager, join(CONFIG_DIR, 'roles_%s.ini' % niveau_gestion))

Note

pour l’instant quatre fichiers de rôle sont utilisés:

  1. roles.ini
  2. roles_nomdumodule.ini
  3. roles_local.ini
  4. roles_acad.ini

Les deux derniers sont personnalisables, roles_local.ini l’est depuis l’interface.

Chargement des permissions

La class Amon charge également les permissions. Le chargement se fait sur le même schéma, avec une fonction parse_and_update.

Note

de la même manière que pour les rôles, quatre fichiers de permissions sont utilisés:

  1. perm.ini
  2. perm_nomdumodule.ini
  3. perm_local.ini
  4. perm_acad.ini

Les deux derniers sont personnalisables, perm_local.ini l’est depuis l’interface.

Les profils

  • Cas 1: Dans le cas d’une identification Sso, lorsqu’un utilisateur se connecte, le serveur d’identification Sso renvoie des données de profil, outre l’uid, ses groupes ldap, son ‘typeadmin’, son ‘employeetype’... Selon l’annuaire auquel on se connecte (Scribe, Horus), ces informations ont des significations différentes.
  • Cas 2: Utilisateur système. La seul manière de profiler un utilisateur système est de considérer son login. Dans la gestion des profils le login système est identifié par la clé ‘pam’.

Table des matières

Sujet précédent

Le templating dans l’Ead2

Sujet suivant

Les outils du serveur de commande

Cette page