Mathieu CLAUDEL a écrit 149 commentaires

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

    Posté par (page perso) . En réponse au journal Glewlwyd 2.0, serveur SSO, est maintenant en RC1. Évalué à 1 (+0/-0).

    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: keycloak ?

    Posté par (page perso) . En réponse au journal Glewlwyd 2.0, serveur SSO, est maintenant en RC1. Évalué à 1 (+0/-0).

    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 (page perso) . En réponse au journal Glewlwyd 2.0, serveur SSO, est maintenant en RC1. Évalué à 1 (+0/-0).

    Bien plus belle réponse que la mienne …

  • [^] # Re: keycloak ?

    Posté par (page perso) . En réponse au journal Glewlwyd 2.0, serveur SSO, est maintenant en RC1. Évalué à 1 (+0/-0).

    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: Papotages

    Posté par (page perso) . En réponse au journal Glewlwyd 2.0, serveur SSO, est maintenant en RC1. Évalué à 2 (+1/-0).

    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: Authentification TLS

    Posté par (page perso) . En réponse au journal Glewlwyd 2.0, serveur SSO, est maintenant en RC1. Évalué à 2 (+1/-0).

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

  • # Papotages

    Posté par (page perso) . En réponse au journal Glewlwyd 2.0, serveur SSO, est maintenant en RC1. Évalué à 6 (+5/-0).

    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: selfid

    Posté par (page perso) . En réponse à la dépêche Sortie de Keycloak 7.0. Évalué à 2 (+1/-0).

    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 .

  • [^] # Re: selfid

    Posté par (page perso) . En réponse à la dépêche Sortie de Keycloak 7.0. Évalué à 2 (+1/-0).

    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 !

  • [^] # Re: traefik ?

    Posté par (page perso) . En réponse au journal EASYLAN - Mise en place simplifiée et personnalisable d'un intranet sécurisé avec Docker. Évalué à 2. Dernière modification le 16/06/19 à 20:09.

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

  • # Compréhension

    Posté par (page perso) . En réponse à la dépêche FusionDirectory 1.3 est sorti. Évalué à 4.

    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 ?

  • [^] # Re: RFC 8565: Hypertext Jeopardy Protocol (HTJP/1.0)

    Posté par (page perso) . En réponse au journal Liste de poissons d'avril 2019. Évalué à 5.

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

  • [^] # Re: SSO as a Service (SSOaaS)

    Posté par (page perso) . En réponse à la dépêche Sortie de LemonLDAP::NG 2.0. Évalué à 1.

    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).

  • [^] # Re: SSO as a Service (SSOaaS)

    Posté par (page perso) . En réponse à la dépêche Sortie de LemonLDAP::NG 2.0. Évalué à 1.

    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.

  • # SSO as a Service (SSOaaS)

    Posté par (page perso) . En réponse à la dépêche Sortie de LemonLDAP::NG 2.0. Évalué à 1.

    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 ).

  • # du huit du six

    Posté par (page perso) . En réponse au sondage Prononciation des options. Évalué à 5.

    perso, j'utilise le moins surtout car cela évite de devoir préciser de quel tiret il s'agit.

  • [^] # Re: Quels cas d'usage ?

    Posté par (page perso) . En réponse à la dépêche RyDroid Web Proxy (1.0) : outil de capture de sessions Web. Évalué à 5. Dernière modification le 22/06/18 à 08:55.

    salut,

    quand tu fais des scénarios de tests fonctionnels, tests de charges,… pour simuler les clients on utilise des injecteurs qui doivent être "programmer".
    Tu peux faire tout à la main à coup de commande Curl ou utiliser un logiciel dédié (jmeter,… liste non exhaustive en début d'article).
    Dans ces logiciels tu peux de même tout décrire les scénarios à la main ou lancer un proxy http dédié qui intercepte les requêtes et les réponses. Le logiciel pourra ensuite les rejouer (bien sur, il est possible de variabiliser les requêtes et contrôler les réponses attendus).

    Dans le cas de jmetre que je connais un peu, on te propose de lancer un proxy et de modifier la configuration de ton navigateur pour l'utiliser.

    Ici l'idée pour simplifier l'utilisation pour l'utilisateur non technique et leur permettre de créer les scénarios et de (si j'ai tout bien compris):

    • se rendre sur "le site du proxy"
    • soumettre l'url cible
    • le proxy sert la page en prenant soin de modifier toutes les urls pour que le clic suivant passe toujours par lui

    => les requêtes sont mémorisés et peuvent ensuite être charger dans CLIF pour être rejouées dans le cadre de tests automatisés.

  • [^] # Re: Fédération

    Posté par (page perso) . En réponse au message Quel logiciel pour gérer une base d'utilisateurs centralisée ?. Évalué à 2.

    Pour la base Nextcloud > il provisionne à la volé les comptes. quand le compte est désactivé coté IdP, l'utilisateur ne peut plus s’authentifie
    serveur mail et ejabberd : Je ne sais pas. pas encore eu l’occasion de jouer. Mais il est possible en se basant sur le même référentiel (ldap ?) au minimun d'avoir du Common sign on et d'utiliser IdP pour la gestion des utilisateurs et "des authentifications web"

    FreeIPA permet de faire de la gestion d'identité (et pas de l'authentification), qui est peut-etre du coup la solution pour ton cas https://connect.ed-diamond.com/GNU-Linux-Magazine/GLMF-186/Gestion-d-identite-avec-FreeIPA

  • [^] # Re: Fédération

    Posté par (page perso) . En réponse au message Quel logiciel pour gérer une base d'utilisateurs centralisée ?. Évalué à 3. Dernière modification le 29/05/18 à 16:15.

    Beaucoup, (mais pas toutes, c'est surtout dans le monde web, même si ça évolue) applications sont capable de déléguer leur authentification à une application dédié (dans le language SAML V2, on l'appel IdP : Identity Provider).
    lorsque l'application à besoin d'authentifier un utilisateur, elle le redirige vers son IdP qui se charge de la partie authentification proprement dite (et est capable de détecter si un utilisateur est déjà connecter via sa session et donc de ne pas redemander l'authentification dans se cas. C'est donc transparent pour l'utilisateur). Une fois l'utilisateur authentifié, l'IdP envoie un jeton d'authentification à l'application. L'appliation n'a plus qu'a truster ce dernier pour ouvrir "ses portes" sans avoir connaissance des identifiants mot de passe de l'utilisateur.

    en SAML la sécurité se base essentiellement par de la signature de jetons (le chiffrement et aussi possible). Tout passe par le navigateur, il n'y a pas besoin d'ouverture de flux.

    en OpenId Connect, cela depend du token utilisé et du flow utilisé :

    • access_token : doit être valider par le client au prêt de "l'IdP"

    • un id_token, tout comme SAML est signé et est donc autoporteur

    Note : OpenId Connect est utilisé par google, facebook,… pour leur authentification sociale. C'est aussi le protocole utilisé par france connect. SAML lui est beaucoup utilisé en entreprise ou université (exemple renater : https://services.renater.fr/federation/introduction/comment-ca-marche) car la techno est plus ancienne.

    Note 2 : d'autres IdP que keycloak existe : shibboleth, simplesamlphp, …

  • # Fédération

    Posté par (page perso) . En réponse au message Quel logiciel pour gérer une base d'utilisateurs centralisée ?. Évalué à 1.

    yop, si tu souhaites gérer des authentifications utilisateurs sur des services web (type nextcloud) la fédération est là pour ça (SAML V2, OpenId Connect) !
    Un petit keycloak (avec ou non un ldap en backend) te permettra de faire les authentifications, délégué à d'autre provider d'identité pour les utilisateur qui le souhaite, utiliser l'application FreeOTP pour faire de l'authentification forte pour les utilisateur qui le souhaite, gérer une politique de mot de passe et de renouvellement,…
    Par contre pour le mail, nextcloud fait du rejeu de mot de passe (de mémoire), qu'il n'aura plus. L'authentification sur le mail sera donc plus délicat. Il est certainement possible (si pas déjà fait !) de faire dès choses quand même !

  • # Nextcloud + Duplicati

    Posté par (page perso) . En réponse au message Nexcloud ou Seafile avec versionning et surtout chiffrement de bout en bout. Évalué à 1.

    salut,
    tu peux utiliser le chiffrement intégré à Nextcloud et y ajouter le versionning de Duplicati sur le dossier data de Nextcloud. C'est pas complètement intégré, mais il doit y avoir de faire des choses….

  • [^] # Re: Article pas terrible

    Posté par (page perso) . En réponse au journal [liens] Mais juste un. Évalué à 4.

    Un très bon roman dont le personne principal joue dans sa tête : le joueur d'échec de Stefan Zweig. Attention on est plus très loin du point godwin…

  • [^] # Re: Aigreur, quand tu nous tiens

    Posté par (page perso) . En réponse au journal ils l'ont voulu, ils l'ont obtenu, et ils l'ont dans le baba.... Évalué à 3.

    Cela dépend du retard, mais il n'est pas irrationnel de faire perdre 5 minutes à certaines personnes pour éviter d'en faire perdre 60 à d'autres.

    Et donc peut-etre faire perdre une correspondance à certaines personnes qui était dans le train en temps et en heure. La correspondance pouvant être SNCF (on retarde aussi le ce train est c'est le domino) ou non SNCF comme une ligne de CAR, un avion,…

    De mémoire, a une certaine époque, il faisait attendre les train quand c’était le dernier de la journée (une règle comme une autre qui est pas déconnante. Et si tu la connais il est possible de la prendre en compte)

  • [^] # Re: Très Pratique !

    Posté par (page perso) . En réponse au sondage Que pensez-vous des liseuses ?. Évalué à 7.

    C'est dommage de lire sur une tablette, c'est tellement plus confort sur une liseuse !

  • [^] # Re: Mots de passe Active Directory

    Posté par (page perso) . En réponse à la dépêche Sortie de LDAP Tool Box Self Service Password 1.1. Évalué à 2.

    L'attribut est en lecture seul.

    Idem pour userPassword

    Le userPassword est lisible dans certain cas (utilisation du compte pour de l'autologon de poste je crois). Du coup une petite recherche (&(objectClass=user)(userPassword=*)) donne des fois quelques surprises :)

    A noter que le pwdlastset est mis à jour à chaque changement de mot de passe.