Le langage C est à la base standardisé par l'ANSI.
Depuis la première version mainstream du standard, la C89 (en 1989), d'autres versions lui ont succédé: C90, C95, C99, C11 et plus récemment C17.
Actuellement, la prochaine version est en cours de rédaction, la C2x qui sera probablement la C23.
La plupart du temps, les nouvelles versions du standard ne changent rien de fondamental, mais ajoutent des précisions, ou normalisent certaines façons de faire qui existent par ailleurs.
Par exemple le C23 va probablement inclure dans le standard les fonctions comme strdupstrndup ou memcpy, ajouter les macros #elifdef et #elifndef, ou encore permettre d'initialiser à 0 une structure avec {}:
struct_toto{inta;char*b;void*c;};struct_totototo={};// au lieu de memset(&toto, 0, sizeof(struct _toto));
J'imagine déjà les autres langages regarder ça et dire "Meh", mais moi je trouve ca cool de voir ce langage continuer son chemin à son rythme, sans écouter les railleries de ce qui ne le connaissent pas, ni dénigrer les autres langage.
[Mavie]
De mon coté j'ai installé un serveur VPN Wireguard avec PiVPN sur un VPS que je loue, un serveur de mon réseau local est branché sur le VPN, et ca me permet d'accéder à mon réseau local depuis n'importe quelle machine, pourvu qu'elle soit connectée au VPN. L'avantage est quand je suis hors de chez moi, je peux accéder à mon réseau, mais je n'ai plus de serveur ssh ouvert sur le monde, ca calme les logs…
Le client wireguard pour android juste marche, et sur mon laptop j'utilise deux fichiers de config wireguard avec la même clé:
- un où le VPN est full: tout mon flux réseau passe par le VPN, le DNS est changé, etc.
- un où le VPN ne me permet que d'accéder aux machines connectées sur le VPN, le reste du traffic réseau passe par la connexion internet normale
D'un point de vue hyper pas objectif, OpenVPN m'avait rebuté parce que je trouvais la configuration pas facile, mais à sa décharge, PiVPN le supporte aussi, donc ca doit être faisable finalement.
Par contre, wireguard dans PiVPN m'a agréablement surpris par le coté juste marche
[/Mavie]
Je veux bien décentraliser toutes les forges mais l'avantage des deux gros c'est quand meme de fournir une plate-forme commune et que tout plein de gens connaît, sait utiliser, et utilise.
Quand tu es un gros projet mainstream comme Gnome, le kernel ou Gimp, tu peux te permettre d'héberger ta forge sur tes serveurs, mais quand tu es petit, c'est quand meme plus pratique de bénéficier de l'affluence des grosses forges pour échanger et communiquer.
Éventuellement, il faudrait qu'il existe une sorte de "fédération de forges", qui permette de ne pas avoir à créer un compte sur chaque forge décentralisée, et éventuellement de créer des forges spécialisées. Mais bon, yaka…
C'est vrai, mais c'est malheureusement le cas pour à peu près n'importe quelle techno qui vit assez longtemps.
Parmi les exemples qui me viennent en tête vite fait:
- IPV4 - IPV6 - IPV10
- FTP - FTPS - SFTP
- OAuth2 - PKCE - introspection/révocation - OIDC - une tétrachiée d'autres trucs
Ca part d'un bon sentiment, le but c'est de limiter la réinvention de la roue puisque tu te bases sur quelque chose d'existant, connu, et déjà déployé.
Par contre sans vraiment t'en apercevoir, tu te retrouves dans un gloubiboulga plus ou moins complexe, ou chacun implémente certaines rustines et pas d'autres, et où tu passes plus de temps à gérer l'intégration que le développement.
J'avance, maintenant si je me connecte sur http://dlfp.lo j'arrive sur la page mais ca me dit:
Migrations are pending. To resolve this issue, run: bin/rails db:migrate RAILS_ENV=development
D'après la doc, je dois lancer docker-compose run linuxfr.org bin/rails db:migrate, sauf que ca me pète une erreur:
$ docker-compose run linuxfr.org bin/rails db:migrate
Starting linuxfrorg_database-test_1 ... done
Starting linuxfrorg_redis_1 ... done
Starting linuxfrorg_database_1 ... done
rails aborted!
StandardError: An error has occurred, all later migrations canceled:
Directly inheriting from ActiveRecord::Migration is not supported. Please specify the Rails release the migration was written for:
class CreateUsers < ActiveRecord::Migration[4.2]
/var/lib/gems/2.3.0/gems/activerecord-5.2.5/lib/active_record/migration.rb:528:in `inherited'/linuxfr.org/db/migrate/20090105233501_create_users.rb:2:in `<main>'[...]
Caused by:
StandardError: Directly inheriting from ActiveRecord::Migration is not supported. Please specify the Rails release the migration was written for:
[...]
Tasks: TOP=> db:migrate
(See full trace by running task with --trace)
Mon outil habituel maintenant c'est le serveur d'authentification parce qu'il sait écrire dans du LDAP. Donc ajouter/modifier/supprimer les utilisateurs se fait directement dans Glewlwyd: exemple 1, exemple 2
Mais sinon quand je dois mettre les mains dans le cambouis je prends ApacheDirectoryStudio.
Si je comprends ta méthode, l'appartenance au groupe est connue dans le claim.
Pour moi il peut y avoir un souci de confidentialité, parce que si je comprends bien, le client connaîtra tous les groupes auquel l'utilisateur appartient, pas uniquement ceux dont il a besoin.
Dans mon cas, les groupes de l'ACL correspondent aux scopes OAuth2 via un mappage dans l'AS qui connait les groupes auxquels l'utilisateur a accès. Les scopes autorisés se retrouvent ainsi dans l'access token, et le RS qui consomme le token pour accéder aux ressources de l'utilisateur saura quels niveaux d'accès sont autorisés pour ce token, donc pour cet utilisateur.
En plus, les scopes autorisés dans le token ne sont pas nécessairement tous les scopes demandés par le client parce qu'il doit passer par plusieurs filtres avant d'atterrir dans le token:
scopes demandés par le client
scopes autorisés pour le client par l'AS
scopes autorisés pour l'utilisateur par l'AS
scopes autorisés par l'utilisateur pour ce client
À la fin, si le client n'a pas accès aux scopes dont il a besoin pour faire son boulot, c'est à lui de gérer l'exception.
Cela dit, OIDC n'est pas nécessaire parce que l'id_token ne sert pas dans ce cas, OAuth2 tout seul fait l'affaire, mais comme OIDC est une surcouche à OAuth2, les deux fonctionnent.
La question qui doit être répondue est la suivante: Le programme X veut accéder aux ressources Y de l'utilisateur Z. Mais il se peut que Z n'ait pas le droit d'accéder à Y tout court, genre l'utilisateur lambda n'a pas le droit d'accéder à la console d'administration, seulement à ses mails et nextcloud. Donc pour permettre ces niveaux d'accès, j'utilise les scopes.
La norme OAuth2 est assez souple sur la nature scope et à quoi il sert. Elle spécifie qu'un ou plusieurs scopes peuvent être associés à un access token mais ne rend pas les scopes obligatoires.
Le client inclus dans sa requête d'authentification la liste des scopes qu'il souhaite avoir, mais peut recevoir une sous-liste partielle des scopes demandés.
Les scopes utilisés pour accéder à des claims est une fonctionnalité propre à OIDC qui permet à un utilisateur d'autoriser ou non le client d'accéder à des données personnelles de l'utilisateur.
En effet, il faut comprendre comme je sécurise mes mots de passe d'application quelque part pour les réutiliser ailleurs, mais rien n'empêche de l'utiliser qu'une fois et d'en générer à chaque fois que tu en as à nouveau besoin.
La page que tu mentionnes est sur le site Debian officiel, les dépôts pour les paquets du support étendu sont hébergés sur les serveurs Debian, je dirais que ca à le goût d'un projet officiel, pour autant que le terme officiel ait du sens.
avec un processus de maintenance différent, par des personnes à priori différente d'après ce qu'ils disent
Le processus est forcément différent, vu que le cycle de vie normal dans Debian n'inclus pas de LTS, il fallait soit changer le processus actuel, soit mettre le Debian LTS en dehors du processus original. Ils ont choisit la deuxième option.
Les personnes sont différentes parce que les mainteneurs d'un paquet ne sont pas nécessairement ni uniquement ceux qui font le support LTS. Des fois oui, des fois non, généralement non.
La grosse différence est qu'un paquet dans le cycle normal est mis à jour par son mainteneur ou son équipe quand le logiciel upstream est mis à jour ou que des bugs dans le paquet sont corrigés, puis ca finit dans testing.
Pour le support LTS, les mises à jour autorisées sont des mises à jour de sécurité principalement (voire uniquement, je suis pas sûr). Donc le numéro de version ne changera pas, seuls des patches seront autorisés, et avec l'autorisation des membres de l'équipe de support LTS, comme c'est le cas pour les patches de sécurité pour Debian stable en fait.
C'est un support volontaire additionnel
Comme le projet Debian dans son ensemble :)
Vu que ce support est plus destiné aux entreprises ou grosses structures qui ne veulent/peuvent pas mettre à jour facilement, ils les encouragent à contribuer ou participer financièrement.
L'ordinateur pourrait au moins faire l'effort d'afficher les caractères tapés au clavier,
C'est tellement 2008…
En plus on n'est pas à l'abri d'un bug dans X11 qui afficherait les caractères sans anti-aliasing alors mon mot de passe moche, non merci.
Par contre je veux bien journaliser les commandes reçues et les actions résultantes, les envoyer dans un SAAS à base de Kafka/Kubernetes pour analyse statistique ultérieure accessible en OpenData, là on tient un killer feature coco!
Dans le paragraphe Attaque de l’homme du milieu, il est écrit:
Il est relativement aisé de procéder à une attaque MITM et ainsi d’accéder au contenu de la communication en clair : votre employeur qui a installé le certificat de son autorité de certification interne sur votre poste (vous chiffrez alors sans le savoir avec la clé de votre employeur…)
Mais pour autant que je sache, un certificat installé sur ton navigateur te permet de déchiffrer uniquement, le chiffrement se fait par le serveur proxy de l'employeur. J'ai bon?
Ma question sur le transactionnel n'était pas à propos de SQL / NoSQL mais plutôt concernant le théorème CAP
OK, alors j'ai lu rapidement la page wikipedia et je dois dire que je suis dans le champ solide!
Ce n'est pas du tout mon domaine, et Glewlwyd n'a pas été concu pour du calcul distribué, ni pour une quelconque répartition de charge.
Si on accepte de faire sauter le C (le coté transactionnel), on peut alors avoir une base répartie clusterisée master master beaucoup plus facilement.
Admettons, mais là on est dans la couche données, pas dans la couche métier. Mais encore là je suis à l'ouest donc je vais éviter de polémiquer pour ne pas dire plein de bêtises.
Par contre je ne vois pas le rapport entre tes explications et un serveur d'API REST qui permet de faire du OAuth2/OpenID Connect. Quel serait l'avantage de ce que tu décris pour Glewlwyd?
Est-ce que ça veut dire que le backend peut fonctionner en utilisant un LDAP existant ?
Oui, on peut même utiliser plusieurs LDAP existants si ca nous chante. La doc que tu pointes est celle pour l'installation du service, pas sa configuration (je vais ajouter une précision)
Le truc qui pourrait manquer aux utilisateurs hardcore de services LDAP, c'est les groupes pour mapper avec les scopes de Glewlwyd.
Je ne l'ai pas fait vu que je ne l'utilse pas moi-même, et que je ne comprends pas bien comment ca marche dans la vraie vie.
Mais si on m'explique ou qu'on me propose un patch, je serai content!
Par contre, Glewlwyd ne permet pas d'ajouter l'authentification OpenID à ton serveur LDAP, mais te permet d'avoir un service d'authentification oidc ou OAuth2 branché sur ton annuaire LDAP pour les informations minimales de tes utilisateurs (login, mot de passe, scopes, e-mail, etc)
Je me pose toujours la question de la pertinence d'une BD qui stocke à la fois des paramètres de config et de session
Et c'est en effet une très bonne question, sauf qu'il faut voir l'application comme une boite noire qui expose une API REST.
J'utilise la BD pour la configuration de certains aspects parce que c'est le meilleur moyen que j'ai trouvé pour avoir une configuration pérenne et dynamique, tout en gardant le principe KISS dans un coin de la tête.
Mais tout ce qui est configuration des modules: CRUD des modules backend utilisateurs ou clients, CRUD des plugins, CRUD des schémas d'authentification, tout se fait via l'interface graphique d'administration, parce que ces parties-là sont plus complexes à configurer et qu'une UI qui t'accompagne en te disant ce que tu as le droit de faire ou non, c'est plus simple à utiliser qu'un fichier de config à plat ou un fichier XML pour lequel il faut lire et comprendre la doc. Ca permet aussi d'avoir plein de modules qui "juste marchent" sans forcément avoir à tout comprendre, typiquement les schémas HOTP/TOTP ou Webauthn.
Ensuite, il faut voir que la config en BD n'est lue qu'au démarrage de l'application, puis "mappée" en mémoire, ou rechargée lorsqu'on modifie la config via les API. Donc la question de distinguer la BD de config de la BD de session ne se pose pas trop non plus je pense.
Et comme toute la config stockée en BD est accédée entièrement via les API REST, tu as la possibilité d'automatiser l'administration via des scripts qui font des appels HTTP à l'ancienne.
A-t-on besoin d'une base de donnée relationnelle, donc avec transaction ?
Ca aussi c'est une bonne question!
Au début de mon ère néo-productiviste libriste avec les API REST en C, je me demandais justement si j'allais pas directement taper sur des bases de données NoSQL comme MongoDB, qui est d'ailleurs un peu la seule que je connais pour l'instant, et encore très peu, plutôt que de rester sur les vieilles techno à grand-papa comme le SQL. À l'époque, j'entendais parler du NoSQL partout sans trop savoir c'est quoi, et moi aussi je voulais être copain avec le nouveau gars cool de l'école.
Sauf que justement je ne connais pas tant que ca le NoSQL, et mon approche de modélisation était et est encore très modèle relationnel. Quand je pense à une structure de données à persister, je vois facilement son schéma SQL dans ma tête. J'aime bien utiliser des technos récentes mais quand c'est justifié, pas juste pour utiliser des trucs hype. J'ai donc préféré rester sur mon approche à l'ancienne qui ne m'a posé aucun problème. Je ne critique même pas le NoSQL, je dis juste que j'en ai pas encore l'utilité.
Les transactions SQL ne sont pas utilisées dans Glewlwyd, l'architecture REST et la façon dont sont identifiées les données permet de l'éviter.
Je ne connais ni Riak, ni Etcd, merci pour l'info.
Dans la mesure où je fais Glewlwyd avant tout pour moi, sur mon temps libre, je préfère utiliser des technos que je connais et que je maîtrise.
Par contre, si quelqu'un me propose un patch ou de l'aide pour migrer sur une autre persistance qu'une base SQL, je suis preneur!
En fait pas besoin, j'avais étendu la notion de machine locale à mon réseau local, donc forcément en me connectant sur l'IP distante ça ne passait pas.
L'url de connexion à l'image docker est mentionnée dans le README.md mais pas dans le INSTALL.md.
Je vais rajouter ca pour expliquer que l'image quickstart est pour localhost seulement, et expliquer la bonne utilisation du external_url. :)
Petite question (qui elle mérite peut-être un ticket), ne serait-il pas intéressant que ce ficher fasse appel à un css custom, vide mais qui peut être modifié par la suite par l'utilisateur?
Oui, tout à fait, je vais même faire mieux parce qu'il y a 3 applis web: admin, login et profile. Je vais donc rajouter un css custom par appli, et un autre global à toutes les applis. Merci pour l'idée!
Pourquoi il a besoin d'une base de données pour fonctionner ?
J'avoue que je ne m'attendais pas à cette question.
Pour faire simple, la base de données stocke au minimum:
- La configuration des modules
- Les hash et métadonnées des session utilisateurs
- Les scopes et leurs facteurs d'authentification
- Les hash de code et de tokens
- Les configs de certains schémas d'authentification pour les utilisateurs
Il aurait pas pu en utiliser une qui soit en cache RAM ?
Entre deux redémarrages du service ou du serveur, il faut stocker un minimum d'informations pour ne pas avoir à perdre toute la config ou les données de session des utilisateurs. Cela dit, si tu veux une BD en RAM, tu peux monter un RAMDisk et y coller le fichier de BD SQLite3. Mais je doute que ca réponde à ton besoin.
Pour la question sur le RGPD, je te laisse juge sur comment l'appliquer, c'est un domaine que je ne connais pas, mais je ne pense pas qu'avoir une base données qui s'efface à chaque redémarrage soit utile.
Autre question, ton service est capable de se clusteriser ?
En utilisant une base de données MariaDB ou PostgreSQL je dirais que oui, au final c'est un simple exécutable qui utilise la BD pour la persistance, donc une session ouverte depuis une instance de serveur Glewlwyd peut être utilisée par une autre instance par exemple. Le seul truc important à penser c'est de relancer le service sur chaque noeud si on a changé la configuration des instances de modules (ajouter ou modifier un schema d'authentification par exemple)
Cela dit je n'ai pas essayé de le clusteriser donc ca se peut qu'il y ait des problèmes auxquels je n'ai pas pensé, dans ce cas je serai ravi de les corriger!
Enfin, il faut aussi se poser la question de l'utilité de faire un cluster.
Un serveur SSO est finalement peu sollicité en moyenne. Je suis un petit utilisateur de mon application donc chez moi ca tournerait sans problèmes sur un Raspberry Pi Zero, bien qu'il tourne en fait sur un Odroid C2.
Si c'est pour répartir la charge ok, mais dans ce cas je suis curieux, pour combien d'utilisateurs et de clients?
Anéfé, le lien que je donne n'est pas valide dans tous les cas, si un modo veut bien le corriger.
Error connecting to Glewlwyd API
Là par contre je ne comprends pas. Si tu utilises la commande docker run --rm -it -p 4593:4593 babelouest/glewlwyd et que tu as ce résultat-là c'est un problème que je ne connaissais pas. Peux-tu ouvrir un bug pour essayer de corriger ca?
# Un langage qui avance, tranquillement, à son rythme
Posté par Babelouest (site web personnel) . En réponse au journal C, un âge remarquable. Évalué à 10.
Le langage C est à la base standardisé par l'ANSI.
Depuis la première version mainstream du standard, la C89 (en 1989), d'autres versions lui ont succédé: C90, C95, C99, C11 et plus récemment C17.
Actuellement, la prochaine version est en cours de rédaction, la C2x qui sera probablement la C23.
La plupart du temps, les nouvelles versions du standard ne changent rien de fondamental, mais ajoutent des précisions, ou normalisent certaines façons de faire qui existent par ailleurs.
Par exemple le C23 va probablement inclure dans le standard les fonctions comme
strdupstrndupoumemcpy, ajouter les macros#elifdefet#elifndef, ou encore permettre d'initialiser à 0 une structure avec{}:J'imagine déjà les autres langages regarder ça et dire "Meh", mais moi je trouve ca cool de voir ce langage continuer son chemin à son rythme, sans écouter les railleries de ce qui ne le connaissent pas, ni dénigrer les autres langage.
Longue vie au C!
[^] # Re: pourquoi openvpn ?
Posté par Babelouest (site web personnel) . En réponse au journal Installation d'un réseau VPN. Évalué à 5. Dernière modification le 26 juillet 2021 à 15:35.
[Mavie]
De mon coté j'ai installé un serveur VPN Wireguard avec PiVPN sur un VPS que je loue, un serveur de mon réseau local est branché sur le VPN, et ca me permet d'accéder à mon réseau local depuis n'importe quelle machine, pourvu qu'elle soit connectée au VPN. L'avantage est quand je suis hors de chez moi, je peux accéder à mon réseau, mais je n'ai plus de serveur ssh ouvert sur le monde, ca calme les logs…
Le client wireguard pour android juste marche, et sur mon laptop j'utilise deux fichiers de config wireguard avec la même clé:
- un où le VPN est full: tout mon flux réseau passe par le VPN, le DNS est changé, etc.
- un où le VPN ne me permet que d'accéder aux machines connectées sur le VPN, le reste du traffic réseau passe par la connexion internet normale
D'un point de vue hyper pas objectif, OpenVPN m'avait rebuté parce que je trouvais la configuration pas facile, mais à sa décharge, PiVPN le supporte aussi, donc ca doit être faisable finalement.
Par contre, wireguard dans PiVPN m'a agréablement surpris par le coté juste marche
[/Mavie]
[^] # Re: "panne mondiale"
Posté par Babelouest (site web personnel) . En réponse au journal Gitlab, Github & Stackoverflow sont inaccessibles simultanément. Évalué à 8.
Je veux bien décentraliser toutes les forges mais l'avantage des deux gros c'est quand meme de fournir une plate-forme commune et que tout plein de gens connaît, sait utiliser, et utilise.
Quand tu es un gros projet mainstream comme Gnome, le kernel ou Gimp, tu peux te permettre d'héberger ta forge sur tes serveurs, mais quand tu es petit, c'est quand meme plus pratique de bénéficier de l'affluence des grosses forges pour échanger et communiquer.
Éventuellement, il faudrait qu'il existe une sorte de "fédération de forges", qui permette de ne pas avoir à créer un compte sur chaque forge décentralisée, et éventuellement de créer des forges spécialisées. Mais bon, yaka…
[^] # Re: le web devient monstrueux
Posté par Babelouest (site web personnel) . En réponse à la dépêche Communiquer avec le serveur depuis un navigateur Web : XHR, SSE et WebSockets. Évalué à 4.
C'est vrai, mais c'est malheureusement le cas pour à peu près n'importe quelle techno qui vit assez longtemps.
Parmi les exemples qui me viennent en tête vite fait:
- IPV4 - IPV6 - IPV10
- FTP - FTPS - SFTP
- OAuth2 - PKCE - introspection/révocation - OIDC - une tétrachiée d'autres trucs
Ca part d'un bon sentiment, le but c'est de limiter la réinvention de la roue puisque tu te bases sur quelque chose d'existant, connu, et déjà déployé.
Par contre sans vraiment t'en apercevoir, tu te retrouves dans un gloubiboulga plus ou moins complexe, ou chacun implémente certaines rustines et pas d'autres, et où tu passes plus de temps à gérer l'intégration que le développement.
[^] # Re: Rails ne dépend plus de mimemagic
Posté par Babelouest (site web personnel) . En réponse à l’entrée du suivi Le script de build docker-compose de linuxfr n'est pas à jour. Évalué à 3 (+0/-0).
Merci beaucoup, je suis en business maintenant!
[^] # Re: Rails ne dépend plus de mimemagic
Posté par Babelouest (site web personnel) . En réponse à l’entrée du suivi Le script de build docker-compose de linuxfr n'est pas à jour. Évalué à 2 (+0/-0). Dernière modification le 13 avril 2021 à 15:53.
Au temps pour moi, j'avais pas vu ca.
J'avance, maintenant si je me connecte sur http://dlfp.lo j'arrive sur la page mais ca me dit:
D'après la doc, je dois lancer
docker-compose run linuxfr.org bin/rails db:migrate, sauf que ca me pète une erreur:Merci de ton aide déjà!
[^] # Re: Rails ne dépend plus de mimemagic
Posté par Babelouest (site web personnel) . En réponse à l’entrée du suivi Le script de build docker-compose de linuxfr n'est pas à jour. Évalué à 2 (+0/-0).
Cool, le docker-compose build bien maintenant avec le patch!
par contre c'est quoi la bonne adresse pour atteindre le site de dev? parce que http://localhost est vide, et si j'essaie http://localhost/dlfp ou http://localhost/linuxfr ou autre, ca donne rien…
[^] # Re: 51 tests en erreur
Posté par Babelouest (site web personnel) . En réponse au journal Compilation de curl 7.75 sur Debian Bullseye. Évalué à 5.
Je ne vois pas de mention de locale imposée dans le README des tests.
À mon avis ça mériterait d'ouvrir un rapport de bug…
[^] # Re: Outil de gestion OpenLDAP
Posté par Babelouest (site web personnel) . En réponse au journal Comment j'ai (presque) réussi à ne plus retenir de mot de passe pour mes services en ligne. Évalué à 3.
Mon outil habituel maintenant c'est le serveur d'authentification parce qu'il sait écrire dans du LDAP. Donc ajouter/modifier/supprimer les utilisateurs se fait directement dans Glewlwyd: exemple 1, exemple 2
Mais sinon quand je dois mettre les mains dans le cambouis je prends ApacheDirectoryStudio.
[^] # Re: Scope
Posté par Babelouest (site web personnel) . En réponse au journal Comment j'ai (presque) réussi à ne plus retenir de mot de passe pour mes services en ligne. Évalué à 3.
Si je comprends ta méthode, l'appartenance au groupe est connue dans le claim.
Pour moi il peut y avoir un souci de confidentialité, parce que si je comprends bien, le client connaîtra tous les groupes auquel l'utilisateur appartient, pas uniquement ceux dont il a besoin.
Dans mon cas, les groupes de l'ACL correspondent aux scopes OAuth2 via un mappage dans l'AS qui connait les groupes auxquels l'utilisateur a accès. Les scopes autorisés se retrouvent ainsi dans l'access token, et le RS qui consomme le token pour accéder aux ressources de l'utilisateur saura quels niveaux d'accès sont autorisés pour ce token, donc pour cet utilisateur.
En plus, les scopes autorisés dans le token ne sont pas nécessairement tous les scopes demandés par le client parce qu'il doit passer par plusieurs filtres avant d'atterrir dans le token:
À la fin, si le client n'a pas accès aux scopes dont il a besoin pour faire son boulot, c'est à lui de gérer l'exception.
Cela dit, OIDC n'est pas nécessaire parce que l'id_token ne sert pas dans ce cas, OAuth2 tout seul fait l'affaire, mais comme OIDC est une surcouche à OAuth2, les deux fonctionnent.
[^] # Re: Scope
Posté par Babelouest (site web personnel) . En réponse au journal Comment j'ai (presque) réussi à ne plus retenir de mot de passe pour mes services en ligne. Évalué à 4.
C'est un choix d'implémentation.
La question qui doit être répondue est la suivante: Le programme X veut accéder aux ressources Y de l'utilisateur Z. Mais il se peut que Z n'ait pas le droit d'accéder à Y tout court, genre l'utilisateur lambda n'a pas le droit d'accéder à la console d'administration, seulement à ses mails et nextcloud. Donc pour permettre ces niveaux d'accès, j'utilise les scopes.
La norme OAuth2 est assez souple sur la nature scope et à quoi il sert. Elle spécifie qu'un ou plusieurs scopes peuvent être associés à un access token mais ne rend pas les scopes obligatoires.
Le client inclus dans sa requête d'authentification la liste des scopes qu'il souhaite avoir, mais peut recevoir une sous-liste partielle des scopes demandés.
Les scopes utilisés pour accéder à des claims est une fonctionnalité propre à OIDC qui permet à un utilisateur d'autoriser ou non le client d'accéder à des données personnelles de l'utilisateur.
[^] # Re: Mot de passe applicatifs NC
Posté par Babelouest (site web personnel) . En réponse au journal Comment j'ai (presque) réussi à ne plus retenir de mot de passe pour mes services en ligne. Évalué à 3.
En effet, il faut comprendre comme je sécurise mes mots de passe d'application quelque part pour les réutiliser ailleurs, mais rien n'empêche de l'utiliser qu'une fois et d'en générer à chaque fois que tu en as à nouveau besoin.
[^] # Re: Et pour les options de ligne de commande ?
Posté par Babelouest (site web personnel) . En réponse au journal rsync. Évalué à 3.
"dash"
[^] # Re: Pas sûr de comprendre le problème…
Posté par Babelouest (site web personnel) . En réponse au journal Linux ne m'intéresse plus. Évalué à 3.
Pour avoir domotisé à la main je confirme que c'est une rêve de geek, mais une fois que tu as les outils, tu trouves plein d'idées à automatiser:
Je suis d'accord que la domotique n'a rien de révolutionnaire mais par contre il peut se révéler un bon outil.
[^] # Re: Pourquoi ce titre ?
Posté par Babelouest (site web personnel) . En réponse à la dépêche CentOS se saborde‑t‑elle ?. Évalué à 10.
La page que tu mentionnes est sur le site Debian officiel, les dépôts pour les paquets du support étendu sont hébergés sur les serveurs Debian, je dirais que ca à le goût d'un projet officiel, pour autant que le terme officiel ait du sens.
Le processus est forcément différent, vu que le cycle de vie normal dans Debian n'inclus pas de LTS, il fallait soit changer le processus actuel, soit mettre le Debian LTS en dehors du processus original. Ils ont choisit la deuxième option.
Les personnes sont différentes parce que les mainteneurs d'un paquet ne sont pas nécessairement ni uniquement ceux qui font le support LTS. Des fois oui, des fois non, généralement non.
La grosse différence est qu'un paquet dans le cycle normal est mis à jour par son mainteneur ou son équipe quand le logiciel upstream est mis à jour ou que des bugs dans le paquet sont corrigés, puis ca finit dans testing.
Pour le support LTS, les mises à jour autorisées sont des mises à jour de sécurité principalement (voire uniquement, je suis pas sûr). Donc le numéro de version ne changera pas, seuls des patches seront autorisés, et avec l'autorisation des membres de l'équipe de support LTS, comme c'est le cas pour les patches de sécurité pour Debian stable en fait.
Comme le projet Debian dans son ensemble :)
Vu que ce support est plus destiné aux entreprises ou grosses structures qui ne veulent/peuvent pas mettre à jour facilement, ils les encouragent à contribuer ou participer financièrement.
[^] # Re: Pressentiment?
Posté par Babelouest (site web personnel) . En réponse au journal sudo, faille pwfeedback. Évalué à 5.
C'est tellement 2008…
En plus on n'est pas à l'abri d'un bug dans X11 qui afficherait les caractères sans anti-aliasing alors mon mot de passe moche, non merci.
Par contre je veux bien journaliser les commandes reçues et les actions résultantes, les envoyer dans un SAAS à base de Kafka/Kubernetes pour analyse statistique ultérieure accessible en OpenData, là on tient un killer feature coco!
[^] # Re: On s'en fout
Posté par Babelouest (site web personnel) . En réponse à la dépêche Sauvez le .org !. Évalué à 5.
Tiens, encore un qui décide que le fr dans linuxfr.org veut dire France, c'est triste ton avis sur les francophones hors du territoire français…
[^] # Re: Un certificat ne sert-il pas plutôt à déchiffrer?
Posté par Babelouest (site web personnel) . En réponse à la dépêche HTTPS, Tor, VPN : de quoi est‐ce que ça protège exactement ?. Évalué à 3.
Ok pour le fonctionnement du MITM mais c'est la phrase suivante qui me fait tiquer:
Il me semble qu'on déchiffre uniquement avec un certificat, qu'il vienne du site web d'origine ou de l'employeur avec son MITM.
Le chiffrement du flux par le client se fait avec une clé générée aléatoirement lors du début de la session TLS.
# Un certificat ne sert-il pas plutôt à déchiffrer?
Posté par Babelouest (site web personnel) . En réponse à la dépêche HTTPS, Tor, VPN : de quoi est‐ce que ça protège exactement ?. Évalué à 2.
Dans le paragraphe
Attaque de l’homme du milieu, il est écrit:Mais pour autant que je sache, un certificat installé sur ton navigateur te permet de déchiffrer uniquement, le chiffrement se fait par le serveur proxy de l'employeur. J'ai bon?
[^] # Re: Base de données
Posté par Babelouest (site web personnel) . En réponse au journal Sortie de Glewlwyd 2.0, serveur SSO. Évalué à 2.
OK, alors j'ai lu rapidement la page wikipedia et je dois dire que je suis dans le champ solide!
Ce n'est pas du tout mon domaine, et Glewlwyd n'a pas été concu pour du calcul distribué, ni pour une quelconque répartition de charge.
Admettons, mais là on est dans la couche données, pas dans la couche métier. Mais encore là je suis à l'ouest donc je vais éviter de polémiquer pour ne pas dire plein de bêtises.
Par contre je ne vois pas le rapport entre tes explications et un serveur d'API REST qui permet de faire du OAuth2/OpenID Connect. Quel serait l'avantage de ce que tu décris pour Glewlwyd?
[^] # Re: Base de données
Posté par Babelouest (site web personnel) . En réponse au journal Sortie de Glewlwyd 2.0, serveur SSO. Évalué à 4. Dernière modification le 04 novembre 2019 à 21:56.
Oui, on peut même utiliser plusieurs LDAP existants si ca nous chante. La doc que tu pointes est celle pour l'installation du service, pas sa configuration (je vais ajouter une précision)
Une fois que le serveur est lancé, il faut le configurer et c'est expliqué là: https://babelouest.github.io/glewlwyd/docs/GETTING_STARTED.html
Et plus précisément comment configurer un backend LDAP est expliqué là: https://babelouest.github.io/glewlwyd/docs/USER_LDAP.html
Le truc qui pourrait manquer aux utilisateurs hardcore de services LDAP, c'est les groupes pour mapper avec les scopes de Glewlwyd.
Je ne l'ai pas fait vu que je ne l'utilse pas moi-même, et que je ne comprends pas bien comment ca marche dans la vraie vie.
Mais si on m'explique ou qu'on me propose un patch, je serai content!
Par contre, Glewlwyd ne permet pas d'ajouter l'authentification OpenID à ton serveur LDAP, mais te permet d'avoir un service d'authentification oidc ou OAuth2 branché sur ton annuaire LDAP pour les informations minimales de tes utilisateurs (login, mot de passe, scopes, e-mail, etc)
[^] # Re: Base de données
Posté par Babelouest (site web personnel) . En réponse au journal Sortie de Glewlwyd 2.0, serveur SSO. Évalué à 5.
Et c'est en effet une très bonne question, sauf qu'il faut voir l'application comme une boite noire qui expose une API REST.
J'utilise la BD pour la configuration de certains aspects parce que c'est le meilleur moyen que j'ai trouvé pour avoir une configuration pérenne et dynamique, tout en gardant le principe KISS dans un coin de la tête.
Glewlwyd utilise un fichier de config au format libconfig, ce fichier contient la configuration dite statique et hardcore de Glewlwyd, avec notamment l'url externe, le chemin local vers les fichiers statiques du front-end, le chmin local vers les modules ou encore la connexion vers base de données.
Mais tout ce qui est configuration des modules: CRUD des modules backend utilisateurs ou clients, CRUD des plugins, CRUD des schémas d'authentification, tout se fait via l'interface graphique d'administration, parce que ces parties-là sont plus complexes à configurer et qu'une UI qui t'accompagne en te disant ce que tu as le droit de faire ou non, c'est plus simple à utiliser qu'un fichier de config à plat ou un fichier XML pour lequel il faut lire et comprendre la doc. Ca permet aussi d'avoir plein de modules qui "juste marchent" sans forcément avoir à tout comprendre, typiquement les schémas HOTP/TOTP ou Webauthn.
Ensuite, il faut voir que la config en BD n'est lue qu'au démarrage de l'application, puis "mappée" en mémoire, ou rechargée lorsqu'on modifie la config via les API. Donc la question de distinguer la BD de config de la BD de session ne se pose pas trop non plus je pense.
Et comme toute la config stockée en BD est accédée entièrement via les API REST, tu as la possibilité d'automatiser l'administration via des scripts qui font des appels HTTP à l'ancienne.
Ca aussi c'est une bonne question!
Au début de mon ère néo-productiviste libriste avec les API REST en C, je me demandais justement si j'allais pas directement taper sur des bases de données NoSQL comme MongoDB, qui est d'ailleurs un peu la seule que je connais pour l'instant, et encore très peu, plutôt que de rester sur les vieilles techno à grand-papa comme le SQL. À l'époque, j'entendais parler du NoSQL partout sans trop savoir c'est quoi, et moi aussi je voulais être copain avec le nouveau gars cool de l'école.
Sauf que justement je ne connais pas tant que ca le NoSQL, et mon approche de modélisation était et est encore très modèle relationnel. Quand je pense à une structure de données à persister, je vois facilement son schéma SQL dans ma tête. J'aime bien utiliser des technos récentes mais quand c'est justifié, pas juste pour utiliser des trucs hype. J'ai donc préféré rester sur mon approche à l'ancienne qui ne m'a posé aucun problème. Je ne critique même pas le NoSQL, je dis juste que j'en ai pas encore l'utilité.
Les transactions SQL ne sont pas utilisées dans Glewlwyd, l'architecture REST et la façon dont sont identifiées les données permet de l'éviter.
Je ne connais ni Riak, ni Etcd, merci pour l'info.
Dans la mesure où je fais Glewlwyd avant tout pour moi, sur mon temps libre, je préfère utiliser des technos que je connais et que je maîtrise.
Par contre, si quelqu'un me propose un patch ou de l'aide pour migrer sur une autre persistance qu'une base SQL, je suis preneur!
[^] # Re: Docker
Posté par Babelouest (site web personnel) . En réponse au journal Sortie de Glewlwyd 2.0, serveur SSO. Évalué à 3.
L'url de connexion à l'image docker est mentionnée dans le README.md mais pas dans le INSTALL.md.
Je vais rajouter ca pour expliquer que l'image quickstart est pour localhost seulement, et expliquer la bonne utilisation du
external_url. :)Oui, tout à fait, je vais même faire mieux parce qu'il y a 3 applis web: admin, login et profile. Je vais donc rajouter un css custom par appli, et un autre global à toutes les applis. Merci pour l'idée!
[^] # Re: Base de données
Posté par Babelouest (site web personnel) . En réponse au journal Sortie de Glewlwyd 2.0, serveur SSO. Évalué à 2.
J'avoue que je ne m'attendais pas à cette question.
Pour faire simple, la base de données stocke au minimum:
- La configuration des modules
- Les hash et métadonnées des session utilisateurs
- Les scopes et leurs facteurs d'authentification
- Les hash de code et de tokens
- Les configs de certains schémas d'authentification pour les utilisateurs
Entre deux redémarrages du service ou du serveur, il faut stocker un minimum d'informations pour ne pas avoir à perdre toute la config ou les données de session des utilisateurs. Cela dit, si tu veux une BD en RAM, tu peux monter un RAMDisk et y coller le fichier de BD SQLite3. Mais je doute que ca réponde à ton besoin.
Pour la question sur le RGPD, je te laisse juge sur comment l'appliquer, c'est un domaine que je ne connais pas, mais je ne pense pas qu'avoir une base données qui s'efface à chaque redémarrage soit utile.
En utilisant une base de données MariaDB ou PostgreSQL je dirais que oui, au final c'est un simple exécutable qui utilise la BD pour la persistance, donc une session ouverte depuis une instance de serveur Glewlwyd peut être utilisée par une autre instance par exemple. Le seul truc important à penser c'est de relancer le service sur chaque noeud si on a changé la configuration des instances de modules (ajouter ou modifier un schema d'authentification par exemple)
Cela dit je n'ai pas essayé de le clusteriser donc ca se peut qu'il y ait des problèmes auxquels je n'ai pas pensé, dans ce cas je serai ravi de les corriger!
Enfin, il faut aussi se poser la question de l'utilité de faire un cluster.
Un serveur SSO est finalement peu sollicité en moyenne. Je suis un petit utilisateur de mon application donc chez moi ca tournerait sans problèmes sur un Raspberry Pi Zero, bien qu'il tourne en fait sur un Odroid C2.
Si c'est pour répartir la charge ok, mais dans ce cas je suis curieux, pour combien d'utilisateurs et de clients?
[^] # Re: Docker
Posté par Babelouest (site web personnel) . En réponse au journal Sortie de Glewlwyd 2.0, serveur SSO. Évalué à 3.
Anéfé, le lien que je donne n'est pas valide dans tous les cas, si un modo veut bien le corriger.
Là par contre je ne comprends pas. Si tu utilises la commande
docker run --rm -it -p 4593:4593 babelouest/glewlwydet que tu as ce résultat-là c'est un problème que je ne connaissais pas. Peux-tu ouvrir un bug pour essayer de corriger ca?