You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Les rôles plateforme pilotent les permissions globales de la Console (scope Console). Ils sont distincts des rôles projet, qui ne s’appliquent qu’à un projet.
4
+
5
+
Si un utilisateur est associé à plusieurs rôles plateforme, ses permissions sont cumulées : il obtient l’ensemble des permissions de tous ses rôles.
6
+
7
+
Certains rôles plateforme sont préconfigurés (rôles “système”) et sont en lecture seule : leurs permissions, leur type et leur groupe OIDC ne sont pas modifiables depuis l’interface. La gestion des membres reste possible.
8
+
9
+
## Accéder à la gestion des rôles
10
+
11
+
Chemin : `Administration` → `Rôles`.
12
+
13
+
14
+
15
+
## Paramétrer un rôle
16
+
17
+
L’onglet `Général` permet de :
18
+
19
+
- nommer le rôle ;
20
+
- choisir ses permissions (globales) ;
21
+
- définir le type ;
22
+
- associer le groupe OIDC.
23
+
24
+
25
+
26
+
## Gérer les membres d’un rôle
27
+
28
+
L’onglet `Membres` permet d’ajouter ou retirer des utilisateurs.
29
+
30
+
31
+
32
+
## Effet sur GitLab
33
+
34
+
Selon l’intégration et le niveau de synchronisation, l’affectation à un rôle plateforme se traduit par des droits visibles côté GitLab (ex. via l’appartenance à des groupes synchronisés).
35
+
36
+
Copy file name to clipboardExpand all lines: docs/administration/utilisateurs.md
+5-1Lines changed: 5 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,6 +1,6 @@
1
1
# Utilisateurs
2
2
3
-
Dans le menu Administration > Utilisateurs il est possible de retrouver tous les utilisateurs inscrits sur la plateforme, ainsi que leur statut (utilisateur simple ou administrateur).
3
+
Dans le menu `Administration` → `Utilisateurs`, il est possible de retrouver tous les utilisateurs inscrits sur la plateforme, ainsi que des informations d’administration associées.
4
4
5
5
> La création et la suppresion des utilisateurs est à faire directement dans keycloak.
6
6
@@ -18,3 +18,7 @@ Une fonction de recherche est disponible sur les champs suivants:
18
18
## Devenir administrateur
19
19
20
20
En cochant la case **Administrateur**, la personne choisie devient administrateur de la console DSO.
21
+
22
+
Selon la configuration, les permissions globales peuvent aussi être gérées via les rôles plateforme (recommandé).
Chemin : sélectionner un projet → onglets `Équipe` / `Rôles`.
11
10
12
-
La page Rôles présente la liste des rôles du projet :
11
+
12
+
13
+
## Consulter qui a quoi (onglet Équipe)
14
+
15
+
L’onglet `Équipe` affiche les membres du projet et les rôles qui leur sont associés.
16
+
17
+
18
+
19
+
La capture ci-dessus illustre un exemple avec un utilisateur de test.
20
+
21
+
## Gérer les rôles (onglet Rôles)
22
+
23
+
L’onglet `Rôles` présente la liste des rôles du projet.
13
24
14
25
15
26
16
-
Par défaut le rôle `Tout le monde` regroupe tous les membres de l'équipe avec les permissions suivantes :
27
+
Par défaut, le rôle `Tout le monde` regroupe tous les membres de l'équipe avec les permissions suivantes :
17
28
18
29
- Reprovisionner le projet
19
30
- Voir les environnements
20
31
- Voir les dépôts
21
32
22
-
## Créer un rôle
33
+
## Créer ou modifier un rôle
23
34
24
35
Cliquer sur le bouton `Ajouter un rôle`.
25
36
26
37
27
38
28
-
Le champ de texte `Nom du rôle` permet de choisir le nom du rôle à créer.
39
+
Le champ `Nom du rôle` permet de choisir le nom du rôle à créer.
29
40
30
-
Détail des permissions :
41
+
### Permissions disponibles
31
42
32
43
- Projet
33
44
- Gérer le projet : Permet de gérer tout le projet et ses ressources associées
@@ -44,31 +55,39 @@ Détail des permissions :
44
55
- Gérer les dépôts : Permet de créer, éditer, supprimer des dépôts
45
56
- Voir les dépôts : Permet de visualiser tous les dépôts et leurs configurations
46
57
47
-
Cliquer sur le bouton `Enregistrer` pour créer le rôle.
58
+
Cliquer sur `Enregistrer` pour créer le rôle.
48
59
49
-
##Assigner/Retirer un membre à un rôle
60
+
### Ajouter/retirer des membres à un rôle
50
61
51
-
Cliquer sur le rôle voulu et aller dans l'onglet `Membres`
62
+
Après création, sélectionner le rôle puis ouvrir l’onglet `Membres` pour ajouter/retirer des utilisateurs. Les modifications sont sauvegardées automatiquement.
52
63
53
-
64
+
54
65
55
-
Dans l'exemple, Aurahan est associé au rôle Dev.
66
+
## Supprimer un rôle
56
67
57
-
Les modifications concernant les membres d'un rôle sont sauvegardées automatiquement.
68
+
Pour supprimer un rôle, sélectionner celui-ci dans la liste des rôles puis cliquer sur `Supprimer`.
58
69
59
-
Il est possible de retrouver un récapitulatif des rôles associés aux membres du projet sur la page `Equipes` :
Les permissions sont cumulatives : un utilisateur obtient l’ensemble des permissions de tous les rôles qui lui sont assignés. Il n’y a pas de mécanisme de “refus” qui viendrait retirer des droits.
64
75
65
-
- Baptiste est le créateur du projet
66
-
- Pierre a le rôle ops
67
-
- Aurahan a les rôles dev et PO
76
+
Exemple : si un rôle donne `Voir les dépôts` et un autre donne `Gérer les dépôts`, l’utilisateur pourra `Gérer les dépôts`.
68
77
69
-
## Supprimer un rôle
78
+
### Rôles préconfigurés (lecture seule)
79
+
80
+
Certains rôles sont fournis par la plateforme (rôles “système”). Ils sont en lecture seule : vous ne pouvez pas modifier leurs permissions ni leur nom, mais vous pouvez ajouter/retirer des membres.
81
+
82
+
Pour les identifier, vérifier que les champs de paramétrage sont non modifiables (grisés) dans l’interface.
83
+
84
+
Selon l’intégration et le niveau de synchronisation, l’affectation à un rôle peut se traduire par une appartenance visible côté GitLab (groupe synchronisé).
70
89
71
-
Pour supprimer un rôle, sélectionner celui-ci dans la liste des rôles et cliquer sur le bouton `Supprimer`
90
+
Cette page présente l’IAM de la Console (Identity & Access Management) : authentification, autorisations et principes de synchronisation des groupes.
4
+
5
+
## Architecture fonctionnelle
6
+
7
+
L’IAM repose sur Keycloak pour l’identité (OIDC), une authentification backend via session ou jeton API, et une autorisation calculée côté serveur avec des bitmasks BigInt.
8
+
9
+
L’authentification navigateur passe par `fastify-keycloak-adapter`, qui extrait l’identité (`sub`, `email`, `given_name`, `family_name`, `groups`) et la stocke en session. Un mode jeton API (`x-dso-token`) existe aussi pour des usages non interactifs.
10
+
11
+
L’autorisation combine des permissions globales (`ADMIN_PERMS`) et projet (`PROJECT_PERMS`) via OR bitwise, puis applique les décisions avec `AdminAuthorized.*` et `ProjectAuthorized.*`.
12
+
13
+
## Groupes et rôles
14
+
15
+
La Console maintient une hiérarchie de groupes Keycloak par projet pour matérialiser les rôles et la séparation RO/RW des environnements :
16
+
17
+
```txt
18
+
/<projectSlug>
19
+
/console
20
+
/<role-group-path...>
21
+
/<environmentName>
22
+
/RO
23
+
/RW
24
+
```
25
+
26
+
La réconciliation est faite par `KeycloakService` (événements projet + cron), qui crée les groupes manquants, ajuste les memberships et purge les orphelins.
27
+
28
+
Certains rôles affichés dans la Console sont préconfigurés (rôles “système”) et sont en lecture seule. Dans ce cas, l’interface permet typiquement de gérer les membres, mais pas de modifier le contenu du rôle.
- Rôles projet (scope projet) : [Gestion des rôles](/guide/roles)
34
+
35
+
### Corroboration externe (GitLab)
36
+
37
+
Selon l’intégration et le niveau de synchronisation, on peut corroborer les accès via GitLab (projets et memberships). Voir des exemples de captures dans [Gestion des rôles](/guide/roles) et [Rôles plateforme](/administration/roles).
38
+
39
+
## Pour aller plus loin
40
+
41
+
-[Rôles plateforme](/administration/roles)
42
+
-[Gestion des rôles (projet)](/guide/roles)
43
+
-[Gestion des équipes](/guide/team)
44
+
-[Gestion des projets](/guide/projects-management)
Ne pas renuméroter les bits de `ADMIN_PERMS`/`PROJECT_PERMS` sans migration contrôlée. Les cookies de session doivent rester `httpOnly` + `secure` en production (HTTPS). Les jetons API sont stockés hashés et doivent être traités comme des secrets.
0 commit comments