Journal Glewlwyd 2.0, serveur SSO, est maintenant en RC1

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
15
8
sept.
2019

Sommaire

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 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 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, Microsoft Azure, Apple, Twitter, AWS, la liste est longue.

Pour les libristes, il existe également beaucoup de produits libres que l'on peut utiliser chez soi: Gluu, Keycloak 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é 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 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 (FIDO2 pour les intimes) ou le téléphone Android (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 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.

  • # Papotages

    Posté par  (site web personnel) . Évalué à 6.

    Salut,
    Je vais chipoter un peu,…

    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.

    C'est un protocole d’autorisation, aucun moyen de valider une identité avec un acces_token avec OAuth2 seul, seulement d'autoriser l'accès sur une porté donnée (Et je ne vois pas ce qui à été supprimé).

    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.

    Je n'ai pas trop compris, pour moi OIDC est une surcouche à OAuth2 qui ajoute l'authentification via : id_token qui est une preuve d'identité le service web userinfo qui donne l'identité de l'utilisateur en échange d'un access_token.

    Sinon, je trouve super de voir de nouveau IdP qui donne de nouvelles pistes de réflexions. Et après un rapide survole de la doc, j'ai aimé assez ta vision, notamment :
    - de la gestion des sessions multiples : l'idée est intéressante !
    - que webauthn soit implémenté : tu l'exploites dans quel contexte ?
    - le "E-mail code scheme" natif qui peu être intéressant

    Dans quel contexte exploites tu ton projet ?

    Bon continuation dans ton projet.

    Ps: tu n'as pas un container à nous soumettre pour faire des tests ?

    • [^] # Re: Papotages

      Posté par  (site web personnel) . Évalué à 3.

      C'est un protocole d’autorisation, aucun moyen de valider une identité avec un acces_token avec OAuth2 seul, seulement d'autoriser l'accès sur une porté donnée (Et je ne vois pas ce qui à été supprimé).

      Alors, dans l'absolu oui parce que OAuth2 ne dit pas ce qu'est un access token, sauf que dans mon cas le access token est un JWT, ce qui permet d'avoir des informations pertinentes dedans.
      Dans le cas du plugin OAuth2 de Glewlwyd, le payload des JWT ressemble à ca:

      {
  username: "user1",        // Username that was provided this access_token
  salt: "abcdxyz1234",      // Random string to avoid collisions
  type: "access_token",     // Hardcoded
  iat: 1466556840,          // Issued at time in Epoch Unix format
  expires_in: 3600,         // Number of seconds of validity for this token
  scope: "scope1 g_profile" // scopes granted to this access token in a string separated by spaces
}

      Ce qui permet d'avoir l'information minimale de l'identité de l'utilisateur qui demande l'accès aux ressources.

      Ce que OIDC a enlevé par rapport à OAuth2 vanille c'est les response types Resource Owner Password Credentials Grant et Client Credentials Grant.
      Pour être précis ils ne disent pas explicitement "Ne mettez pas ca dans votre OIDC", mais la norme OIDC les ignore, donc on en fait ce qu'on veut.
      Ca peut vouloir dire que si tu migres d'un serveur OAuth2 vers un serveur OIDC et que tu utilisais ces response types dans OAuth2, ils ne seront pas nécessairement implémentés dans le nouveau serveur, donc il faudra que tu trouves une autre solution.
      Pour éviter ca, dans le plugin OIDC, j'ai mis une option pour le rendre "compatible" OAuth2.

      que webauthn soit implémenté : tu l'exploites dans quel contexte ?

      J'ai acheté deux Yubikeys (une Yubikey 4 et une 5 nfc), j'ai un téléphone android avec le lecteur d'empreinte et une tablette sans lecteur d'empreinte mais suffisamment récent pour que ca fonctionne quand même avec le code secret.
      Ca me permet donc de faire de l'authentification sur ces deux machines sans utiliser de mot de passe ou de TOTP ou autre. Super pratique pour me connecter.

      Mais comme je disais, je ne supporte que ces deux types de device webauthn parce que c'est les seuls que j'ai sous la main. J'aimerais bien supporter toute la chaine de composants webauthn mais j'ai rien pour le tester.

      Dans quel contexte exploites tu ton projet ?

      Chez moi pour mes autres projets personnels. Je suis un adepte de l'auto-hébergement et outre mes mails et mon nextcloud, je me suis fais un serveur domotique, un serveur de streaming audio et un gestionnaire de mots de passe. Je voulais pas me cogner la couche d'authentification dans chacun de ceux-là indépendamment.

      Ps: tu n'as pas un container à nous soumettre pour faire des tests ?

      En effet, à la demande générale je vais pousser bientôt une image docker pour ceux qui veulent tester facilement.

      Si ca te tente, tu peux aussi installer les paquets Debian/Ubuntu/Alpine que je compile à chaque release.

      • [^] # Re: Papotages

        Posté par  (site web personnel) . Évalué à 2.

        Ce que OIDC a enlevé par rapport à OAuth2 vanille c'est les response types Resource Owner Password Credentials Grant et Client Credentials Grant.
        Pour être précis ils ne disent pas explicitement "Ne mettez pas ca dans votre OIDC", mais la norme OIDC les ignore, donc on en fait ce qu'on veut.

        Effectivement, je n'avais pas remarqué cette absence dans la norme. Tous les IdP que j'ai utilisés implémentaient les grant_type client_credential et password.

    • [^] # Re: Papotages

      Posté par  (site web personnel) . Évalué à 2. Dernière modification le 11 septembre 2019 à 04:55.

      Une image Docker est prête :
      https://github.com/babelouest/glewlwyd/blob/master/docs/INSTALL.md#docker

  • # keycloak ?

    Posté par  (site web personnel) . Évalué à 6.

    Dans ce domaine, je connais keycloak, qui marche bien mais qui demande de bien connaitre les protocoles et comment les utiliser.

    Qu'apporte Glewlwyd de plus ?

    "La première sécurité est la liberté"

    • [^] # Re: keycloak ?

      Posté par  (site web personnel) . Évalué à 4.

      Je sais pas trop ce qu'il apporte de plus, je connais un peu keycloack mais je ne l'ai jamais utilisé.

      À la louche, je dirais qu'il est moins lourd car Keycloack est écrit en Java alors que Glewlwyd est écrit en C.
      Le paquet d'installation fait ~2.3 Mo et il tourne sans problèmes sur une config minimale type Raspberry Pi Zero pour une utilisation à petite échelle. C'est parce que j'aime le C que j'ai voulu faire ca comme ca.

      Pour les fonctionnalités, notamment quels facteurs d'authentification sont supportés par l'un et pas l'autre, je sais pas vraiment, j'ai pas trouvé la liste complète sur le site de keycloack (j'ai pas cherché sur tout le site non plus)

      Mais je n'ai pas la prétention de remplacer Keycloack, j'ai fait Glewlwyd pour m'amuser et pour répondre à mes besoins.

      • [^] # Re: keycloak ?

        Posté par  (site web personnel) . Évalué à 3.

        J'ai mis keycloak pour un cas d'usage qui me paraissait de base, mais en fait non : une SPA (react.js) qui attaque une API rest. C'est une architecture qui me paraissait standard, sauf que le SPA impose une absence de secret (mode implicit de mémoire) mais que cela pourrait être fait pour protéger les appels à l'api. Mixer les 2 n'a pas l'air prévu de base dans openid.

        "La première sécurité est la liberté"

        • [^] # Re: keycloak ?

          Posté par  (site web personnel) . Évalué à 1.

          Salut,
          tu dois pouvoir faire au authorization end point un responce_type=id_token+token pour obtenir à la fois un id_token pour valider l'authentification coté client et un access_token à faire suivre en header authorization bearer à tes API (mais tu peux aussi ne demander que le token puis faire un appel à ton back qui lui fera un appel au end point user info pour obtenir l'identité de ton utilisateur, ou ne faire que de l'id_token)

          Le problème dans ce scenario étant de rafraichir les jetons sans re passer par la case authorisation.

          Une autre possibilité est de faire du response_type=code avec une url de retour interprété coté back (qui pourra donc garder les jetons) avec en retour par exemple le token qui pourra alors être envoyé au api sous forme d'un header. Quand le token sera expiré, il suffira donc de rappeler l'url qui renouvelle ce dernier grace au refresh_token.

        • [^] # Re: keycloak ?

          Posté par  (site web personnel) . Évalué à 3. Dernière modification le 10 septembre 2019 à 15:35.

          Ton cas d'usage est celui que j'utilise la plupart du temps, mais dans OAuth2/OIDC il faut distinguer deux notions différentes:

          • Le client peut être public ou privé

          Un client privé est un client qui doit s'authentifier sur le serveur OAuth2/OIDC pour faire une demande quelconque, avec un mot de passe, une clé RSA, ou un autre moyen pris en charge par le serveur OAuth2/OIDC. Il doit donc être capable de stocker ladite méthode d'authentification quelque part pour le donner au serveur OAuth2/OIDC à chaque requête.
          Un client public n'a pas besoin de s'authentifier à chaque requête sur le serveur OAuth2/OIDC.
          Je vois souvent les clients OAuth2/OIDC confidentiels qui sont des services web intermédiaires, biens que plein d'autres facons de faire existent.

          Effectivement si ton client est une application javascript s'exécutant sur le navigateur de l'utilsateur (SPA), c'est inutile d'avoir un client confidentiel car avec un simple F12 n'importe quel utilisateur (authentifié ou non) peut accéder au secret du client.

          • Le client peut demander un refresh token ou seulement un access token

          S'il demande un refresh token, le client doit le stocker quelque part pour utiliser le refresh token à chaque besoin, d'autant que le token peut avoir une durée de vie longue, donc faut faire attention à ce que tu en fais.

          Maintenant dans les faits, je ne vois pas de contre indication à utiliser un client public pour demander des refresh token. Si tu as confiance en ton navigateur pour stocker tes cookies de session, éventuellement tes mots de passe, je ne vois pas pourquoi tu ne pourrais pas non plus y stocker tes refresh token, via un cookie ou un stockage local.

          • [^] # Re: keycloak ?

            Posté par  (site web personnel) . Évalué à 1.

            Bien plus belle réponse que la mienne …

          • [^] # Re: keycloak ?

            Posté par  (site web personnel) . Évalué à 3.

            J'ai fais un truc qui ressemble à ça. Mais cela me parait une architecture tellement évidente que je pensais que les serveurs SSO géraient ça de base. Et bien non, il faut savoir si on peux utiliser un code ou pas, une lib qui fait le refresh tout seul ou pas, faire attention au CORS, etc…

            "La première sécurité est la liberté"

            • [^] # Re: keycloak ?

              Posté par  (site web personnel) . Évalué à 1.

              Je pense qu'on peut dire qu'ils le gèrent. Mais il faut bien voire qu'avec les applications SPA, on se retrouve dans le contexte d'une application qui fonctionne en local avec toutes les contraintes de sécurité que cela entraine en terme de sécurité (idem que les applications mobiles et bureaux).

              Dans le cas de keycloak, il y a plein solution disponible out-of-the-box. Par exemple pour javascript mais aussi pour node.js. Le principe étant d’énormément faciliter le travail aux développeurs. L’inconvenant de ces solutions, c'est qu'elles sont parfois spécifique à keycloak (fichier de configuration json spécifique, utilise le fait que l'access_token est lui aussi jwt,…) et sont donc non compatible avec une autre solution.

    • [^] # Re: keycloak ?

      Posté par  . Évalué à 2.

      Même question, mais avec Gluu.

      • [^] # Re: keycloak ?

        Posté par  (site web personnel) . Évalué à 3.

        Ah là j'ai trouvé la doc qui détaille les fonctionnalités!

        Basic Authentication

        J'ai ca, LDAP ou base de données. Pour MySQL et Postgre j'utilise les fonctions built-in pour stocker des mots de passe, pour SQLite3 j'encode en pbkdf2 via GnuTLS.
        J'ai même la possibilité d'authentifier un utilisateur via un service HTTP tiers qui ferait du Basic authentication.

        FIDO U2F et FIDO 2.0

        J'ai ca via Webauthn, avec en plus le support des lecteurs d'empreinte digitale dans Android.

        Super Gluu

        J'ai pas ca mais ca m'amuserait d'en faire un

        OTP Apps

        J'ai ca

        SMS OTP

        J'ai pas ca mais j'ai E-Mail OTP

        Inbound OAuth & OpenID

        J'ai ca

        Inbound SAML

        J'ai pas ca. Je voulais le faire au début mais je ne connais pas SAML, et en lisant la doc, il m'a l'air pas mal compliqué, le jeu n'en valait pas la chandelle en tout cas pour le moment.
        Cela dit, quelqu'un de motivé peut très bien créer un plugin qui fera de l'authentification SAML.

        Duo Security

        J'ai pas ca

        ThumbSignIn

        J'ai pas ca

        Certificate Authentication

        J'ai ca

        Account Lockout

        J'ai ca mais il faut un admin pour désactiver un compte

        Forgot Password

        J'ai pas ca mais c'est relativement facile à faire

        Custom Script Tutorial

        J'ai pas fait de SDK pour scripter les accès à Glewlwyd mais toute l'API REST est documentée.

        • [^] # Re: keycloak ?

          Posté par  (site web personnel) . Évalué à 3.

          Petit erratum.

          Inbound OAuth & OpenID

          J'ai ca

          Non j'ai pas en vrai, je supporte les protocoles OpenID et OAuth2 mais je ne permets pas de m'authentifier sur un autre SSO

    • [^] # Re: keycloak ?

      Posté par  . Évalué à 2.

      Dans ce domaine, il y a également dex qui est sympa.

  • # Authentification TLS

    Posté par  . Évalué à 1.

    Pour l'authentification par certificat, c'est effectivement un peu contraignant. Surtout tel que tu l'utilise, pour authentifier l'utilisateur sur le serveur d'identité.

    Moi je l'aurais plutôt vu au même niveau qu'un Oauth2 ou OpenID, voir simplement à la place d'un JWT: ton serveur d'authentification émet des certificats qui peuvent ensuite être présentés pour accéder aux services.

    Mais dans ton cas, pour l'utiliser pour t'authentifier sur le serveur d'identification, tu pourrais imaginer émettre deux certificats : un pour l'authentification et l'autre pour le renouvellement, de durée de validité un peu plus longue, à la manière d'Oauth2…

    Sinon, tu aurais une instance de test ou un exemple de certificat émis, histoire d'en regarder les champs ?

    • [^] # Re: Authentification TLS

      Posté par  (site web personnel) . Évalué à 2.

      Je ne pense pas que son but est de faire une PKI en émettant lui même des certificats, mais de truster des CA déjà existantes pour authentifier les utilisateurs pourvus de tels certificats, par exemple issue une PKI d'entreprise (qui peuvent servir par ailleurs pour les accès VPN ou être déployé sur les mobiles d'entreprise via leur mdm).

      A noter que pour cela il faut que le serveur soit en terminaison TLS. Dans beaucoup de cas, les serveurs d'authentifications sont aussi capable de lire l'information du certificat dans un header transmit par un élément en frontal (par exemple un apache ou un ngnix) qui lui fait une première vérification du certificat (CA, CRL,…)

      • [^] # Re: Authentification TLS

        Posté par  (site web personnel) . Évalué à 2.

        J'aimerais bien pouvoir émettre des certificats depuis Glewlwyd pour que l'utilisateur l'installe facilement sur son navigateur mais je n'ai pas encore compris comment générer un PKS#12 avec GnuTLS.
        Je peux le faire avec certtools ou openssl mais je préfère le faire avec la librairie GnuTLS toute seule (C'est celle que j'utilise dans Glewlwyd).

        Après, comme je disais, je ne suis pas un expert de l'authentification TLS cert donc y'a encore des trucs qui m'échappent.
        Mais si je dis pas de conneries, la validation du certificat est faite en amont par le framework HTTP, et Glewlwyd récupère le certificat du client si celui-ci est validé avec le CA qu'on a spécifié.
        De fait, Glewlwyd se contente d'enregistrer les certificats des clients et de dire si oui ou non le certificat est connu. Pour l'instant il ne fait pas d'autres vérifications car je ne sais pas comment est validé un certificat TLS chez ceux qui le font, d'où mon appel à l'aide.

    • [^] # Re: Authentification TLS

      Posté par  (site web personnel) . Évalué à 2.

      Salut,

      J'ai peut-être trouvé ce qui me manquait pour émettre des PKCS#12 à la volée, donc je vais essayer de placer ca dans la RC2.

      Mais de ce que j'ai compris sur les certificats X509, ils stockent les informations suivantes:
      - Clé publique (évidemment)
      - Date d'émission
      - Date d'expiration
      - Numéro de série
      - DN du certificat
      - DN du signataire du certificat

      Le seul sur lequel je ne sois pas sûr c'est le DN du certificat, comment est-il construit en général?

      Je me mets à la place de l'admin qui paramètre son générateur de certificat.
      Est-ce que le DN du certificat doit piocher ses paramètres dans les données de l'utilisateur genre cn=<son nom>,ou=<son groupe>,dc=plop,dc=grut?
      Est-ce qu'il doit construire le DN en utilisant un format beaucoup plus rigide, comme cn=<chiffre random>,ou=coin,dc=plop,dc=grut?

      Est-ce que je dois permettre à l'admin de contrôler très finement tous les paramètres ou pas tant que ca?

  • # Commentaire inutile

    Posté par  (site web personnel) . Évalué à 6.

    Oui, mon commentaire est inutile, mais merci, sans le savoir, tu m'as enfin permis de retrouver le logiciel SSO qui m'intéressait mais dont je n'arrivais plus à retrouver le nom depuis des semaines (me souvenant juste qu'il y avait un rapport avec une mythologie, je ne savais plus laquelle)

    À chaque fois je tombais sur Gluu et Keycloack mais jamais Glewlwyd…

  • # SSO et autorisation en mode fédéré : possible ?

    Posté par  (site web personnel) . Évalué à 2. Dernière modification le 10 septembre 2019 à 16:23.

    Bonjour,

    Intro :
    Je travaille en tant que professionnel sur le projet SEN2, la suite du projet SEN1 (voir : https://github.com/consometers/sen1-poc-docs) et en tant que bénévole dans le collectif des Consometers (voir https://wiki.consometers.org/doku.php).
    On travaille sur l'échange de données énergétiques (et plus) en mode fédéré. Nous avons fait un POC en nous basant sur le protocole XMPP. Nous avons eu à utiliser Oauth2 pour l'autorisation de récupération des données de compteurs connectés.

    Réflexions :
    Pendant ce POC, nous avons réfléchi au RGPD et à comment fournir une base de services d'infra qui simplifie le travail d'implémentation d'un nœud dans la fédération. Une des solutions retenue est l'autorisation décentralisée, via des protocoles comme Oauth2 ou OIDC. MAIS ces protocoles nécessitent des paramètres amont (ex : URL du fournisseur de données pour la demande d'autorisation).

    Question :
    On commence à peine à s'y mettre et on est loin d'être expert dans le domaine de la SSO et de l'autorisation décentralisée. Mais à l'instar de XMPP, y aurait il une méthode infrastructurelle qui permettrait de nous affranchir d'un paramétrage spécifique pour chaque service dont l'autorisation est nécessaire ? Je m'explique, pour XMPP, on envoie un message à plop@superweb.org. Le client envoie le message au serveur. Le serveur cherche l'entrée SRV du domaine superweb.org correspondant au service XMPP. Le serveur XMPP se connecte sur le serveur du domaine superweb.org et lui transfert le message.
    Est-ce qu'il y aurait déjà une méthode de ce type pour OIDC ou Oauth2 ? Si non, est ce que ce serait pertinent d'en créer une ?
    Nous voulons faire sen sorte que les échanges de données entre applications soient fluides, nous voulons tracer les autorisations, et tout ça dans un mode fédéré. Merci d'avance pour vos avis éclairés !

    PS : merci de partager ton projet !

    • [^] # Re: SSO et autorisation en mode fédéré : possible ?

      Posté par  (site web personnel) . Évalué à 2.

      TL;DR: Tu peux peu-être utiliser les response type client credential ou password dans OAuth2 pour répondre à ton besoin mais je ne suis pas sûr de l'avoir totalement compris.

      On travaille sur l'échange de données énergétiques (et plus) en mode fédéré

      Mais encore? Plus précisément qui échange avec qui?
      Est-ce que ce sont des systèmes embarqués qui récoltent des données puis les poussent sur un service distant ou des services distribués?
      Est-ce que ce sont des utilisateurs avec leur téléphone intelligent qui se connectent dans une app et qui rentrent des données à la main?
      Autre chose?

      nous avons réfléchi au RGPD

      Quel est l'impact du RGPD dans ton cas?

      ces protocoles nécessitent des paramètres amont

      Plus précisément, ces protocoles nécessitent que les clients et les utilisateurs soient préalablement connus du serveur d'authentification. Mais je ne comprends pas ton besoin, donc je ne peux pas te dire si tu es dans le champ ou pas.

      Nous voulons faire sen sorte que les échanges de données entre applications soient fluides, nous voulons tracer les autorisations

      Dans un contexte à base d'API REST, je verrais quelque chose comme ca:

      Chaque application est connue du serveur OAuth2 par un identifiant/mot de passe.
      Il existe un ou plusieurs services REST qui ont pour tâche de te renvoyer un JWT signé contenant les données que tu lui as fournies. Seuls ces services REST connaissent les clés privées pour signer les messages, mais les clés publiques sont publiques justement, donc n'importe qui (n'importe quel noeud) peut vérifier la signature pour s'assurer que ledit message est bien valide, et résoudre une partie du problème des généraux byzantins: le message n'a pas été altéré pendant le transport.

      Lorsqu'une application souhaite envoyer un message aux noeuds, elle se connecte au serveur OAuth2, lui réclame un access token en utilisant son identifiant/mot de passe.
      Le message non signé est transmis au service REST de signature qui lui renvoie le message signé sous forme de JWT
      Le message signé est enfin prêt à être distribué via XMPP ou tout autre moyen aux autres noeuds qui n'auront qu'à vérifier la signature tout seuls.

      Bonus: les response type client credential ou password ne nécessitent pas d'url de retour.

      • [^] # Re: SSO et autorisation en mode fédéré : possible ?

        Posté par  (site web personnel) . Évalué à 1.

        Merci d'avoir répondu si rapidement et merci pour ton aide !

        Mais encore? Plus précisément qui échange avec qui?

        J'aurais dû donner plus de détails désolé.
        La on réfléchit en terme d'applications qui discutent à travers une architecture fédérée (ni centralisée, ni pair à pair). On voudrait garder le même avantage que XMPP : ne pas avoir à configurer quoi que ce soit pour que les applications puissent discuter entre elles. Et c'est le cas avec notre POC puisque nos applications utilisent le protocole XMPP.
        On sort le cas de l'IoT et de l'acquisition de données de l'équation pour le moment (mais on garde ça dans un coin de notre tête).

        Scénario complexe (car tripartite) :
        - l'appli A possède des données de courbes de charges d'énergie.
        - l'utilisateur final a un compte sur une appli C qui permet d'afficher de jolies courbes sur une GUI WEB
        - l'appli C utilise une appli B pour récolter les données de l'appli A, les stocker et les traiter (ex : fournir à la demande des jeux de données minimaux à l'appli C pour afficher un graphe entre telle date et telle date, autre exemple : envoyer une alerte à l'appli B quand il n'y a plus du tout de consommation électrique dans un cas de coupure de disjoncteur différentiel par exemple)
        Un scénario plus simple serait que l'appli C fasse le boulot de l'appli B elle même, et ce sera possible techniquement. Mais on ne s'empêche pas d'avoir des relations multiple. L'idée finale est de pouvoir faire en sorte qu'une appli ait accès à N jeux de données de N applications ET d'avoir un chaînage avec N applications pour pouvoir créer ou répondre à de nouveaux usages avec des données multiples.
        Un exemple concret du POC est expliqué p10 du rapport de conclusion du POC (voir : rapport_conclusion.pdf). La figure 1 représente des échanges entre applications. Les applications n'ayant pas été prévus pour se "brancher" directement en fédération, nous avons ajouté des composants d'interface que l'on a appelé "proxy de données"

        Quel est l'impact du RGPD dans ton cas?

        Nous avons fait une étude non experte sur le RGPD appliqué au cadre d'une architecture fédérée. Voir : Rapport-RGPD.pdf. Ce qu'il en ressort c'est que l'on a tout intérêt à prévoir des mécanismes les plus automatisés possibles pour aider les applications à être en conformité (voir les encadrés "recommandations" dans le rapport). Ce que l'on a vu également c'est que le lien contractuel (ou non) joue beaucoup sur les responsabilités entre applications qui échangent des données. Un appli (et donc un organisme) peut être considérée comme co-traitante, sous-traitante ou indépendante. Nous allons contacter la CNIL et/ou le Pôle d'excellence cyber de Bretagne pour avoir des éclaircissements sur le sujet.

        Chaque application est connue du serveur OAuth2 par un identifiant/mot de passe.

        Du coup, ce paradigme n'est pas souhaitable. Le besoin c'est de faire de l'autorisation avec un serveur "que l'on ne connaît pas encore". Le but étant que les utilisateurs donnent leur consentement pour tout échange/traitement de données. Dans le scénario complexe exposé ci-dessus, l'utilisateur donne son consentement dans l'appli C (GUI WEB) pour que cette dernière traite/affiche ses données. Puis on imagine que l'appli C va utiliser Oauth2 ou OIDC avec l'appli A (source des données). Mais après, l'appli B doit avoir le consentement de l'utilisateur pour aller chercher les données de l'appli A… Et tout ça sans configuration préalable (sauf à avoir une sorte de catalogue central, chose que l'on aimerait éviter car on ne veut pas ajouter une composante centralisée…). Et c'est là que je ne vois pas comment y arriver.
        Nous avons regardé oAuth2 et nous avons implémenté la partie "client" pour récupérer des données auprès d'une application du type A justement :-) Et je pense que je vais devoir potasser sérieusement avant d'aller plus loin. Tu aurais des documentations à me conseiller ou c'est préférable que j'aille voir directement aux sources :
        - https://openid.net/connect/
        - https://tools.ietf.org/html/rfc6749

        PS : j'ai déterré ça : https://linuxfr.org/news/authentifiez-vous-sans-mot-de-passe-grace-a-xmpp, ça va peut être m'intéresser pour les authentifications entre applis…

        • [^] # Re: SSO et autorisation en mode fédéré : possible ?

          Posté par  (site web personnel) . Évalué à 1.

          après une lecture très rapide de ton post assez dense :

          • il n'y a pas de découverte ne OIDC mais la auto enregistrement est présent dans la norme. Normalement une application qui à l'url du well-known/openid_configuration à tout ce dont elle à besoin à disposition.

          • ton cas d'usage m'a fait pensé à UMA

          • [^] # Re: SSO et autorisation en mode fédéré : possible ?

            Posté par  (site web personnel) . Évalué à 2.

            Merci d'avoir pris le temps de me lire :-)
            J’essaye de faire des explications claires mais ça prends plus de caractères :-)

            Auto-enregistrement : on regardera ça de près
            UMA : bien sympathique, je me suis cramé des neurones, ça va peut être nous servir.

            Merci pour tes retours !

        • [^] # Re: SSO et autorisation en mode fédéré : possible ?

          Posté par  (site web personnel) . Évalué à 2.

          OK alors tel que tu le décris, dans un contexte OAuth2 (ou OIDC ca marche aussi), ca m'a l'air de ressembler à ca:

          • L'appli A est un service web qui utilise des access_token pour authentifier les accès pour envoyer ses données via une requête HTTP REST.
            Comment l'appli A récupère ses données et comment elle les stocke est hors scope du problème.
            Il existe plusieurs applis A différentes qu'on va appeler A1, A2, A3, etc. Le nombre de A varie dans le temps.

          • L'appli C est un client OAuth2, celle-ci va chercher un access_token au nom d'un utilisateur connecté pour aller faire des requêtes sur l'appli A
            L'appli C doit être préalablement inscrite sur le serveur OAuth2 pour être autorisée à aller chercher des access tokens, mais c'est moins grave parce que le nombre de C m'a l'air moins variable que le nombre de A.

          Glewlwyd utilise des JWT comme access_token, ce qui permet à A de valider la validité des access tokens tout seul, en validant la signature dudit JWT.

          Si tu veux que l'utilisateur donne explicitement son consentement à C l'autorisation d'accéder aux applis A, il faut assigner à chaque A un scope différent, ce qui permettra dans Glewlwyd d'avoir des access_token pour un ensemble de scopes correspondant à ceux autorisés par l'utilisateur pour le client.
          Tu peux créer dans le serveur OAuth2 un grand nombre de scopes pour permettre aux nouveaux A qui arrivent dans la fédération de se voir assigner un scope que pour lui.

          Faut comprendre que dans ce que je viens de décrire, les A ne s'authentifient pas ni n'authentifient personne. Ils se contentent de fournir des données à un client C qui a un access_token valide, c'est à dire avec une signature et un scope valides.

          Aussi, le serveur OAuth2 est seul donc un joyeux SPOF (single point of failure). Tu peux contourner ca en prévoyant plusieurs serveurs OAuth2 qui partageront la même configuration ce qui leur permettra de fournir des access tokens compatibles, mais il faudra permettre à C de connaitre l'ensemble de serveurs OAuth2 disponibles.

          Mathieu a mentionné UMA, ca peut aussi répondre à ton problème mais je ne connais pas.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.