Authentification: Rôles Keycloak
La gestion des permissions au sein d'EFR repose sur deux axes :
Un axe transverse, basé sur les rôles Keycloak ;
Un axe spécifique, où chaque module gère ses propres permissions.
Le second axe est autonome par module, et ne nécessite aucune configuration préalable de votre part. En revanche, il faut configurer certains éléments sur la gestion de l’identité, afin d’offrir soit des accès, soit des permissions administrateurs à certains de vos utilisateurs.
Comment configurer Keycloak
Pour la suite de cette documentation, vous êtes invités à prendre en compte les articles suivants :
Rôles requis, par module
Dans le tableau ci-dessous, les rôles en verts sont ceux posant peu de risques. En orange, il s’agit de rôles pouvant avoir un impact important. En rouge, sont ceux dont l’accès doit être très limité.
Module | Lecture | Écriture |
|---|---|---|
Cartographie * |
|
|
Propriétés |
|
|
Tables dynamiques |
|
|
Rejeu |
|
|
Tests de non-régression |
|
|
Déchiffrement *** |
| / |
Notifications globales (sans IHM) | / |
|
Il faut noter que la portée “écriture” est en réalité très large, et sous entend “toute action modifiant un état”.
Par exemple, sur le module de rejeu, la permission d'écriture permet aussi de déclencher un rejeu.
(*) Le module de cartographie est partagé entre deux IHM (cartography et reporting), et entre 3 API (applications, business, mediations).
(**) La permission efr_tables_admin n’est à confier qu’aux administrateurs. En effet, ce module a son propre système de permissions auto-porté.
Voir l’article Gestion des permissions dans le module de Tables Dynamiques pour plus d'informations.
(***) Le déchiffrement concerne aussi bien le déchiffrement des traces que des propriétés.
La cartographie est utilisée par tous les modules de EFR.
Le droit efr_carto_access est donc nécessaire pour TOUS les utilisateurs.
Actions globales
Pour plus aisément donner les accès aux modules à vos utilisateurs, vous pouvez donner le rôle à tout le monde par défaut.
Configurer un rôle avec un Identity Provider externe
Dans le cas d’un AD par exemple, vous pouvez ajouter un rôle mapper offrant un rôle hardcodé.
Dans la vue Mapper de votre Identity Provider, voici un exemple de rôle donné par défaut :
Ce contenu est soumis au droit à Copyright. Il ne doit pas être utilisé sans accord de la société Middleware Editions.