# 2023/02/12 (Neutriton) : Keycloak v3

* [Réunion précédente](https://wiki.neutrinet.be/fr/rapports/2022/12-11)
* [Pad de la réunion](https://doc.neutrinet.be/neutriton-2023-02-12)

Présences : 

- HgO
- Célo
- Tharyrok
- wget

## Météo

//Moment informel durant lequel on exprime **en peu de mots** comment on se sent et si on a une attente forte pour la réunion.//
//**Ce n'est pas un moment de discussion mais d'expression individuelle et ce n'est pas obligatoire :-)**//

### Attente(s) forte(s)

//Si l'une ou l'autre personne exprime une attente forte, merci de vous en occuper en priorité ou de la noter dans le hub ou dans un point approprié//.

FIN: 17h

## Atelier Keycloak v3

### Rappel du dernier atelier

On a créé un utilisateur et deux royaumes : un royaume utilisateurs et un royaume applications.

On avait fait deux royaumes comme ça l'on sépare les utilisateurs des applications, pour éviter que les applications aient plus d'informations que nécessaire.

Quand on veut donner accès au Keycloak, si on donne directement accès au royaume des utilisateurs c'est sensible.

Des développeurs auront besoin de pouvoir gérer les utilisateurs de leur application mais pas besoin de connaître les données sensibles.

Donc l'idée c'est de segmenter, et la séparation peut prendre plusieurs aspects (par ex un client qui n'a besoin que le nom, prénom et email, tandis qu'un autre a aussi besoin de l'adresse postale), et on peut avoir plusieurs royaumes différents par usage (applications-postal, applications-basic, etc.)

Une arme puissante dans Keycloak est de pouvoir impersonnifier les personnes. Dans ce cas, Keycloak ne peut pas savoir que ce n'est pas la personne qui fait des choses, et donc on peut faire tout et n'importe quoi au nom de la personne. Cela peut donner lieu à des cas graves.

Ensuite, on a connecté un premier client : proxy oauth2. Ce client est un peu spécial car il permet de connecter une application qui n'est pas compatible avec oauth2. Cela permet de donner accès à des applications comme site statique.

![](https://s3.neutrinet.be/hedgedoc/uploads/8f99db02-fd0b-4d5e-a3a5-cc108e48afa6.png)

L'avantage de oAuth Proxy est de gérer les choses.

* Ne fonctionne que si on a été connecté correctement sur Keycloak
* ProxyOAuth rajoute des headers et Peering-manager ou Netbox comprends les headers qu'on lui envoie. Ca permet aux devs d'éviter de gérer plusieurs manières de connexion (OpenID, oauth, etc.) et de réutiliser une brique (le proxy OAuth).

On aimerait avoir une belle doc pour connecter un client ou créer les deux royaumes. Après le problème c'est que l'interface change très souvent, on va se retrouver avec une doc vite obsolète. Donc il faudra repartir d'un keycloak vierge pour s'assurer que toute la doc est toujours à jour.

Est-ce qu'on mettra à jour keycloak régulièrement ? À quel rythme ? Est-ce qu'on met à jour vers la dernière version ? Est-ce qu'on met à jour sur une instance de test pour vérifier ce qui est cassé (thème, etc.) ? Tout ça fera l'objet d'un Neutriton sur le version management. 

TODO: Avoir un Neutriton sur le version management / version tracking

### Laboratoire

Des serveur sont provisionnés et disponible a ces addresses :

- ssh.3e9.chezme.me (HgO)
- ssh.3ea.chezme.me (Célo)
- ssh.3eb.chezme.me (wget)
- ssh.3ec.chezme.me (Tharyrok)

Des services sont provisionnés et disponibles à ces adresses :

- mail.{slug}.chezme.me (maildev pour voir les mails)
- cloud.{slug}.chezme.me (nextcloud)
- auth.{slug}.chezme.me (keycloak)
- echo.{slug}.chezme.me (voir les headers)
- www.{slug}.chezme.me (grav)
- proxy.{slug}.chezme.me (proxy oauth2)

### Exercice

Le but, c'est de configurer deux services en open-id et un service en SAML. 

Dans les services openid il y aura Grav et proxy-oauth2

Nextcloud sera en SAML.

Maildev est juste là pour débugguer, il permet de voir les mails qui arrivent sur la machine localement.

#### Keycloak

- Créer un utilisateur
- Créer un royaume utilisateur
- Créer un royaume application
- utiliser l'Identity providers du royaume utilisateurs vers le royaume application
- Créer des roles clients dans le royaume application a faire une fois que des applications dans keycloak sont configuré

Il y a un outil qui est censé facilité la connexion entre les deux royaumes. On doit aller dans le royaume utilisateurs, dans `Realm Settings` récupérer le `OpenID Endpoint Configuration` tout en bas, qui ressemble à ça : https://auth.3e9.chezme.me/realms/utilisateurs/.well-known/openid-configuration

Ensuite dans le royaume applications, dans le Identity Provider on fournit cette url pour le champ `Discovery Endpoint`. 

On doit aussi avoir créé un client `keycloak-oidc` dans le royaume utilisateurs pour permettre au royaume applications de se connecter à ce royaume.

Il faut aussi changer le flow authentication pour dire au royaume applications de se connecter avec les utilisateurs du royaume utilisateurs.

#### Proxy oauth2

Il faut configurer l'outils pour qu'il proxifie le service echo (port 5080) sur le domain proxy.{slug}.chezme.me avec une authentification.

https://oauth2-proxy.github.io/oauth2-proxy/docs/configuration/oauth_provider#keycloak-oidc-auth-provider

Dans Keycloack, on créé un nouveau client dans le royaume application (et non utilisateur, car il s'agit d'une application) :

On met l'adresse du proxy comme adresse de callback : 

https://proxy.3ea.chezme.me/oauth2/callback

Dans Credential, on trouve le secret lié au client : 

![](https://s3.neutrinet.be/hedgedoc/uploads/c192ab78-af7e-455d-adb5-2d31379a53bf.png)

On fait ensuite la config du proxy dans la machine, dans ```/var/www/proxy-xxxx/dist/oauth2-proxy.cfg```

```
## The OAuth Client ID, Secret
provider = "keycloak-oidc"
client_id = "proxy-xxx-chezme-me"
client_secret = ""
oidc_issuer_url = "https://auth.xxx.chezme.me/realms/master"
```
Chez Célo, ça donne : 
```
## the OAuth Redirect URL.
# defaults to the "https://" + requested host header + "/oauth2/callback"
redirect_url = "https://proxy.3ea.chezme.me/oauth2/callback"

[...]

## The OAuth Client ID, Secret
provider = "keycloak-oidc"
client_id = "oauth2-proxy"
client_secret = "JyoFO5peUIkMqWUSKOVjwYbCWapPLYnY"
oidc_issuer_url = "https://auth.3ea.chezme.me/realms/broco_applications"
```

On rédémarre le proxy : 

```
service oauth2-proxy.services
```
Si on a un problème d'audience il faut allé dans client scope du client dans keycloak, ajouté un scope configuré de type audience et de nom audience.

Spécifier l'audience sert à restreindre le client OAuth pour ne pas qu'il puisse accéder à toutes les apps du royaume dans lequel il est. En effet comme le client est dans le royaume `applications`, il peut par défaut accéder à toutes les applications. Cet argument d'audience permet de lister les applications auxquelles le client peut avoir accès.

![](https://s3.neutrinet.be/hedgedoc/uploads/a48950e3-050b-4f44-b28b-0cd2e94096f8.png)

Ici, il y a aussi un mapper groups comme définit dans la doc : https://oauth2-proxy.github.io/oauth2-proxy/docs/configuration/oauth_provider/#keycloak-oidc-auth-provider Mais ce n'est pas obligatoire.

![](https://s3.neutrinet.be/hedgedoc/uploads/8d9f570c-bb2d-4267-9d64-4f37daf4aee4.png)

Si tout semble bon mais que les logs indiquent un problème de mail, il faut indiquer au niveau de l'utilisateur que l'email est vérifié.

![](https://s3.neutrinet.be/hedgedoc/uploads/0ef92220-7397-48a9-b65f-ddd729ebf514.png)

A la fin, une fois que ça fonctionne, on peut comparer le header entre https://echo.3ea.chezme.me/ et https://proxy.3ea.chezme.me/

#### Grav

Configurer l'autentification oauth2

- https://github.com/trilbymedia/grav-plugin-login-oauth2
- https://github.com/trilbymedia/grav-plugin-login-oauth2-extras

On commence par créer un utilisateur `admin` qui a accès à l'interface d'administration de Grav.

Ensuite, on configure les plugins pour l'oauth2 en suivant les instructions dans la doc.

Il faut aller sur `<grav domain>/login` pour voir une interface toute moche qui permet de se connecter via Keycloak.

Spoiler chez HgO:

- Créer un client `grav`
- Ajouter la root url `http://www.3e9.chezme.me`
- Ajouter les redirect url pour le login et l'admin (ce sont les callback urls dans le plugin Oauth2 de grav)
- Dans le plugin Oauth2 Extra de grav, mettre les scopes suivants:
    - profile: permet de récupérer les infos de l'utilisateur, tels que le nom, prénom, etc de l'utilisateur
    - email: permet de récupérer l'email de l'utilisateur
    - openid: nécessaire au bon fonctionnement du plugin
- Les client scopes se trouvent dans le royaume utilisateurs, et on peut cliquer par exemple sur `profile` pour voir les infos qui sont fournies, notamment le nom des attributs qui sont passés à grav
- Mettre les attributs suivants dans le plugin Oauth2 Extra:
    - Login key: username
    - Fullname key: name (c'est pas documenté...)
    - Email key: email
- Si on veut donner un accès admin, alors il faut suivre les instructions du plugin Oauth2, notamment:
    - save grav user: true, et on donne les accès "super admin" ou autre dans l'interface d'admin de Grav
- Pour éviter d'avoir des problèmes de cache lors du logout, il faut mettre à true le paramètre `Dynamic Page Visibility` dans le plugin Login. On peut aussi mettre à true le paramètre `Redirect after login` si jamais on ne passe pas par Keycloak.
- Pas trouvé comment forcer le login via Keycloak (et rien d'autre). En tout cas, on ne peut pas se logger manuellement, même en testant avec l'email ou l'username généré par Keycloak.

#### Nextcloud

Configurer l'autentification saml et les groups utilisateurs.

## Prochaine réunion

Prochaine réunion keycloak v4 : 30/04 à 14h00

Lieu : Caldarium

## Météo de fin

//Moment informel durant lequel on exprime **en peu de mots** comment, à titre personnel, la réunion a été vécue que ce soit positif ou négatif.//
//Si une ou plusieurs **tension est née** durant la réunion, il est peut-être nécessaire d'envisager l'une ou l'autre réunion pour y remédier.//

{{tag>infra neutriton}}