URL: https://linuxfr.org/users/superzen/journaux/glewlwyd-2-0-serveur-sso-est-maintenant-en-rc1 Title: Glewlwyd 2.0, serveur SSO, est maintenant en RC1 Authors: Babelouest Date: 2019年09月08日T22:27:29+02:00 License: CC By-SA Tags: oauth2, openidconnect, yubikey, webauthn, otp, fédération-identité et jwt Score: 15 Glewlwyd est un serveur d'authentification unique. La nouvelle version 2.0 entre maintenant en Release Candidate et propose plein de fonctionnalités. https://github.com/babelouest/glewlwyd Il implémente les protocoles suivants: - OpenID Connect - OAuth2 Ainsi que les schémas d'authentification: - Mot de passe à l'ancienne - TOTP/HOTP - Webauthn avec le support de FIDO2 et Android Safetnyet - Envoi de code aléatoire par e-mail - Certificat TLS Il peut se connecter à un ou plusieurs serveurs LDAP ainsi que une ou plusieurs bases de données pour le stockage des utilisateurs. Il permet aussi de faire du passwordless c'est à dire de se débarrasser du mot de passe pour s'authentifier. ## Principes ### Serveur d'Authentification Unique Un serveur d'[authentification unique](https://fr.wikipedia.org/wiki/Authentification_unique) ou Single-Sign-On permet de centraliser l'authentification pour plusieurs services au même endroit. Lorsque l'on implémente ou qu'on gère des services webs, on se rend compte que l'authentification des requêtes pour accéder aux services est non seulement lourde, mais en plus peut être dupliquée autant de fois qu'on a de services différents parfois, ce qui ajoute du code, des bugs, de la maintenance, et peut limiter l'évolution du reste. Le besoin est pourtant simple à formuler:> Je veux que seules les personnes autorisées puissent accéder à mes services web. Des gens se sont donc penchés sur la question depuis pas mal d'années et plusieurs solutions et architectures ont émergé depuis. ### OAuth2 OAuth2 est le successeur d'OAuth, et est un framework de délégation d'authentification qui permet à un client de se connecter à un ou plusieurs serveurs de ressources au nom d'un utilisateur. Le principe est le suivant: le client redirige l'utilisateur vers le serveur d'authentification unique en notifiant au serveur d'authentification qui est le client qui demande, et quels accès il demande. L'utilisateur s'authentifie, autorise ou non les accès au client selon ses droits, puis le serveur d'authentification redirige l'utilisateur vers le client avec une clé. Cette clé permet enfin au client d'accéder aux ressources demandées initialement. Pour répondre à plusieurs besoins distincts, OAuth2 propose plusieurs méthodes d'authentification appellées `response type`. Il propose également les `access token` qui sont les clés proprement dites pour accéder aux ressources et les `refresh token` qui permettent de demander un nouvel `access token` quand le précédent a expiré. OAuth2 est un standard volontairement incomplet. Pas dans le sens tout pourri, mais qui laisse volontairement des zones d'ombre pour permettre de s'adapter aux besoins. Par exemple, il ne spécifie pas comment le serveur d'authentification doit identifier l'utilisateur. Ca peut être par un cookie de session, par un certificat TLS, par autre chose, etc. Également, il dit que l'authentification des access tokens est en dehors de la portée du protocole OAuth2. ### OpenID Connect La fondation OpenID est partie du standard OAuth2 et de ses propres expériences et solutions pour proposer le protocole OpenID Connect. OpenID Connect est issu de OAuth2 mais n'en est pas pour autant interopérable. En fait, il a pris certains aspects d'OAuth2 qui l'intéresse, s'est débarrassé des aspects qui ne l'intéresse pas, et a ajouté de nouvelles fonctionnalités pour étendre les possibilités. La grosse nouveauté d'OpenID Connect (mais pas la seule) est le `id token`, c'est un [JWT](https://fr.wikipedia.org/wiki/JSON_Web_Token) permettant au client d'identifier l'utilisateur connecté et d'accéder à des informations de l'utilisateur comme son nom, son adresse courriel, son adresse postale, etc. Il est également plus structuré car il propose des webservices supplémentaires et normalisés comme le `userinfo` qui permet d'accéder à des informations d'un utilisateur comme pour un `id token` ou le webservice disovery `/.well-known/openid-configuration` permettant de récupérer la configuration publique du serveur et donc de faciliter la configuration d'un nouveau client en lui donnant la marche à suivre pour connecter un serveur OpenID Connect ainsi que les fonctionnalités qu'il supporte. ### Implémentations existantes Beucoup de fournisseurs de services en ligne proposent leut propre SSO: [Google](https://developers.google.com/identity/), [Microsoft Azure](https://azure.microsoft.com/en-us/resources/videos/overview-of-single-sign-on/), [Apple](https://developer.apple.com/sign-in-with-apple/), [Twitter](https://developer.twitter.com/en/docs/twitter-for-websites/log-in-with-twitter/login-in-with-twitter.html), [AWS](https://aws.amazon.com/fr/single-sign-on/), la liste est longue. Pour les libristes, il existe également beaucoup de produits libres que l'on peut utiliser chez soi: [Gluu](https://www.gluu.org/), [Keycloak](https://www.keycloak.org/) notamment pour ceux que je connais un peu. ## Fonctionnement Voici donc la nouvelle version de mon serveur SSO que j'avais [déjà présenté](https://linuxfr.org/users/superzen/journaux/glewlwyd-serveur-d-authentification-oauth2) dans sa version précédente. Le backend est écrit en C ce qui permet d'avoir une application légère et rapide. Il supporte des bases de données SQLite3, MySQL/MariaDB ou PostgreSQL. C'est du GPL et c'est libre! À l'époque, Glewlwyd supportait seulement le protocole OAuth2 et une seule instance de connexion LDAP et base de données. Après quelques retours et des envies de tester des trucs nouveaux, j'ai décidé de tout remettre à plat et de faire la version 2.0 avec une architecture modulaire. L'idée de cette architecture est de séparer et de cloisonner certains aspects de l'application, afin de rendre le code plus facile à écrire, débugger, et maintenir. On peut donc écrire des modules pour: - Gérer les utilisateurs - Gérer les clients - Gérer les méthodes d'authentification pour les utilisateurs (Les fameux N-Factor) - Gérer les protocoles d'authentification voire en implémenter des nouveaux Glewlwyd permet donc d'authentifier un utilisateur et de donner à un client un accès aux ressources autorisées par l'utilisateur. Il permet également de rajouter des facteurs d'authentification pour des niveaux d'accès. Ainsi, on peut dire que le niveau d'accès X requiert le mot de passe *et* le TOTP, le niveau d'accès Y seulement le mot passe, et le niveau d'accès Z le TOTP *ou* la yubikey. ### Backends user et client Les utilisateurs et les clients (qui au final sont des utilisateurs particuliers) peuvent être stockés dans la base de données, ou une autre base de données ailleurs, ou dans un serveur LDAP (en écriture si ca vous tente), voire plusieurs. On peut ajouter autant d'instances de backends qu'on veut pour accéder aux utilisateurs. Le backend gère l'authentification par mot de passe, et puis c'est tout. ### Modules d'authentification Pour rajouter des couches de blindage à l'authentification, on peut rajouter des facteurs supplémentaires. Les facteurs actuellement implémentés sont: #### TOTP/HOTP Le One-Time Password ou mot de passe à usage unique, dans sa version HOTP (avec un compteur qui s'incrémente à chaque accès réussi), ou TOTP (basé sur l'heure, donc change toutes les x secondes). Comment ca marche? Tu scannes le QR code de la page OTP de ton profil Glewlwyd dans ton application OTP préférée, ou tu recopies les paramètres, et paf! #### Webauthn La [nouvelle API Javascript](https://www.w3.org/TR/webauthn/) permet de faire de l'authentification dans ton navigateur avec un composant externe. C'est supporté dans Firefox et Chrom[e|ium]. Tu dois utiliser un outil tiers qui signe une attestation permettant au serveur de vérifier que c'est le bon utilisateur qui se connecte. Tu sais que c'est le bon utilisateur car il a préalablement enregistré son composant Webauthn dans son profil Glewlwyd. Ca marche avec les [Yubikey](https://www.yubico.com/products/yubikey-hardware/) (FIDO2 pour les intimes) ou le [téléphone Android](https://developer.android.com/training/safetynet/attestation) (Android SafetyNet). D'autres formats d'authentification existent comme TPM, Packed ou Android Key mais comme je n'ai sous la main que des machins android ou des Yubikeys, je n'ai pas pu faire les autres. Avis aux amateurs! #### Envoi d'un code à ton adresse courriel Simple, efficace, mais pas mal plus contraignant, parce que faut avoir accès à son courriel déjà, et faut avoir confiance dans le fait qu'il n'est pas compromis. #### Certificat TLS J'avoue que celui-là c'est plus un défi technologique qu'autre chose, en plus de trouver la méthode contraignante: tu dois sauvegarder le certificat dans ton navigateur, en demander un nouveau quand l'autre a expiré. De plus, je ne connais pas assez le standard donc ca se peut que des trucs importants m'aient échappé. J'aimerais beaucoup un avis éclairé sur celui-là, en toute modestie. ### Plugins Comme je l'expliquais plus haut, les protocoles OAuth2 et OpenID Connect sont supportés. Comme dans la première version, les access tokens fournis sont des JWT. Un JWT, ou [JSON Web Token](https://fr.wikipedia.org/wiki/JSON_Web_Token) est un token signé, permettant d'incorporer au token des informations, et la signature garantit que l'information n'a pas été modifiée entre le serveur et le client. C'est donc la méthode que j'ai choisie, ca permet au serveur de ressource qui mange le token de ne pas avoir à demander au serveur d'authentification si le token est valide ou non, il peut le vérifier tout seul. Dans Glewlwyd, un plugin est vu plus ou moins comme une application autonome qui peut créer ses propres webservices pour ses propres besoins, tout en ayant accès à certaines ressources comme les utilisateurs ou les sessions. Je ne l'ai pas encore fait mais si par exemple je veux faire un service pour permettre aux nouveaux utilisateurs de s'enregistrer ou un service `J'ai perdu mon mot de passe`, ca ira dans un plugin plutôt que dans l'application elle-même. ## Conclusion Avis aux curieux. L'application rentre en Release Candidate maintenant et ca serait cool d'avoir des retours et des avis.

AltStyle によって変換されたページ (->オリジナル) /