Mathieu CLAUDEL a écrit 184 commentaires

Pour plantuml, j'ai trouvé ça pas plus tard que le semaine dernière : https://github.com/Hywan/Database-to-PlantUML

Il faut penser à augmenter la taille max de l'image si on veut que les grosses DB rentre.

On est aussi sur du 30s à 1min pour du youtube, facebook, jwplayer, …. donc il n'y a pas à rougir.

Si tu t’intéresses à la sécurité informatique, un point d'entrée intéressant c'est :
https://www.root-me.org/

Un autre cas, qui est peut-être encore plus flagrant, car seul une version papier peut réellement être lue : la série des Julius Corentin Acquefacques dont un tome possède une case qui est un trou vers la case de la page suivante et précédente ou encore un tome qui se lit en mode "européen" et en mode "manga", …

Salut,

une piste : si tu as une licence, tu peux peut-être installer Windows dans une machine virtuel ? (tu dois même pouvoir trouver des images de machines officielles)

Salut
Une liste de diffusion chez ton fournisseur.
Un mail pour s'inscrire, un maim pour se desincrire.

ça me fait penser au ps doom

https://www.cs.unm.edu/~dlchao/flake/doom/chi/chi.html

Bonjour,

j'ai été aussi dans votre cas, mais après études on est passer d'un wordpress avec des extensions dans tous les sens (difficile à maintenir) à du SaaS (abonnement mensuel).

Du coup c'est plus nous qui gérons, on ne fait plus que utiliser et faire des demandes d'évolutions (qui sont prisent en compte plus ou moins rapidement). Il manque pour le moments quelques fonctionnalités (du coup nous gérons une boutique en ligne en parallèle, mais le wordpress ne fait plus que ça).

Le gros avantage de la solution que nous avons retenu : il fait aussi la compta, et ça la trésorière et ravis (surtout quand les adhérents payent par CB) !

PS: la solution qu'on a retenu est Pep's up (je fais un peu de pub car plus on sera à l'utiliser plus ils auront la possibilité de faire évoluer la solution, si vous avez des questions sur la solution n’hésitez pas)

Fédéré !
OpenId Connect sur leur fournisseur de mail (ici google) et bascule sur un autre fournisseur si ils changent de crémerie.

salut,

Grafana peut, peut-être répondre à ton besoin ? il est capable d’interroger des serveurs SQL (exemple https://grafana.com/docs/features/datasources/mysql/ https://grafana.com/docs/features/datasources/postgres/ ou encore https://grafana.com/docs/features/datasources/mssql/ (avec des exemples de graphiques dans ce dernier))

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

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.

Bien plus belle réponse que la mienne …

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.

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.

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,…)

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 ?

Je préfèrerais un OTP mail. Je ne vois pas l'intérêt de créer un compte pour certains sites (genre où tu te connectes une fois par an).

Je vais chipoter :) Mais tu veux dire créer un mot de passe ? car envoyer un OTP, c'est une méthode d'authentification lié à une identité (un compte) existant préalablement et qui à donc été créée (dans ton cas une boite mail).
C'est une solution que j'ai employée pour un site perso afin de ne pas m’embêter à gérer des mot de passe. Mais dans ce cas, il faut avoir conscience que la sécurité se base sur la boite mail (ce qui bien souvent le cas via les fonctionnalités "j'ai oublié mon mot de passe" et il y a peu, le site des impôt français à eu quelques soucis à ce sujet). Mais ce n'est pas une solution pour beaucoup de site .

Salut,

Le problème avec les protocoles classiques est qu'il faut gérer des comptes utilisateurs, des login/mdp, des codes de confirmation par SMS ou mail…

Je pense que tu lies protocoles (SAML v2, OpenID Connect,…) et Gestion des Identités.
On peut tout à fait faire ce que tu décris en utilisant l'un de ces protocoles (qui créer une relation de confiance entre IdP et SP et par extension aux identités fournies mais si elles sont farfelue). Par exemples en SAMLv2 tu peux utiliser https://stubidp.sustainsys.com/ qui est un IdP compatible SAML v2 dans lequel tu forges toi même le jeton de retour (assez intéressant pour les tests).

Pour faire une gestion d'identité simple pour des applications grand public (par opposition à une application interne à une entreprise où la maitrise des salariés est indispensable), avec keycloak, tu peux activer la création de compte ce qui permet au utilisateur de renseigner eux même leur identité et de gérer son cycle de vie.

