# Autorisation & RBAC

> **Unité d'apprentissage.** Moule : ① concept → ② Set-OPS → ③ transférable → ④ à toi de jouer.
> Le pendant naturel de **[Identité & SSO](Identité-et-SSO)** : celle-là dit *qui tu es*, celle-ci dit *ce que tu as le droit de faire*.

---

## ① Le concept *(générique)*

**Authentification (authN)** : *qui es-tu ?* — **Autorisation (authZ)** : *as-tu le droit ?* Deux
questions distinctes. Se connecter ne dit **rien** sur ce qu'on peut faire.

**RBAC** (*Role-Based Access Control*) : on n'attribue pas des droits à chaque personne, mais des
**rôles** (Viewer, Editor, Admin…), et chaque rôle porte un ensemble de **permissions**. La personne
reçoit un rôle → hérite des droits. Simple, auditable, évolutif.

**Où décider ?** Deux écoles :
- *local à l'app* : chaque service gère ses propres comptes/rôles (silos, à maintenir partout) ;
- *centralisé (piloté par le SSO/annuaire)* : le rôle voyage **dans le jeton** ; l'app le lit et
  l'applique. Une seule source, cohérente partout. **Moindre privilège** par défaut.

Mécanique OIDC : le fournisseur d'identité met un **claim** (ex. `roles`) dans le jeton ; l'app
**mappe** ce claim vers son niveau de droit interne.

---

## ② Comment Set-OPS le fait — l'exemple Grafana

Par défaut, un utilisateur SSO arrive en **Viewer** dans Grafana → il voit les tableaux de bord,
mais **pas Explore** (requêtes ad-hoc). Pour donner Explore aux opérateurs, sans l'ouvrir à tous :

```
Keycloak : rôle de realm 'grafana-editor'  ──(assigné à testmail)
        + mapper de rôles                  ──> claim "roles":["grafana-editor"] dans le jeton
Grafana  : role_attribute_path             ──> "grafana-editor" ⇒ Editor (⇒ Explore)
                                               "grafana-admin"  ⇒ Admin ; sinon Viewer
```

Déclaratif dans Set-OPS : `serveur_keycloak_realm_roles`, `_role_mapper_clients`,
`_role_assignments` (côté IdP) + `serveur_grafana_oidc_role_path` (côté app). kcadm **à chaud** :
**zéro coupure SSO**. Une identité (`testmail`), et c'est **le rôle** — pas la connexion — qui décide
d'Explore.

> **Raffinement souverain** : ici le rôle est assigné *explicitement* à testmail. L'idéal est de le
> piloter par un **groupe d'annuaire** (LDAP → Keycloak → claim), pour que *l'appartenance* gouverne
> l'autorisation. C'est le vrai « l'annuaire gouverne l'accès ».

---

## ③ Pourquoi c'est transférable

| Set-OPS | Équivalents ailleurs |
|---|---|
| rôles de realm Keycloak → claim | claims/scopes OIDC de tout IdP (Okta, Entra…) |
| `role_attribute_path` Grafana | *role mapping* de n'importe quelle app OIDC |
| RBAC (rôles → permissions) | **Kubernetes RBAC** · IAM cloud (AWS/GCP) · SGBD (rôles SQL) |
| moindre privilège | principe **universel** de sécurité |

Tu as appris **authZ vs authN, le RBAC, l'autorisation par claim, le moindre privilège** — pas
« Grafana ».

---

## ④ À toi de jouer

1. **Sens le défaut.** Avant tout rôle, un nouvel utilisateur SSO est **Viewer** dans Grafana : il
   voit le dashboard *Journaux de la flotte*, mais **pas** l'icône Explore.
2. **Donne Editor.** `testmail` a le rôle `grafana-editor` → **déconnecte/reconnecte-le** (Grafana
   applique le rôle *à la connexion*) → **Explore apparaît**.
3. **Observe le claim.** Dans Keycloak (console admin) → Clients → grafana → *Client scopes* →
   *Evaluate* pour `testmail` : le jeton contient `"roles": ["grafana-editor"]`. C'est ② en vrai.
4. **Casse & répare.** Retire `grafana-editor` de testmail (ou renomme-le en `grafana-viewer`),
   reconnecte : **Explore disparaît**. Remets-le : il revient. Tu *sens* que c'est **le rôle**, pas
   l'identité, qui ouvre la porte.

---

## Pour aller plus loin *(dépôt)*
- IdP : `roles/serveur_keycloak/tasks/rbac-oidc.yml` (rôles + mapper + assignations).
- App : `roles/serveur_grafana` (`serveur_grafana_oidc_role_path`).
- Le pendant *authentification* : unité **[Identité & SSO](Identité-et-SSO)**.