2022/12/11 (Neutriton) : Keycloak v2

• Réunion précédente
• Pad de la réunion

Présences :

• HgO
• Tharyrok
• Célo
• Channel (en retard)

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

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: max 17h

C'est la galère :boat:

Royaume séparé du royaume principal et aussi par type d'application et type de données personnelles

On pouvait faire en sorte qu'un royaume peut parler à d'autres royaumes (= fédération) pour récupérer les utilisateurs

On a vu la différence entre SAML et openid-connect, ce dernier étant plus récent.

Open-id-connect, est un successeur de oauth2 qui est un successeur de open-id. Ca fonctionne avec du json et des requêtes https et c'est fondé sur des api rest.

SAML est plus ancien. C'est du xml. Les messages sont signés et/ou chiffrés. Ca ne se repose pas forcément sur de l'https.

Dans le cas de SAML, un échange manuel de clés publiques doit être fait. Ce n'est pas le cas d'open-id.

On a vu qu'on pouvait attribuer des rôles aux utilisateurs. On a aussi vu le flux de travail, la manière dont les informations circulent entre l'utilisateur·trice (navigateur), l'application qui a besoin de se connecter et keycloak.
Quand on va sur l'application, soit on est déjà connecté soit on n'est pas encore connecté.

Si on est déjà connecté, et l'app utilise openid, et dans ce cas on a un refresh token de l'utilisateur. C'est un token qui a un temps d'utilisation.

Soit l'application considère que le refresh token est toujours valide, soit elle considère que les infos qu'elle a au niveau SSO sont toujours valides et la session est toujours en cours. En fonction de comment l'application a été codée, soit elle vérifie soit toutes les X minutes, soit elle revérifie le token à chaque nouvelle page. Dans le cas où on ne revérifie pas à chaque fois, on peut avoir une situation où l'application demande une fois à Keycloack si le tocken est valide et puis elle considère que la session est toujours en cours jusqu'à la déconnexion de l'application.

La manière dont ça se passe dépend du développement.

Cela signifie que si on se déco de Keycloak, on peut très bien être encore connecté à d'autres applications qui ne font pas le travail de revérifier auprès de Keycloak si c'est vrai que l'utilisateur s'est déconnecté.

Si on n'est pas connecté, on arrive sur la page de connexion. Sur le bouton pour se logger, on va avoir :

• l'id du client (parfois)
• l'url de call back

Quand on configure mal keycloak, on a parfois une erreur qui dit que l'url de call back ou l'url de retour n'est pas valide. C'est cette URL que Keycloak va appeler une fois qu'il a identifié la personne.

Dans le cas où on est pas connecté, on affiche le formulaire de connexion. Keycloack fait une redirection vers l'url de call back de l'application avec le refresh token. Cela peut se faire au travers d'une requête GET (tout est dans l'URL même le token) ou POST (envoi des informations dans un formulaire).

Ca c'est du oauth2. La particularité d'open-id est qu'on a des URL avec plus d'infos accessibles sur Keycloak. L'application peut donc le contacter via le refresh token.

L'application va d'abord voir chez Keycloak.

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

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

Des services sont provisioné et disponible a ces address :

• 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)

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.

• 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 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

Config /var/www/proxy-xxxx/dist/oauth2-proxy.cfg service oauth2-proxy.services

## 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"

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.

Configurer l'autentification oauth2 https://github.com/trilbymedia/grav-plugin-login-oauth2 https://github.com/trilbymedia/grav-plugin-login-oauth2-extras

Configurer l'autentification saml et les groups utilisateurs.

Prochaine réunion neutriton v3 : 12/02/2023 à 14h (confirmer en réu hub-infra) Prochaine réunion hub-infra : 22/01/2023 à 14h

Lieu : Jitsi & Caldarium

On confirmera la date pour la suite de l'atelier keycloak à ce moment-là.

Il restera aussi le Neutriton sur la sécurité à décider.

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.