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.

.. glossary::

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

.. glossary::
    profil
        Un profil est donc un couple clé, valeur. Ce couple est renvoyé au moment de l'identification d'un utilisateur.
        Un profil permet d'associer des permissions via des rôles. Un utilisateur peut avoir plusieurs profils.
        Un profil professeur sera par exemple employeetype=professeur, mais il peut être en même temps professeur
        administrateur de classe si il a un typeadmin de valeur 2::

            [employeetype]
            professeur=prof

            [typeadmin]
            2=prof_admin



