L’authentification HTTP via XMPP est une extension du protocole XMPP (XEP).
Elle permet de s’authentifier sur un site Internet sans avoir besoin de mot de passe : le site en question envoie une demande de confirmation à l’utilisateur du compte XMPP qui autorise ou non l’accès.
Des implémentations sont récemment apparues ou en cours, plus de détails en deuxième partie de dépêche.
Introduction
XMPP permet d’authentifier une requête HTTP via XMPP, ou en d’autres termes de valider qu’une requête sur un site web (ou autre) est bien faite par le possesseur d’un identifiant Jabber jid.
Le processus est décrit dans la XEP-0070.
Cette extension (antérieure à OpenID) a l’avantage d’être basée sur un protocole déjà répandu, dont certains serveurs sont très faciles à installer, et qui fourni beaucoup d’autres services (on n’installe pas juste un serveur d’authentification).
Comment ça marche pour l’utilisateur ?
D’un point de vue de l’utilisateur, c’est très simple : lors que l’on visite un site (ou autre), on donne son identifiant XMPP (jid). Le serveur va alors faire une demande qui apparaîtra sur le client XMPP de l’utilisateur, qui peut être sur son bureau, sur un site ouvert à côté, sur son téléphone, etc.
Un code affiché sur le client et le site doit être vérifié (ou entré dans le client selon les implémentations) par l’utilisateur, afin de s’assurer qu’il valide bien sa propre requête.
L’intérêt est multiple : non seulement il n'y pas besoin de retenir un nouveau mot de passe, mais c’est également une sécurité supplémentaire pour qui se connecte depuis un lieu public ou une machine étrangère (bibliothèque, ordinateur d’un ami, etc).
Une implémentation facile
Cette XEP est donc très intéressante. Cependant, elle est relativement difficile à mettre en place si on compare avec un système d’authentification plus classique, car cela nécessite des connaissances sur le protocole XMPP, et implémenter un client qui se chargerait de faire le travail. J’ai donc récemment implémenté cette XEP côté serveur sous la forme d’un composant et essayé de simplifier au maximum son utilisation pour qui voudrait profiter de ce type d’authentification. Il suffit de faire une requête HTTP sur le composant qui s’occupe de toute la partie XMPP. Ensuite, le code de retour de la requête HTTP détermine l’autorisation ou non, donnée par l’utilisateur.
L’avantage de cette implémentation est que l’on peut installer ce service sur une « autorité de confiance » qui dispose d’un serveur XMPP. Ensuite, un site Internet qui voudrait bénéficier de ce système d’authentification sans pour autant se préoccuper du XMPP, a la possibilité de le faire de manière très simple.
Cette implémentation n’entre pas non plus en contradiction avec la nature décentralisée du réseau XMPP. Tout le monde peut installer ce composant sur un serveur XMPP et l’utiliser pour soi. Ce serait bien triste de devoir faire confiance à une seule autorité…
Tour d’horizon des clients compatibles
Certains clients implémentent déjà cette XEP, et d’autres sont en cours d’implémentation :
- Gajim ;
- Salut à Toi ;
- Poezio (en cours) ;
- Psi.
Cependant, un client qui n’implémente pas la XEP n’est pas pénalisé pour autant. Un moyen de secours est prévu dans le standard, mais son implémentation n’est pas obligatoire (c’est au développeur d’en prendre l’initiative, ce qui est le cas pour l’extension susmentionnée). Espérons tout de même que d’autres clients viendront s’ajouter à cette liste, notamment sur appareils portables.
Ci-dessous, deux exemples de clients (Gajim et Salut à Toi) qui reçoivent une demande de confirmation.
Exemple de Gajim
Exemple de Salut à Toi (Primitivus)
Et maintenant ?
Jehan a écrit un plugin WordPress qui implémente cette XEP. Il serait donc intéressant de voir d’autres initiatives de ce genre fleurir, et que des sites Internet emboîtent le pas et mettent en place ce système d’authentification au même titre que l’authentification par Facebook ou OpenID.
Si vous connaissez (ou voulez apprendre) Ruby et si vous voulez contribuer à la fois à DLFP et à XMPP, c’est le moment ! Une entrée de suivi est ouverte pour implémenter l’authentification XMPP sur LinuxFr.org. Avec le composant mentionné plus haut, l’implémentation devrait être relativement aisée. Ceci pourrait inciter d’autres sites Internet à faire de même et amorcer l’effet boule de neige.
Aller plus loin
- XEP-0070 (220 clics)
- Composant serveur (243 clics)
- Plugin WordPress (146 clics)
# Petites questions
Posté par barmic . Évalué à 6.
Je n'ai pas pris le temps de regarder dans les détails, mais ton composant est un client XMPP ? On peut lui faire utiliser un serveur xmpp de notre choix (comme un qu'on installe pas nous) ou bien ?
D'un point de vu sécurité de XMPP, est-ce que ton composant accepte les communications non chiffrées ? Est-ce que la requête passe par le serveur XMPP ou est-ce qu'elle est envoyée directement au client ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Petites questions
Posté par louiz’ (site web personnel) . Évalué à 5.
Dans XMPP, un composant (component, dans la XEP 0114) est un logiciel qui fait office de « plugin » pour un serveur XMPP.
C’est le serveur qui gère les connexions avec l’extérieur, il ne fait que transmettre au composant les messages qui lui sont addressés, puis il (le serveur) renvoie les messages.
C’est donc le serveur lui-même qui gère le chiffrement, et tout le reste.
Le composant, lui, est juste lancé en local, sur la même machine que le serveur, s’y connecte sur un port spécifique (en clair) et gère uniquement les stanzas qui lui sont adressées.
[^] # Re: Petites questions
Posté par Jehan (site web personnel, Mastodon) . Évalué à 4.
Dans XMPP tout est un nœud du réseau:
example.com,blog.example.cometuser@example.com. Tu peux donc lancer des messages XMPP depuis n'importe lequel de ces nœuds.Comme dit Louiz', un composant, c'est une sorte de "plugin" du serveur pour lui rajouter des fonctionnalités. Si ton serveur est
example.com, un composant aura donc le droit d'envoyer des messages au nom deexample.com(ensuite ça dépend de ta configuration: parfois tu veux plutôt donner un sous-domaine pour un composant, mais souvent tu peux aussi bien lui donner le droit d'agir au nom du domaine principal).Une fonctionnalité comme l'identification par XMPP peut se lancer de n'importe quel nœud du réseau. Ainsi si tu as un blog perso, tu peux utiliser un compte
mon-blog@example.comqui sera géré par un bot et enverra les messages aux gens qui veulent se connecter. Mais si jamais ton blog estexample.commême, et tu gères ton propre serveur XMPP, alors tu vas préférer que les gens reçoivent un message deexample.comtout court. C'est plus "officiel" et fait plus confiance qu'une adresse que tout le monde peut avoir. Pour ça, il faut un composant.En conclusion: oui un composant est une sorte de client XMPP, géré par les admins du serveur, et à qui le serveur a donné des droits spéciaux pour agir en son nom.
Ainsi un composant c'est l'équivalent d'un
botmais côté serveur.Le composant accepte tout ce qu'accepte le serveur. Les messages passent par le serveur (qui les redistribue s'il constate qu'ils sont pour tel composant ou pour tel utilisateur). Le composant ne gère donc pas la sécurité et la communication est donc aussi sécurisée que le permettent clients et serveurs.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Petites questions
Posté par Chteufleur . Évalué à 3.
Pour l’instant c’est un composant. Donc uniquement avec un serveur XMPP que l’on contrôle.
Mais, je me suis fait la réflexion hier soir, que ça serait bien que ce ne soit pas uniquement un composant. Ça pourrait aussi être un client XMPP classique, pour pouvoir utiliser un serveur XMPP que l’on ne contrôle pas.
Donc oui, ça sera bientôt possible.
# Gajim et le code de validation (et autres considérations et questions naïves)
Posté par jihele . Évalué à 5.
Dans la fenêtre Gajim, c'est pas bien clair, je savais pas ce qu'était le "id". Je pensais que c'était l'identifiant de l'utilisateur. Et je demandais comment ça pouvait fonctionner sans code de validation.
C'est plus clair de SàT où il est clairement écrit "Validation code" et où il est précisé qu'on doit vérifier que c'est le même que celui affiché sur la page (pour éviter qu'on accepte une requête illégitime qui aurait été effectuée pile au même moment que la notre, j'imagine).
Est-ce qu'il y a pas un risque de se choper plein de popup dues à des requêtes illégitimes? Parce que si des bots tentent de se connecter à ma place, je vais recevoir plein de messages, non? J'aimerais pas recevoir par IM l'équivalent des logs d'échecs d'authentification de mon serveur…
[^] # Re: Gajim et le code de validation (et autres considérations et questions naïves)
Posté par Goffi (site web personnel, Mastodon) . Évalué à 5. Dernière modification le 22 juillet 2016 à 10:33.
c'est exactement ça
Il y a toujours des risques de spam pour tout, on en parlait justement hier sur le salon SàT. Je pense que c'est pas le vecteur de spam le plus efficace ceci dit, c'est plus simple d'envoyer directement des messages.
Si le cas se présente et qu'il y a une grosse vague, ça serait assez facile à éviter: tu peux faire une liste blanche de sites que tu fréquentes, et/ou faire un système ou tu dis d'abord sur ton client « j'attends une requête, tu peux m'afficher les popups », puis tu fais la requête sur le site et enfin du valide (juste un clique en plus en gros).
[^] # Re: Gajim et le code de validation (et autres considérations et questions naïves)
Posté par jihele . Évalué à 4.
Je pensais pas à des spammeurs, plutôt des usurpateurs qui tentent de se connecter à ta place.
OK, je vois l'idée.
[^] # Re: Gajim et le code de validation (et autres considérations et questions naïves)
Posté par Jehan (site web personnel, Mastodon) . Évalué à 4.
Les bots cliquent pas sur les boutons au hasard. Ils implémentent des schémas connus. Pour les bots qui se connectent, ils vont donc essayer de mettre des mots de passe bateau (brute force) dans les champs adéquats. Et pour cela, ils cliqueront pas sur un bouton, mais simplement enverront une requête POST telle qu'attendue par un Wordpress. En gros si ton Wordpress attend des connexions par XMPP, il se passera juste rien: le bot pourra pas se connecter et tu recevras pas de messages par IM.
Pour info, j'utilise mon plugin Wordpress depuis 2011 au moins, et je n'ai jamais reçu la moindre tentative de connexion par XMPP (par contre par login/mot de passe, si!).
Ensuite oui, si la connexion par XMPP devenait un standard super utilisé, là on pourrait imaginer que des bots commencent à tenter des POSTs avec les paramètres adéquats pour déclencher une tentative connexion par XMPP. C'est pour cela qu'il est important que le protocole soit bien sécurisé pour pas que les gens cliquent "OK" pour n'importe quoi.
Et si jamais cela devenait vraiment ennuyeux (cad on reçoit plein de requêtes), on pourra alors imaginer les possibilités pour contrer le spam résultant, tel que Goffi le propose.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
# appareils portables
Posté par Goffi (site web personnel, Mastodon) . Évalué à 8.
j'en profite pour préciser qu'on a avancé sur le frontal bureau/android/éventuellement autre (un billet sur le développement est à venir au moins sur mon blog), donc ça sera prochainement disponible sur appareils portables au moins avec SàT, et gageons que si des sites suivent, ça sera rapidement implémenté par d'autres clients.
Ça serait vraiment super de voir ça se répandre, ceux qui ont un peu de temps libre pendant l'été, faut en profiter ;)
# Le Persona de Jabber ?
Posté par rogo . Évalué à 4.
En lisant la description, j'ai tout de suite pensé à Persona, le système d'authentification proposé par Mozilla. Persona proposait que l'identification soit gérée par un compte email, alors qu'ici c'est un compte XMPP. Il y a eu beaucoup d'enthousiasme dans la communauté du libre, mais ça n'a pas décollé, et Mozilla abandonne complètement le projet à la fin de l'année.
Là, j'ai l'impression qu'on est dans une niche encore plus étroite. Autrement dit, un site devra en pratique ajouter ce système en parallèle de mécanisme plus larges. Même pour l'utilisateur client, il y a des inconvénients évidents : il faut avoir un client XMPP actif, et l'anonymat est plus faible qu'avec le couple mdp/email-jetable. Ça ne veut pas dire que ce protocole est inutile, mais même sur un site optimal pour lui comme linuxfr, je soupçonne que cette authentification serait adoptée par une minorité d'utilisateurs.
[^] # Re: Le Persona de Jabber ?
Posté par barmic . Évalué à 6.
Sur linuxfr, je ne me connecte presque jamais. Je suis perpétuellement connecté.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Le Persona de Jabber ?
Posté par Goffi (site web personnel, Mastodon) . Évalué à 9.
Tu n'es pas le seul à y avoir pensé ;)
C'était beaucoup plus lourd à installer, et très lié à Mozilla, ce qui fait que suite à son abandon, ça n'a pas suivi.
Là les serveurs XMPP sont répandus, côté site c'est une simple requête HTTPS à faire, et côté client ça marche (avec la solution de secours mentionnée dans la dépêche) même si la XEP n'est pas implémentée. Bref, très facile à mettre en place, il y a tous le atouts pour que ça décolle.
Il y a une autre différence avec OpenID et Persona à mon sens, c'est que là c'est un truc en plus, pas un truc dédié uniquement à l'authentification. On peut avoir un client/serveur XMPP pour tout un tas de raisons, c'est pas un truc à installer spécifiquement et uniquement pour l'authentification.
encore une fois, une requête HTTS à faire, il faut vérifier son code de retour, c'est tout ! On peut difficilement faire plus simple (y'a pas besoin d'installer un serveur XMPP ou le composant, suffit d'en utiliser un en qui on a confiance et qui a déjà le composant).
Il y a des comptes « anonymes » sur XMPP, bien plus simples à utiliser qu'une adresse de courriel jetable, il faut juste trouver un serveur public qui les autorise et qui autorise le S2S avec (c.-à-d. la communication avec les autres serveurs).
On peut même ajouter une couche Tor ou autre si on veut, il faut que le serveur XMPP qu'on utilise gère les .onion par exemple (possible avec au moins Prosody).
Vu la facilité d'implémentation, surtout maintenant grâce au composant de Chteufleur, je pense que l'adoption peut être très rapide. Mais il faut que ça suive du côté des mainteneurs et développeurs de sites, et c'est franchement pas un gros effort à faire. Reste à savoir si on veut dépendre des FB et autres G+ ou pas.
Si on se dit toujours que personne n'utilisera, que ça va prendre etc, autant arrêter de faire des choses ;)
[^] # Re: Le Persona de Jabber ?
Posté par rogo . Évalué à 4.
Merci pour cette réponse, c'était instructif. Du coup je suis allé lire la XEP mentionnée dans la dépêche pour mieux comprendre. Le principal handicap technique de Persona, c'était que le domaine de l'email devait gérer le protocole de Persona, sinon c'est Mozilla qui reprenait la main. Pour le processus décrit dans la dépêche, si j'ai bien compris, le domaine du jid n'a rien à faire ; la seule contrainte est que le serveur de départ puisse se connecter en HTTPS à une autorité de confiance qui joue le rôle d'intermédiaire (en étant un serveur XMPP avec ce composant). C'est ça ?
En pratique, ça ne me semble simple à utiliser pour le développeur que si on n'a pas à installer un serveur XMPP. Donc soit le projet gère déjà un tel serveur, soit il va confier l'authentification à un tiers si le besoin de sécurité n'est pas très élevé. Est-ce qu'il y a de serveurs prêts à l'emploi, qui soient de facto des "autorités de confiance" HTTP/XMPP ?
Heureusement qu'il n'y a pas que ça comme alternative, parce que je ne me suis jamais connecté à ces machins, et je m'en passe bien. Les gestionnaires de mots de passe, notamment ceux intégrés aux navigateurs, sont bien pratiques. D'ailleurs pass avec un dépôt Git cloné sur mes machines me convient très bien.
[^] # Re: Le Persona de Jabber ?
Posté par Goffi (site web personnel, Mastodon) . Évalué à 6.
Oui c'est ça
Il est fort probable que jabber.fr/jabberfr.org l'installe à court ou moyen terme. Nous allons certainement le mettre sur libervia.org aussi, et peut être qu'on peut pousser des gens en qui on a confiance comme Framasoft (surtout que Diaspora permet les conversations via XMPP maintenant, donc ça peut être intégré a priori très facilement à framasphère).
Si ça passe sur 3/4 gros sites francophones, ça peut inciter à suivre dans d'autres langues, et faire boule de neige comme dit dans la dépêche.
Je me souviens avoir voulu ajouter SàT à alternative.to et avoir fait marche arrière parce que la seule possibilité non dépendante de ces sites était OpenID, que je n'utilise pas. Et ça m'étonnerait pas que ça se généralise et que les login/mot de passe soit de moins en moins possible (vu que les sites on intérêt à récupérer les infos que Facebook leur file), et pas forcément toujours avec OpenID. Du coup SàT n'est toujours pas listé sur ce site.
Oui mais si t'as pas ta machine à côté (ou si tu la perds ou on te la pique), t'es mal.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Le Persona de Jabber ?
Posté par rogo . Évalué à 3.
Non, justement. Tous mes comptes sont dans un dépôt Git chiffré, donc je peux perdre mes machines sans perdre mes authentifications. Et ces infos sont clonées partout où c'est utile.
Dans le gestionnaire de mdp du navigateur, je ne mets que les sites sans risque. Je peux ainsi m'authentifier sur Linuxfr avec un simple Ctrl-Entrée, tandis que j'utiliserai
passpour une banque. Donc si on me vole une machine, les dégâts seront limités.À contrario, le système proposé ici est moins robuste. Si on vole un mobile avec un client XMPP, on peut ensuite s'authentifier en un clic ! C'est pour cela que l'authentification par SMS n'est utilisée qu'en second niveau, après l'authentification principale.
[^] # Re: Le Persona de Jabber ?
Posté par Goffi (site web personnel, Mastodon) . Évalué à 3.
Oki je pensais à un greffon Firefox avec chiffrement en local. Tu restes quand même embêté sur une machine étrangère, vu que tu n'as pas forcément la possibilité d'installer un greffon (et de le configurer avec ton compte, comment entrer ton mot de passe de déchiffrement sans risque par exemple ?).
Et puis git + chiffrement c'est pas super accessible au grand public.
Rien n'empêche de demander un mot de passe supplémentaire, on peut même le faire uniquement pour les sites sensibles (d'ailleurs ça serait pas mal d'ajouter ça dans la XEP, un drapeau qui annonce un site très sensible).
[^] # Re: Le Persona de Jabber ?
Posté par barmic . Évalué à 4.
La notion de site sensible d'une part est liée à l'utilisation que tu en fais, d'autres part elle est très subtile. Cette fonctionnalité apporte surtout des risques.
Soit on considère que c'est une authentification sûre soit non.
Le client peut très bien définir un mot de passe globale qu'il faut entrer pour valider ces requêtes (mot de passe, dessin ou ce que tu veux) et si l'utilisateur décide de désactiver ces vérification tant pis pour lui
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Le Persona de Jabber ?
Posté par kna . Évalué à 2.
Tu peux utiliser un smartphone aussi. Personnellement, j'utilise, sgit + keepass sur android.
[^] # Re: Le Persona de Jabber ?
Posté par Jehan (site web personnel, Mastodon) . Évalué à 9.
L'identification par XMPP se base en effet sur le fait que les gens ont une adresse XMPP. Et c'est donc un problème si cela ne se répand pas davantage. En même temps, c'est toujours l'œuf et la poule.
Par contre, Persona n'était pas mieux:
1/ De ce que je lis, pour que ce soit aussi intéressant que l'id par XMPP, il fallait que votre serveur de mail prenne en charge Persona. Dans les faits, je crois que quasi aucun serveur email n'a implémenté le protocole. En fait, je ne suis même pas certain quel sera le comportement de login à ce moment: je ne l'ai jamais vécu car justement aucun de mes fournisseurs d'email n'implémente Persona (et je n'ai pas lu la spéc, ce qui me permettrait d'imaginer un comportement).
Au final on se retrouve à utiliser les serveurs Persona de Mozilla (bientôt communautaire?), donc un point de contrôle unique et central pour la plupart des utilisateurs du monde. Pas glop.
En plus en passant par le serveur Persona central, on est obligé d'y créer un mot de passe unique.
De son côté, l'id par XMPP marche quel que soit son serveur et ne passe par aucun serveur tiers. Et on n'a pas à créer de mot de passe supplémentaire (bien sûr ce point précis est biaisé du fait qu'on part de la supposition avoir déjà un compte de messagerie alors que de son côté Persona ne sert qu'à cela, alors on n'avait forcément pas déjà de compte).
2/ Pour que l'id soit final, il faut forcément s'identifier sur Persona dans la même session de navigateur, puisque le système se base sur les redirections http entre le site sur lequel on veut s'identifier et Persona. Cela signifie donc que si la machine elle même est compromise, vous donnez l'accès à un attaquant à l'ensemble de vos comptes utilisables par Persona. Pire vous lui donnez aussi le mdp Persona pour se reconnecter plus tard. C'est d'ailleurs la même faiblesse pour tous les autres systèmes basés sur le web (OpenID, mais aussi les systèmes proprios par compte Facebook, Google, etc.). C'est dommage car Mozilla partait d'une bonne idée en mélangeant un autre protocole (les emails) mais ils finalisent le login par la redirection web.
De son côté, on peut s'identifier par XMPP en gérant entièrement l'identification à travers le canal XMPP, lequel peut être totalement disjoint. Par exemple, vous êtes dans un cybercafé devant une machine Windows (potentiellement vérolée, avec des logiciels de keylogging, etc.) à l'autre bout de la terre et voulez vous connecter sur votre compte Linuxfr. Vous lancez une connexion par IM. Or votre client IM est sur votre téléphone, en 3G. Toute la partie id se fait donc par un échange sécurisé direct entre linuxfr et votre client IM sur une machine perso avant de finalement vous autoriser l'accès dans le navigateur sur la machine tierce.
Si l'ordi est effectivement vérolé, bien entendu, vous donnez l'accès à votre compte linuxfr le temps de votre connexion au site (c'est inévitable: par définition). Mais cette machine n'a jamais accès à votre mot de passe linuxfr, ni à votre compte XMPP, donc pas non plus à aucun autre compte accessible par identification XMPP, et finalement une fois que vous vous déconnectez du site, l'attaquant n'a pas la capacité de se reconnecter plus tard.
En gros, l'identification par Persona/OpenID/Facebook/Google/etc. est bon pour la simplicité d'utilisation mais a extrêmement peu de qualité de sécurité là où la connexion par XMPP a aussi pas mal d'avantages de sécurité.
Note: comme je disais plus haut, par définition, vous prenez un risque en vous connectant sur un site sur un ordi non-de-confiance. Et ce, quel que soit la méthode. Donc déjà il ne faut le faire que sur des sites où le risque est acceptable (genre linuxfr, j'en souffrirai moins que ma banque!). Mais au moins avec l'id par XMPP, vous limitez le risque à ce site et juste le temps de la connexion. Avec les autres méthodes, le risque s'étend à tous les sites qui utilisent cette méthode et de manière illimitée!
3/ Les protocoles emails sont quand même pas sécurisés par nature. Tout le monde peut envoyer de faux emails provenant de
persona @ persona.org. Y a encore plein de serveurs emails qui acceptent les connexions non encryptées, donc ce serait assez simple d'écouter des communications et d'envoyer de faux emails. À partir de là, pas mal d'attaques sont faisables.Franchement l'ID par XMPP est plus simple d'utilisation, plus rapide, un flow bien plus agréable et plus sécurisée. Le seul bloqueur — et là tu as tout à fait raison, c'est le principal problème à l'adoption — c'est que XMPP reste encore trop peu utilisé de manière générale.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Le Persona de Jabber ?
Posté par Mathieu CLAUDEL (site web personnel) . Évalué à 2.
Une petite remarque sur ce que j'ai pu lire (pas que dans ce commentaire d’ailleurs) notamment sur OIDC, Google, …:
A mon sens il faut décorréler les méthodes Authentifications des protocoles telle que OIDC ou SAML. De ce que je comprend ici nous sommes face à une méthode d'authentification, CAD un moyen de valider l'identité de l’utilisateur (au même titre que un bind ldap, un certificat, un OTP par sms,…).
Ici rien empêchement à un fournisseur d’identité (pour prendre la terminologie SAML, mais c'est valable aussi en OIDC, OAuth2,…) d'utiliser cette méthode d’authentification XMPP.
Pour aller plus loin, on peut même l'utiliser pour faire du google :
Site web cible --[demande d'authentification SAML]--> IDP -[Validation de l'identité de l'utilisateur]->Authentification XMPP
Dans ce cas on vois bien que SAML ne fait pas l'authentification proprement dite (pas plus que OIDC) mais ne fait que transporter l'identité de l'utilisateur validé en bout de chaine par une Authentification qui peut elle être plus ou moins sur.
[^] # Re: Le Persona de Jabber ?
Posté par Chteufleur . Évalué à 1.
Oui, tu as raison. Il y a un commentaire plus bas qui en parle.
De plus, en utilisant XMPP dans OIDC comme protocole, ça permet de pallier au problème que décrit Jehan dans son commentaire :
# OpenID et XEP 0070
Posté par MrLapinot (site web personnel) . Évalué à 10.
Ou sinon, on utilise OpenID et http://openid.xmpp.za.net, ce qui permet d'avoir le meilleur des deux mondes : un système qui marche sur tous les sites implémentant OpenID et l'authentification via xmpp. Ça fait une bonne décennie que ça marche…
[^] # Re: OpenID et XEP 0070
Posté par Goffi (site web personnel, Mastodon) . Évalué à 4.
ah ben je ne connaissais pas, c'est plutôt cool, merci pour le lien.
# Quelques années plus tard…
Posté par Jehan (site web personnel, Mastodon) . Évalué à 6. Dernière modification le 22 juillet 2016 à 15:35.
C'est marrant que les choses bougent après si longtemps. Ça fait presque chaud au cœur.
En regardant mes logs pour le plugin Wordpress, je vois que mon premier commit date d'août 2011 (et encore j'avais dû commencer avant). À l'époque, tout le monde avait l'air de s'en foutre. Pourtant j'utilise ça pour me connecter sur mon blog Wordpress depuis des années. Ça marche méga bien et j'ai plus à me faire chier avec un mot de passe à rallonge.
Notez que j'ai fait plusieurs changements par rapport à la XEP pour améliorer la sécurité et notamment l'utilisabilité en mode dégradé (cad quand le client ne prend pas en charge XEP-0070). De manière générale, cette XEP mérite d'être totalement revue sur plusieurs points.
Puis ensuite elle pourrait être améliorée avec de nouvelles fonctionnalités, notamment avec de l'autorisation en plus de l'identification: à ce jour, la seule chose possible est d'identifier quelqu'un mais sans donner le moindre pouvoir ou connaissance. Le protocole pourrait ainsi permettre à un client d'accéder à certaines infos ou de faire certaines actions au nom de l'utilisateur. Par exemple accès à la vcard, récupérer notamment l'avatar pour affichage sur un site, à la liste de contact, etc.
En d'autres termes: faire aussi ce que fait OAuth.
Enfin voilà, c'est une idée des améliorations possibles.
Si vous êtes partants, Chteufleur, Goffi et d'autres intéressés par cette fonctionnalité précise de XMPP, je suis partant pour réécrire la XEP-0070 en co-auteur avec vous et la rendre plus moderne. Vous le savez sûrement, XMPP n'est plus ma priorité principale, mais je suis prêt à prendre quelques heures régulièrement pour ça, car ça fait partie de mes nombreux projets qui m'ont laissé un goût de triste "non-fini" de ma période XMPP.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Quelques années plus tard…
Posté par Goffi (site web personnel, Mastodon) . Évalué à 2.
ça bouge parce qu'à force d'acharnement l'aïoli finit par monter.
Si tu fais ton plugin Wordpress tout seul, ça a peu de chances de prendre. Si Chteufleur fait son composant tout seul, idem. Mais si y'a ton plugin, le composant de Chteufleur, les implés qui vont bien, là ça commence déjà a faire quelque chose. Reste à ce que certains qui lisent cette dépêche suivent pour continuer sur la lancée.
Je pense que la communauté commence à se rendre compte qu'on avance et qu'on a fait un très gros chemin ces dernières années, et que des projets comme Movim ou SàT (ou Prosody, Ejabberd, MongooseIM, Poezio, Gajim, Conversations, etc) sont toujours là.
C'est en gros ce que je proposais avec ma XEP qui a subit un veto. Y'avait une partie avec gestion des permissions, mais qui a été refusée parce que ça n'était pas l'état de l'art (et je comprends tout à fait, avec le recul je pense que ça n'était effectivement pas la meilleure solution). Il est prévu de travailler sur un système de gestion des permissions type ABAC, mais c'est beaucoup de boulot et pas dans mes priorités actuelles.
Je suis partant pour participer oui. Par contre moi aussi j'ai énormément de travail, et pour l'instant la priorité c'est Cagou notre interface bureau/android promise suite à notre financement participatif. Donc OK mais sur du moyen terme. Là je pense que la XEP en l'état est suffisante pour le moment.
[^] # Re: Quelques années plus tard…
Posté par Jehan (site web personnel, Mastodon) . Évalué à 4.
En fait le plus gros problème, c'est le support client, car c'est lui qui donne la meilleure expérience utilisateur. Et comme beaucoup de choses dans le monde XMPP, c'était donc à ce sujet (client) qu'y avait un blocage. C'est bien que ça commence à bouger (merci à toi et aux autres clients modernes que tu cites, notamment), mais c'est dommage que les clients historiques et donc les plus utilisés (Pidgin, on pense à toi!) n'évoluent pas trop.
Ensuite, je faisais ça "tout seul" certes, mais j'étais pas vraiment dans mon coin non plus. Membre de la XSF, j'avais essayé d'avoir des revues de code et une installation du plugin sur xmpp.org (qui a utilisé Wordpress pendant pas mal d'années), mais sans succès. ;-(
Je comprends. Ceci dit, pour moi en tant qu'utilisateur, c'est d'autant plus important sur les clients web de type Libervia. L'autre jour, on m'a fait testé Movim, et j'ai hésité pour mettre mon JID. Au final j'ai créé un compte sur leur serveur pour ne pas avoir à mettre mon mot de passe. Pourtant c'est pas une grosse multinationale derrière et c'est des gens que j'ai rencontrés; mais quand même, ça me gêne de mettre mon mot de passe pour un service sur le site d'un autre service. Et donc ça rend l'idée du client web absurde (sauf si on contrôle aussi le dit client, bien sûr, mais pas tout le monde ne va installer un client Movim/Libervia juste pour lui).
Avec un système de permission, la permission "ultime" serait de permettre à un client de tout faire. Donc une connexion par intérim. Mais au moins on n'a pas à mettre le mot de passe maître et on peut donc à tout moment invalider les droits donnés à un client. Ce serait une grosse avancée pour le protocole, ce genre de truc.
Pas de prob, moi aussi c'est plus du moyen terme. J'aurais eu plus peur de pas pouvoir tenir l'engagement si vous vouliez faire ça demain! ;P
Elle a quand même quelques problèmes. Je ferai peut-être des messages sur les mailing lists de la XSF pour proposer au moins mes modifications de base. Ça fera pas mal d'années que j'ai plus posté là-bas!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Quelques années plus tard…
Posté par Chteufleur . Évalué à 2.
Ça me convient, à moyen terme aussi.
D’ailleurs, ça m’intéresse d’échanger sur le sujet.
# Email ?
Posté par Muchacho . Évalué à 2.
Si j'ai bien compris, l'utilisateur rentre son identifiant XMPP, et le client XMPP lui demande de confirmer (?)
Je dois pas avoir saisi le réel intérêt.
Est-ce que le même mécanisme pourrait être utilisé avec une adresse mail ? On rentre le mail, on attend le lien sur lequel cliquer et on est connecté ?
Il y a aucun sarcasme dans ce message je cherche réellement à comprendre.
[^] # Re: Email ?
Posté par Chteufleur . Évalué à 3.
Le site en question affiche l’identifiant de la confirmation qui a été envoyé au client XMPP. Ensuite la personne donne l’autorisation ou non à cette requête.
Un intérêt est de ne pas fournir son mot de passe pour autoriser l’accès, ce qui offre une plus grande sécurité.
Comme dit dans un commentaire plus haut, Persona utilise l’email. Donc, oui c’est possible.
Cependant, je trouve que le mail n’est pas adapté (avis personnel). Et puis si on est obligé de se connecter à son adresse mail, sur la même machine, pour accéder à son site; l’intérêt diminue grandement (à mon sens). Jehan l’explique très bien, un peut plus haut.
J’espère que c’est plus clair.
[^] # Re: Email ?
Posté par Goffi (site web personnel, Mastodon) . Évalué à 6.
L'email (SMTP) ne dispose pas de l'authentification forte, le chiffrement n'est pas systématique, et tu peux avoir un délai (greylisting par exemple) entre l'émission du message et sa réception comme premiers problèmes qui me viennent à l’esprit.
Donc oui tu pourrais, en mettant par exemple un GPG pour valider l'identité, en t'assurant que les serveurs auxquels tu parles sont chiffrés, et en faisant une extension pour afficher une popup (reste le problème du greylisting), pas franchement simple à généraliser !
XMPP gère tout ce qu'il faut de base, et son système d'extensions permet de facilement récupérer les infos nécessaires à la popup.
[^] # Re: Email ?
Posté par barmic . Évalué à 4.
XMPP a le même problème au sujet du chiffrement. Est-ce que les clients montrent clairement quelles garanties on a sur un message donné ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Email ?
Posté par Goffi (site web personnel, Mastodon) . Évalué à 6.
Le chiffrement est obligatoire avec XMPP et on ne peut pas falsifier (spoofer) l'expéditeur.
[^] # Re: Email ?
Posté par Aurélien Jarno (site web personnel) . Évalué à 3.
Et par IRC ? Je vois souvent des gens qui rentrent leur mot de passe, mais je sais pas si ça marche bien…
# Commentaire supprimé
Posté par lucette123 . Évalué à -1. Dernière modification le 28 juillet 2016 à 14:43.
Ce commentaire a été supprimé par l’équipe de modération.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.