Table des matières
2022/12/11 (Neutriton) : Keycloak v2
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: max 17h
Atelier Keycloak v2
Rappel du dernier atelier
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.
Laboratoir
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)
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é
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.
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.
Grav
Configurer l'autentification oauth2 https://github.com/trilbymedia/grav-plugin-login-oauth2 https://github.com/trilbymedia/grav-plugin-login-oauth2-extras
Nextcloud
Configurer l'autentification saml et les groups utilisateurs.
Prochaine réunion
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.
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.