Je tiens aussi à souligner que sans méthodes d'authentifications (mot de passe, OTP, Certificat, Webauthn,…), l'IdP ne peux vérifier l'identité revendiquée par l'utilisateur et ouvre la porte à l'usurpation.

D'où l'idée d'un protocole basé sur la confiance: selfid.

Un protocole qui est basé sur la confiance est OpenID (pas connect !) mais il ne résout pas le problème de la création et du cycle de vie des identités :). Mais ça n'a pas spécialement pris.

Je réfléchis aussi à une future version, selfid coinect, pour authentifier les canards, mais je ne sais pas si les anatides peuvent se reconnaître.

Voila un beau projet de rfc pour le 1er avril prochain !

ça me fait personnellement penser à une infrastructure docker managée comme Kubernetes avec son ingress (que ce soit traefik ou ngnix+cert manager) qui apporte nativement : reverse proxy (avec certificat ou non), dns interne, load balancer, scalabilité horizontal, automatisation de déploiement,…

si je comprend bien, Fusion Directory est un interface de gestion d'annuaire LDAP v3 qui prend en charge un certain nombre de schéma (eux même lié à des applications spécifiques ou transverse comme peut l'être SupAnn) ?

Et si je compend bien aussi, il à sa propre extension de schéma pour gérer sa propre gestion de droits (ACL) au dessus de celle éventuelement fournit par l'annuaire. Donc si une application fait directement du LDAP, ces ACLs ne sont pas prise en compte, elle ne serve que pour l'interface Fusion Directory (ce qui pas inintéressant d’ailleurs) ?

J'ai bien compris ce qu'est Fusion Directory ?

top, quand on aura oublié son mot de passe on n'aura plus qu'a faire une la requête HTJP "login success" :)

Complément au POST du dessus …

qu'il faut en effet déployer un agent sur le client

Oui. Dans LemonLDAP::NG 2, si j'ai bien compris, c'est du FastCGI ? c'est donc bien exécute aussi coté serveur web ? Il est aussi possible de mettre ton apache en reverse proxy de ton application et de propager les claims via, par exemple, les headers (comme Lemon, si j'ai bien suivis).

merci pour le retour.

OpenID Connect exige que le client soit déclaré au niveau du serveur pour obtenir en particulier un client_id et un client_secret.

Comment le serveur sait-il que la demande est ou non légitime et que ce n'est pas une application faisant par exemple du phishing ?

Enfin OpenID Connect impose l'utilisation de scope et de claims

Il est tout à fait possible de faire une demande d'autorisation sans scope et de ne retourner aucun claims (et donc de ne faire que de l'authentification). Mais c'est plutôt dommage si l'application doit faire du contrôle d'accès derrière.

avec validation du consentement de l'utilisateur

Toutes les solutions que je connais permet de bypasser cette étape au besoin

pas forcément souhaité dans le déploiement de micro services.

Je ne suis absolument pas un spécialiste en micro service, mais n'utiliserions nous pas simplement les jetons en Bearer (access_token ou id_token). Jetons issuent d'une authentification utilisateur préalable (avec éventuellement un consentement :)) ou d'une authentification en grant_type=client_credential pour les "non humains" puis propagation des jetons de services en services (exemple de conf de sécurisation de ressource avec mon cher mod_auth_openidc https://github.com/zmartzone/mod_auth_openidc/wiki/OAuth-2.0-Resource-Server) ?

Mais mod_auth_openidc n'est par exemple disponible que pour Apache, pas Nginx

Pour ngnix il y a https://github.com/zmartzone/lua-resty-openidc (lui aussi certifié)

Désolé, j'ai beaucoup de questions et interrogations, mais c'est un sujet qui m’intéresse beaucoup.

Bonjour,

je n'ais trop compris ce qu'apporte LemonLDAP::NG 2 par rapport à un couple IdP <-> Agent pour serveur web plus classique.

Comme par exemple un IdP OpenID Connect (LemonLDAP::NG, keycloak, …) et le module apache mod_openidc (idem avec SAML en le module shibboleth,…) qui en 5 lignes de configurations dans le fichier ( https://github.com/zmartzone/mod_auth_openidc#quickstart-with-a-generic-openid-connect-provider ) apache permets de sécuriser un site ou une API tout en mettant à disposition des claims à l'application et aussi de gérer les droits d'accès ( https://github.com/zmartzone/mod_auth_openidc/wiki/Authorization ).