Sécuriser ses ap is avec oauth2 jug montpellier 16 avril 2014Damien Boissin
Présentation d'oauth 2 et d'openid connect au Jug Montpellier.
Elle traite la question de l'utilisation d'une api par une application tierce et d'authentifier les utilisateurs de cette application.
Paris Web 2015 - France Connect et OpenId ConnectFrançois Petitit
France Connect est un nouvel outil mis en œuvre par la DISIC et visant à améliorer l'accès aux administrations françaises en facilitant l'authentification et l'identification des usagers ainsi que l'échange de données. Pour cela, nous avons utilisé le protocole OpenID Connect.
Ce protocole ouvert basé sur OAuth2, successeur de OpenID, et soutenu par des grands acteurs, permet à une application cliente d'utiliser n'importe quel fournisseur d'identité pourvu qu'il implémente aussi ce standard.
contact : fpetitit@octo.com, @francoispetitit
Nous verrons dans cette présentation quels sont les cas d'usages de ce protocole (authentification sur le web, sur des applications mobiles…), quels sont ses avantages et inconvénients, et comment le mettre en oeuvre.
Sécuriser ses ap is avec oauth2 jug montpellier 16 avril 2014Damien Boissin
Présentation d'oauth 2 et d'openid connect au Jug Montpellier.
Elle traite la question de l'utilisation d'une api par une application tierce et d'authentifier les utilisateurs de cette application.
Paris Web 2015 - France Connect et OpenId ConnectFrançois Petitit
France Connect est un nouvel outil mis en œuvre par la DISIC et visant à améliorer l'accès aux administrations françaises en facilitant l'authentification et l'identification des usagers ainsi que l'échange de données. Pour cela, nous avons utilisé le protocole OpenID Connect.
Ce protocole ouvert basé sur OAuth2, successeur de OpenID, et soutenu par des grands acteurs, permet à une application cliente d'utiliser n'importe quel fournisseur d'identité pourvu qu'il implémente aussi ce standard.
contact : fpetitit@octo.com, @francoispetitit
Nous verrons dans cette présentation quels sont les cas d'usages de ce protocole (authentification sur le web, sur des applications mobiles…), quels sont ses avantages et inconvénients, et comment le mettre en oeuvre.
Avec la multiplication des applications Web, la question de l’authentification à ces applications est devenue primordiale. Pour simplifier la vie de l’utilisateur, le concept de SSO (Single Sign On) a été inventé. Dans ce domaine, plusieurs protocoles et standards existent, comme CAS, OpenID, Liberty Alliance, Shibboleth ou SAML.
Quelles sont les différences ? Comment utiliser ces protocoles dans les applications ? Cette conférence tentera de répondre à ces questions en présentant des cas concrets d’implémentation.
Application Security Forum 2011
27.10.2011 - Yverdon-les-Bains (Suisse)
Conférencier: Clément Oudot
CAS, OpenID, Shibboleth, SAML : concepts, différences et exemplesClément OUDOT
Avec la multiplication des applications Web, la question de l’authentification à ces applications est devenue primordiale. Pour simplifier la vie de l’utilisateur, le concept de SSO (Single Sign On) a été inventé. Dans ce domaine, plusieurs protocoles et standards existent, comme CAS, OpenID, Liberty Alliance, Shibboleth ou SAML. Quelles sont les différences ? Comment utiliser ces protocoles dans les applications ? Cette conférence tentera de répondre à ces questions en présentant des cas concrets d’implémentation.
Dans un monde où la mobilité devient omniprésente, où les applications et les services en ligne ont un besoin grandissant de s’échanger de l’information, des technologies qui permettent de soutenir cette transformation de façon sécuritaire sont nécessaires. Pour faire face à cette nouvelle réalité, Oauth et OpenID Connect ont vu le jour et en raison de leur adoption par des acteurs influents de l’industrie, leur utilisation est pratiquement devenue un incontournable. Cette présentation se veut un survol du « framework » Oauth 2.0 ainsi que du protocole OpenID Connect 1.0. Ensemble, nous prendrons connaissance des raisons d’être de chacune de ces technologies, de leurs particularités et de leur fonctionnement. Nous poursuivrons avec des mises en contexte concrètes et terminerons avec un survol des vulnérabilités associées.
ASFWS 2012 - OAuth : un protocole d’autorisation qui authentifie ? par Maxime...Cyber Security Alliance
“Sign-in using your facebook, google, linked-in or twitter account…”
Porté notamment par les grands acteurs des réseaux sociaux, Oauth est devenu un standard difficilement contournable dans le paysage de la fédération d’identité.
Authentifier c’est s’assurer qu’une entité est bien celle qu’elle prétend être. Oauth, quant à lui, se définit comme un “framework” d’autorisation permettant à des applications d’accéder aux données d’un utilisateur en lui demandant sa permission.
Pourtant un usage important (Sign-in) semble être l’authentification…
Simple question de sémantique ? Ou réelle subtilité, qui mal comprise, pourrait nous conduire à de mauvaises implémentations ?
En ayant a cœur de répondre à cette question, cette présentation propose de regarder “sous le capot” de ce protocole. De Oauth 1.0 a Oauth 2.0 comment est-ce que cela fonctionne ? est-ce vrai qu’un token d’accès Oauth peut être réutilisé pour “usurper une identité” ? Et par rapport à SAML & OpenId : est-ce différent ou complémentaire ?
S2LQ - Authentification unique sur le Web avec le logiciel libre LemonLDAP::NGClément OUDOT
LemonLDAP::NG est un logiciel libre de WebSSO et contrôle d'accès implémentant les principaux standards du marché comme CAS, SAML et OpenIDConnect. Intégré nativement aux distributions GNU/Linux, c'est une alternative très prisée de logiciels comme CA SiteMinder, Active Directory Federation Services, JASIG CAS, Shibboleth ou encore ForgeRock OpenAM. Il est très utilisé en France en particulier dans les Ministères (Finances, Culture, Justice, Gendarmerie Nationale, Agriculture, Intérieur) et les collectivités territoriales (Métropole de Montpellier, Ville de Villeurbanne, Métropole de Nantes).
OAuth 2.0 est un standard d'autorisation moderne (comprendre avec du JSON partout) qui permet de controller l'accès aux resources web. Cette présentation vous apprendra les pas de danse OAuth 2.0, et vous initiera à la chorégraphie OpenId Connect. On parlera aussi des nouveautés: UMA, PoP, Privacy, Consent et autres acronymes barbares.
SAML, Open ID et CAS dans un seul WebSSO : LemonLDAP::NGClément OUDOT
SAML, Open ID et CAS dans un seul WebSSO : LemonLDAP::NG
at Solutions Linux / Open Source
LemonLDAP::NG est un logiciel libre de WebSSO et de contrôle d'accès aux applications Web. C'est également un fournisseur d'identités SAML, CAS et OpenID.
Vous découvrirez lors de cette conférence comment il est possible de s'affranchir de la gestion du mot de passe de ses utilisateurs, en déléguant l'authentification et les contrôle d'accès à une application à un produit de WebSSO.
Cela permet d'intégrer l'application sans effort dans des systèmes d'informations hétérogènes, en reposant sur des méthodes aussi diverses que les annuaires LDAP, les bases de données, les certificats SSL, Kerberos, etc.
La fonctionnalité de fournisseur d'identité permet également d'établir un cercle de confiance, pour par exemple propager l'authentification des utilisateurs aux applications “cloud”, comme Google Apps ou SalesForce.
Présentation de LemonLDAP::NG aux Journées Perl 2016Clément OUDOT
LemonLDAP::NG supporte de nombreux protocoles comme CAS, OpenID Connect et SAML. Au travers de cette présentation nous verrons les principes de fonctionnement du logiciel ainsi que les technologies Perl utilisées (Mouse, PSGI, Net::LDAP, Apache::Session, Cache::Cache, etc.)
Ce retour d’expérience sera l’occasion d’aborder de façon pragmatique les aspects suivants :
- La PKI : un service de commodité.
- Notions de Base.
- Identification des pré-requis (sujet, usage, séquestre, carte à puce, vitesse de révocation, publication, CPS…)
- Conception de la hiérarchie des autorités de certification (Hiérarchie, taille et durée de validité des clefs, HSM, matrice des rôles…)
- Stratégie de révocation (CRL, CDP, OCSP…)
- Stratégie d’enrôlement (automatique, autorité d’enregistrement…)
Human talks paris - OpenID Connect et FranceConnect - Francois Petitit - 7 ju...François Petitit
Support de la présentation sur l'utilisation du protocole OpenID Connect, basé sur OAuth2, sur le projet FranceConnect.
Présenation donnée par François Petitit lors de la soirée HumanTalks Paris le 7 juillet 2015
An IAM for Beginner's session presented by Dr. Matthias Tristl, ForgeRock Senior Instructor
Learn more about ForgeRock Access Management:
https://www.forgerock.com/platform/access-management/
Learn more about ForgeRock Identity Management:
https://www.forgerock.com/platform/identity-management/
Avec la multiplication des applications Web, la question de l’authentification à ces applications est devenue primordiale. Pour simplifier la vie de l’utilisateur, le concept de SSO (Single Sign On) a été inventé. Dans ce domaine, plusieurs protocoles et standards existent, comme CAS, OpenID, Liberty Alliance, Shibboleth ou SAML.
Quelles sont les différences ? Comment utiliser ces protocoles dans les applications ? Cette conférence tentera de répondre à ces questions en présentant des cas concrets d’implémentation.
Application Security Forum 2011
27.10.2011 - Yverdon-les-Bains (Suisse)
Conférencier: Clément Oudot
CAS, OpenID, Shibboleth, SAML : concepts, différences et exemplesClément OUDOT
Avec la multiplication des applications Web, la question de l’authentification à ces applications est devenue primordiale. Pour simplifier la vie de l’utilisateur, le concept de SSO (Single Sign On) a été inventé. Dans ce domaine, plusieurs protocoles et standards existent, comme CAS, OpenID, Liberty Alliance, Shibboleth ou SAML. Quelles sont les différences ? Comment utiliser ces protocoles dans les applications ? Cette conférence tentera de répondre à ces questions en présentant des cas concrets d’implémentation.
Dans un monde où la mobilité devient omniprésente, où les applications et les services en ligne ont un besoin grandissant de s’échanger de l’information, des technologies qui permettent de soutenir cette transformation de façon sécuritaire sont nécessaires. Pour faire face à cette nouvelle réalité, Oauth et OpenID Connect ont vu le jour et en raison de leur adoption par des acteurs influents de l’industrie, leur utilisation est pratiquement devenue un incontournable. Cette présentation se veut un survol du « framework » Oauth 2.0 ainsi que du protocole OpenID Connect 1.0. Ensemble, nous prendrons connaissance des raisons d’être de chacune de ces technologies, de leurs particularités et de leur fonctionnement. Nous poursuivrons avec des mises en contexte concrètes et terminerons avec un survol des vulnérabilités associées.
ASFWS 2012 - OAuth : un protocole d’autorisation qui authentifie ? par Maxime...Cyber Security Alliance
“Sign-in using your facebook, google, linked-in or twitter account…”
Porté notamment par les grands acteurs des réseaux sociaux, Oauth est devenu un standard difficilement contournable dans le paysage de la fédération d’identité.
Authentifier c’est s’assurer qu’une entité est bien celle qu’elle prétend être. Oauth, quant à lui, se définit comme un “framework” d’autorisation permettant à des applications d’accéder aux données d’un utilisateur en lui demandant sa permission.
Pourtant un usage important (Sign-in) semble être l’authentification…
Simple question de sémantique ? Ou réelle subtilité, qui mal comprise, pourrait nous conduire à de mauvaises implémentations ?
En ayant a cœur de répondre à cette question, cette présentation propose de regarder “sous le capot” de ce protocole. De Oauth 1.0 a Oauth 2.0 comment est-ce que cela fonctionne ? est-ce vrai qu’un token d’accès Oauth peut être réutilisé pour “usurper une identité” ? Et par rapport à SAML & OpenId : est-ce différent ou complémentaire ?
S2LQ - Authentification unique sur le Web avec le logiciel libre LemonLDAP::NGClément OUDOT
LemonLDAP::NG est un logiciel libre de WebSSO et contrôle d'accès implémentant les principaux standards du marché comme CAS, SAML et OpenIDConnect. Intégré nativement aux distributions GNU/Linux, c'est une alternative très prisée de logiciels comme CA SiteMinder, Active Directory Federation Services, JASIG CAS, Shibboleth ou encore ForgeRock OpenAM. Il est très utilisé en France en particulier dans les Ministères (Finances, Culture, Justice, Gendarmerie Nationale, Agriculture, Intérieur) et les collectivités territoriales (Métropole de Montpellier, Ville de Villeurbanne, Métropole de Nantes).
OAuth 2.0 est un standard d'autorisation moderne (comprendre avec du JSON partout) qui permet de controller l'accès aux resources web. Cette présentation vous apprendra les pas de danse OAuth 2.0, et vous initiera à la chorégraphie OpenId Connect. On parlera aussi des nouveautés: UMA, PoP, Privacy, Consent et autres acronymes barbares.
SAML, Open ID et CAS dans un seul WebSSO : LemonLDAP::NGClément OUDOT
SAML, Open ID et CAS dans un seul WebSSO : LemonLDAP::NG
at Solutions Linux / Open Source
LemonLDAP::NG est un logiciel libre de WebSSO et de contrôle d'accès aux applications Web. C'est également un fournisseur d'identités SAML, CAS et OpenID.
Vous découvrirez lors de cette conférence comment il est possible de s'affranchir de la gestion du mot de passe de ses utilisateurs, en déléguant l'authentification et les contrôle d'accès à une application à un produit de WebSSO.
Cela permet d'intégrer l'application sans effort dans des systèmes d'informations hétérogènes, en reposant sur des méthodes aussi diverses que les annuaires LDAP, les bases de données, les certificats SSL, Kerberos, etc.
La fonctionnalité de fournisseur d'identité permet également d'établir un cercle de confiance, pour par exemple propager l'authentification des utilisateurs aux applications “cloud”, comme Google Apps ou SalesForce.
Présentation de LemonLDAP::NG aux Journées Perl 2016Clément OUDOT
LemonLDAP::NG supporte de nombreux protocoles comme CAS, OpenID Connect et SAML. Au travers de cette présentation nous verrons les principes de fonctionnement du logiciel ainsi que les technologies Perl utilisées (Mouse, PSGI, Net::LDAP, Apache::Session, Cache::Cache, etc.)
Ce retour d’expérience sera l’occasion d’aborder de façon pragmatique les aspects suivants :
- La PKI : un service de commodité.
- Notions de Base.
- Identification des pré-requis (sujet, usage, séquestre, carte à puce, vitesse de révocation, publication, CPS…)
- Conception de la hiérarchie des autorités de certification (Hiérarchie, taille et durée de validité des clefs, HSM, matrice des rôles…)
- Stratégie de révocation (CRL, CDP, OCSP…)
- Stratégie d’enrôlement (automatique, autorité d’enregistrement…)
Human talks paris - OpenID Connect et FranceConnect - Francois Petitit - 7 ju...François Petitit
Support de la présentation sur l'utilisation du protocole OpenID Connect, basé sur OAuth2, sur le projet FranceConnect.
Présenation donnée par François Petitit lors de la soirée HumanTalks Paris le 7 juillet 2015
An IAM for Beginner's session presented by Dr. Matthias Tristl, ForgeRock Senior Instructor
Learn more about ForgeRock Access Management:
https://www.forgerock.com/platform/access-management/
Learn more about ForgeRock Identity Management:
https://www.forgerock.com/platform/identity-management/
Shoot Me a Token: OpenAM as an OAuth2 ProviderForgeRock
Presented by Victor Ake, OpenAM Product Manager and ForgeRock Co-Founder at ForgeRock Open Stack Identity Summit. June 2013
Learn more about ForgeRock Access Management:
https://www.forgerock.com/platform/access-management/
Learn more about ForgeRock Identity Management:
https://www.forgerock.com/platform/identity-management/
Nat Sakimura, Senior Researcher, Information Tech. Research Dept, Nomura Research Institute
OpenID Connect is a layer on top of the OAuth 2.0 protocol that adds critical identity-related information and validation to API interactions. Targeted both towards Web SSO and native application scenarios, OpenID Connect defines all the pieces necessary for an IT department to deliver an industry best practice identity regime based on the OAuth 2.0 protocol. Join Nat Sakimura to find out about ID Tokens, userinfo REST endpoints, dynamic client registration, session management, discovery, and all the other important concepts that OpenID Connect standardizes.
CIS 2015 Extreme OpenID Connect - John BradleyCloudIDSummit
Entreprises are deploying more applications to workers phones and tablets. These applications are currently all using separate authentications to establish user identity and authorization.
This session will look at how the Native Application profile of OpenID Connect creates a local token broker on the device to centralize authentication for multiple enterprise and SaaS applications on a device.
This can be used to increase security by enabling additional authentication factors and a enhanced view of device posture, as well as increasing usability, bu reducing the number of unnecessary authentications that interrupt the users work flow every day.
SAML, developed by the Security Services
Technical Committee of the Organization for the
Advancement of Structured Information Standards
(OASIS), is an XML-based framework for
communicating user authentication, entitlement,
and attribute information. As its name suggests,
SAML allows business entities to make assertions
regarding the identity, attributes, and entitlements of
a subject (an entity that is often a human user) to
other entities, such as a partner company or
another enterprise application.
La gestion des identités pour qui, pourquoi ?Benoit Mortier
Conférence sur le concept de la gestion des identités, pourquoi c'est important, quels sont les technologies disponible et comment réaliser cela avec des logiciels libres
Vous avez dit protocoles Web d’authentification et d’autorisation ! De quoi p...Microsoft
L'authentification unique (fédérée), l’autorisation (déléguée), le « provisioning » sont autant de services devenus essentiels pour l’entreprise désormais étendue à la fois en local et à travers le Cloud (hybride). Avec la souscription croissante d’abonnements à des applications SaaS (Software-as-a-Service), l’utilisation du Cloud (hybride) pour des applications cœur de métier, l’utilisation d’APIs Web RESTful spécialisées avec ce qu’il convient désormais d’appeler l’économie des APIs, le désir de mieux collaborer en interne « à la » Facebook et/ou d’interagir directement avec les réseaux sociaux, les protocoles liés à la gestion des identités et des accès constituent la pierre angulaire de ces dynamiques pour « parler » et établir des « ponts » d’identité et d’accès au-delà des frontières de l’organisation. Cette session vise à démystifier certains de ces protocoles (modernes) fondés sur HTTP. Parmi le choix des possibles en termes de protocoles et de standards, cette session s’intéressera plus particulièrement à des protocoles comme SAML 2.0, WS-Federation et OAuth 2.0, qui sont aujourd'hui très largement répandues voir incontournables avec les applications Web et mobile ainsi qu’avec les APIs Web. La session couvrira également OpenID Connect et effleura également SCIM, deux protocoles qui deviendront à n’en point douter des plus importants dans les prochains mois. Si certains de ces protocoles ont déjà été une source de confusion pour vous ou si vous voulez juste comprendre ce qu'ils font et ce qu’ils peuvent apporter dans vos projets ou pas, alors ne manquez pas cette session.
Speakers : Philippe Beraud (Microsoft), Arnaud Jumelet (Microsoft France), Jean-Yves Grasset (Microsoft)
Ce Support explique quelques concepts de base de NodeJS et montre comment mettre en oeuvre la technologie NodeJS pour développer la partie Backend d'une application.
Les vidéos des démonstrations sont publiées sur les adresse suivantes :
- https://www.youtube.com/watch?v=-X_C1tS5-9Y
- https://www.youtube.com/watch?v=rE-xRH28m0s
- https://www.youtube.com/watch?v=tnxjkTvWoKA
Cette série explique les éléments suivants :
- Architecture Web
- Modèles Multi-Threads avec les entrées sorties bloquantes
- Modèles Single Thread avec les entrées sortie non bloquantes
-Technologie Node JS
- Comment créer une simple application Node JS avec java Script
- Architecture du Framwork Express
- Comment créer une application NodeJS avec Type Script
- Comment écrire des tests unitaires avec Jest
- Quelques concepts sur MongoDb
- Comment Créer une API Rest avec NodeJS, Express et MongoDb
- Comment tester l'API Rest
- Comment Créer la partie FrontEnd avec Angular.
Même si la qualité audio n'est pas bonne, ses vidéos peuvent aider ceux qui débutent dans NodeJS en attendant d'autres vidéos avec plus qualité audio et de contenu.
Bonne lecture
Blockchain et Smart Contract : de la théorie à la productionMathieu Durand
Présentation faite au Breizhcamp 2019
Blockchain, Ethereum, Smart-Contracts... on en entend souvent parler mais qu'est ce que ça donne réellement en production ?
Cette conférence sera l'occasion de présenter notre REX de mise en production d'une application web basée sur l'utilisation de Smart Contract Ethereum. Après avoir présenté brièvement les concepts clés de Blockchain Ethereum et Smart Contract, nous présenterons notre retour d'expérience sur le développement d'une application VueJs/Java permettant l'échange de cryptomonnaie dite "tokenisée" (EC-20) via Smart Contract Ethereum.
Présentation effectuée au Meetup Lizard Secu (27 aout 2020)par Christophe Villeneuve sur "Le futur de l'authentification WebAuthn".
Vous allez voir comment se passer du mot de passe en utilisant WebAuthn
Developpé dans le cadre de:
- Unité d'Ensseignement: DEVELOPPEMENT WEB ET MULTIMEDIA 2 comportant:
Matière(1): Programmation Web2
Matière(2): Atelier Développement Webet Multimédia II
Pour les étudiants de la la licenece en Technologies de l’Informatique (TI) - TC-Semestre 2
Par: Mohamed Mhamdi- Iset de Sousse(Tunisie)
(Azure) Active Directory + BYOD = tranquillité d’esprit, chiche ! (2nde Partie)Microsoft Décideurs IT
Aujourd'hui, tout un chacun souhaite aspire à travailler de n'importe où, sur n'importe quel appareil, etc. Comment permettre une telle expérience avec les ressources internes et dans le cloud (hybride) de l’entreprise, tout en conservant le contrôle dans le contexte du BYOD (Amenez votre propre appareil). Sur la base de l’enregistrement d’appareils abordé dans la première partie (session SEC306), cette session illustrera comment configurer les stratégies d’accès conditionnel qui s'appuient d'une manière souple et intuitive sur les nouvelles capacités d’AD FS comme la connaissance des emplacements réseau, l'authentification de l'appareil et l'authentification à facteurs multiples. Elle abordera comment vous pouvez contrôler les méthodes d'authentification qui sont mises à disposition des utilisateurs finaux, comment ajouter des fournisseurs d'authentification supplémentaires et bien sûr comment configurer des stratégies distinctes régissant les accès extranet. Cette session explore au final comment AD FS (et Azure AD) vous permet d'éviter les scénarios de type « Amener votre propre désastre » (BYOD) ;-) en offrant le niveau de confiance appropriée pour l’accès aux ressources de l'entreprise.
(Azure) Active Directory + BYOD = tranquillité d’esprit, chiche ! (2nde Partie)Microsoft Technet France
Aujourd'hui, tout un chacun souhaite aspire à travailler de n'importe où, sur n'importe quel appareil, etc. Comment permettre une telle expérience avec les ressources internes et dans le cloud (hybride) de l’entreprise, tout en conservant le contrôle dans le contexte du BYOD (Amenez votre propre appareil). Sur la base de l’enregistrement d’appareils abordé dans la première partie (session SEC306), cette session illustrera comment configurer les stratégies d’accès conditionnel qui s'appuient d'une manière souple et intuitive sur les nouvelles capacités d’AD FS comme la connaissance des emplacements réseau, l'authentification de l'appareil et l'authentification à facteurs multiples. Elle abordera comment vous pouvez contrôler les méthodes d'authentification qui sont mises à disposition des utilisateurs finaux, comment ajouter des fournisseurs d'authentification supplémentaires et bien sûr comment configurer des stratégies distinctes régissant les accès extranet. Cette session explore au final comment AD FS (et Azure AD) vous permet d'éviter les scénarios de type « Amener votre propre désastre » (BYOD) ;-) en offrant le niveau de confiance appropriée pour l’accès aux ressources de l'entreprise.
Socket tcp ip client server on langace c mouad Lousimi
Les sockets sont des flux de données, permettant à des machines locales ou distantes de communiquer entre elles via des protocoles.
Les différents protocoles sont TCP qui est un protocole dit "connecté", et UDP qui est un protocole dit "non connecté".
Nous allons voir par la suite comment réaliser diverses applications telles qu'un client/serveur TCP
Quelle approche préventive adopter pour empêcher les mouvements latéraux au s...Identity Days
Une conférence proposée par Anne-Sophie Goeldner & Matthieu Masson
Pour gagner du temps dans l’exécution de leurs attaques, les adversaires utilisent des comptes valides depuis quelques années. Pour s’en emparer, ils exploitent notamment des mécanismes et des failles propres à l’AD. Une fois en possession d’identifiants compromis, leur objectif est toujours le même : réaliser des mouvements latéraux, obtenir plus de privilèges si nécessaire et compromettre un domaine pour en exfiltrer ses données.
Il est utopique de penser qu’on peut empêcher un adversaire avec des identifiants valides de s’introduire au sein d’un environnement. Et bien souvent, il est trop tard lorsqu’on arrive à détecter une attaque basée sur l’identité. Alors quelle approche adopter ? Nous pensons que la seule approche efficace consiste à entraver sa capacité à se déplacer latéralement dans l’environnement cible.
Article "Un an de télétravail et de COVID" dans le magazine StartPascal Flamand
Billet d'humeur dans le magazine Start : Retour d’expérience d’un chef d’entreprise et de ses équipes; autres considérations oiseuses sur la résilience des organisations…
Article "La tyrannie du risque zéro" dans le magazine StartPascal Flamand
Billet d'humeur dans le magazine Start : « Fais pas ci, fais pas ça, Viens ici, mets-toi là, Attention, prends pas froid, Ou sinon gare à toi, Mange ta soupe, allez, brosse toi les dents, Touche pas ça, fais dodo, Dis papa, dis maman, Fais pas ci fais pas ça » Qui aurait pu croire que l’injonction de Jacques Dutronc deviendrait le slogan de notre société déboussolée du début du 21 e siècle ? Les hérauts de l’interdiction, les chantres de la
réglementation, les régulateurs de la vie humaine ont pris le pouvoir...
Article "quand les licornes voleront..." dans le magazine StartPascal Flamand
Billet d'humeur dans le magazine Start : Oyez, oyez braves gens, un récent – à l’aune temporelle de cette noble institution, reconnue pour sa jeunesse et son agilité -rapport du Sénat (à retrouver sur senat.fr) met en avant les manques cruels et flagrants de notre industrie numérique nationale....
Pourquoi Busit et Jaguards rapprochent leurs offres : Les deux entreprises, l'une basée à Nice et l'autre à Sophia-Antipolis, rapprochent leur offre individuelle en une offre commune. Le but, notamment, est d'adresser un marché plus large avec une solution de bout en bout. A commencer par la maintenance industrielle
JAGUARDS, éditeur de solutions de gestion opérationnelle, de maintenance et de traçabilité des évènements de sécurité, et BUSIT, éditeur de solutions de pilotage IoT, Big Data et analytique dédiées à la gouvernance et la maîtrise énergétique du bâtiment et de l’industrie, sont heureuses d’annoncer leur partenariat en vue de proposer une offre commune, pour répondre aux enjeux de maintenance industrielle.
2. Agenda
● OIDC concepts
● OIDC flows
● Using OIDC with refresh token
● OIDC OpenAM use case example
3. OpenID connect
● OIDC est défini a l'URL :
– http://openid.net/specs/openid-connect-core-1_0.html
● OpenID connect est Oauth2 + Authentification :
– OpenID Connect 1.0 est un simple layer d'identité construit au dessus
de oauth2.
– Il permet a des clients de vérifier leur identité auprès d'un serveur
d'autorisation, et d'obtenir des informations sur l'utilisateur d'une façon
JSON/REST-like.
– Oauth2 fournit un access token
– OIDC fournit un ID token
4. Role d'un access token ou d'un ID
token
● Access Token :
– Le rôle d'un access token peux être comparé a celui d'un billet de banque :
● On a besoin de savoir si le billet de banque est valide pour effectuer une
transaction, mais le billet de banque « n'a pas de propriétaire attitré)
● L'access token est valide que pour une période prédéterminée
● ID_Token :
– Le rôle de l'id_token est similaire à celui d'une carte d'identité. L'ID token permet
de prouver l'identité de l'utilisateur grâce a la signature, mais est seulement
valable pour une période donné.
5. OpenID connect
● Les rôles définis dans OpenID connect sont :
– End-User (OAuth 2.0 resource owner), dont les informations sont
accedees par l'application.
– Relying Party (RP) (OAuth 2.0 client) qui accède aux données
protégées de l'utilisateur.
– OpenID Provider (OP) (OAuth 2.0 authorization server and also
resource server) qui contient les données de l'utilisateur, et permet les
accès
6. ● Le protocole OpenID Connect suit les étapes suivantes
– Le RP (Cllient) envoie une requête au OpenID provider (OP)
– Le OP authentifie le end-user et obtient une autorisation
– Le OP répond avec un ID token, et éventuellement un access token
– Le RP peux faire des requêtes avec l'access token auprès du userinfo endpoint
– Le userInfo endpoint retourne des claims au sujet du end-user
7. Flow OpenID Connect (1)
● OpenID Connect fournit 3 type de flows :
– Authorization Code flow
– Implicit Flow
– Hybrid Flow
Le type de flow a utiliser va être déterminé par le paramètre de
requête response_type .
8. Flow OpenID Connect (2)
● Authorization Code Flow
– Designed pour les applications utilisant oauth2 autorisation grant type
● Implicit Flow
– Designed pour les RP (Relying Party) qui utilisent oauth2 en mode implicite.
– Ne permet pas la délivrance de refresh token.
● Hybrid Flow
– Permet la delivrance d'Id Token, acces token et refresh token pour les besoins
EDF.
– Approche validé avec forgerock dans le ticket #16900: Using OIDC with
Refresh token - access tokens and ID token generated using authoriwation
code (Foregrock utilise openAM 14 en cours de développement)
9. OpenID Connect Concepts (1)
response_type" value Flow
code Authorization Code Flow
id_token Implicit Flow
id_token token Implicit Flow
code id_token Hybrid Flow
code token Hybrid Flow
code id_token token Hybrid Flow
● Le flow utilisé est déterminé par la valeur response_type
contenu dans la requete de demande.
● (cf http://openid.net/specs/openid-connect-core-1_0.html#Authentication)
10. Lifecycle de OIDC avec OpenAM
pour utiliser des refresh token (1)
Prérequis :
● OpenAM est configuré en tant que Oauth2/OIDC provider
● Clients
– Le client est enregistré auprès de L'oauth2/OIDC provider avec
clientID (nom du client), client secret (password de l'application)
– le refresh token a une durée de vie de 1 an
– L’autorisation code a une durée de vie courte (30s à une minute)
– L'access token et refresh token et id_token ont une durée de vie courte
● L'ID token a une durée de vie de 1heure chez google par exemple.
● L'access token/refresh token ont une durée de vie courte (quelques
minutes).
– Tous ces paramètres sont configurables
11. Lifecycle de OIDC avec OpenAM
pour utiliser des refresh token (2)
● Resfresh Token
– Le Refresh token est unique pour un utilisateur donné
– Il permet de regénérer un access token/id_token en utilisant une requete de type
grant_type=refresh_token.
– Il est possible de révoquer un refresh token d'un utilisateur donné.
12. Lifecycle de OIDC avec OpenAM
pour utiliser des refresh token (3)
● Step1: (demande d’autorisation code)
– Requête:L'utilisateur va effectuer un requête de type « code id_token token »
– Réponse : l'utilisateur reçoit un réponse avec code autorisation, access token et
de_token.
● Step2 (utilisation de l'autorisation code)
– Requête : L'utilisateur utilise l'autorisation code
– Réponse : l'utilisateur reçoit un access, refresh token, id_token
clientID (nom du client), client secret (password de l'application)
● Utilisation du refresh Token (au cours de l'année)
– Requête : Utilisation du refresh token
– Génération d'un nouvel access token /id token
14. ID_Token (1)
● ID Token :
– L'ID token se decompose en 3 parties :
● header
● payload
● Signature
– Le header et la payload sont encodes en base 64, et peuvent etre
faciment lus en decodeant leur format en base 64.
– La signature est un hash des composants suivants: header, payload,
secret.
– Le secret est la signauture du serveur, qui permet de verifier des tokens
et d'en signer des nouveaux.
15. ID_Token(2)
● Verification d'un ID Token :
– La verification d'un ID token contient environ une dizaine de points dont
certains optionels.
– Est definit dans la spec openID Connect (3.1.3.7. ID Token Validation,
http://openid.net/specs/openid-connect-core-1_0.html#CodeIDToken)
– Certains points sont quasiment immediat a verifier (sujet, audience,
validite, expiration …)
– D'autre points sont complexes (verfication de la signature, necessitant
l'usage de libraies JWT pour verifier le token)
● Verification d'un access Token
– De meme, il est possible de valider un access token, en utilisant le
champ at_hash de l'id_token et en calculant un hash a partir de l'access
token.
18. Analyse d'un ID_Token (1)
● Un id_token issu de OPENAM est composé de claims.
●
Les claims obligatoires sont :
– iss: Issuer Identifier for the Issuer of the response.
– sub: Subject Identifier. A locally unique and never reassigned identifier within the
Issuer for the End-User
– aud: Audience(s) that this ID Token is intended for. It MUST contain the OAuth
2.0 client_id of the Relying Party as an audience value
– exp: Expiration time on or after which the ID Token MUST NOT be accepted for
processing.
– iat: Time at which the JWT was issued. Its value is a JSON number representing
the number of seconds from 1970-01-01T0:0:0Z as measured in UTC until the
date/time.
19. Analyse d'un ID_Token (2)
●
Les claims optionnelles sont :
– auth_time: Time when the End-User authentication occurred.
– nonce: String value used to associate a Client session with an ID Token, and to
mitigate replay attacks.
– azp : Authorized party - the party to which the ID Token was issued. If present, it
MUST contain the OAuth 2.0 Client ID of this party.
– at_hash:Access Token hash value. Its value is the base64url encoding of the left-
most half of the hash of the octets of the ASCII representation of the
access_token value, where the hash algorithm used is the hash algorithm used
in the alg Header Parameter of the ID Token's Header.
20. Remontée d'information OpenID
● Il existe 2 mécanismes avec openID pour remonter des
informations :
– Utilisation des scope dans les access access token
– Utilisation de claims
● OpenID fourni des claims standard (i.e par défaut), et il est
possible de customiser cette liste avec des attributs spécifiques
– Le mécanisme de customisation des claims fonctionne pas ou mal avec
openam12 (http://www.janua.fr/openid-connect-with-openam/)
– On doit utiliser la feature scope des access tokens pour remonter des infos
depuis le LDAP
25. OIDC example ( part 4) -
(utilisation du refresh token)
+ curl -X POST http://openam.example.com:18080/openam/oauth2/access_token?scope=profile%20mail
%20openid%20employeenumber -u myClientID:oauthclient -d grant_type=refresh_token -d
refresh_token=9a187f2d-4715-4e58-b208-bd5b8d61e769
{"access_token":"8d588b5a-baa7-4df8-96f1-6b52272b7ca9","scope":"employeenumber mail openid
profile","id_token":"eyAidHlwIjogIkpXVCIsICJraWQiOiAiU3lsTEM2Tmp0MUtHUWt0RDlNdCswemNlUVNVPSIsICJ
jdHkiOiAiSldUIiwgImFsZyI6ICJSUzI1NiIgfQ.eyAiYXRfaGFzaCI6ICJfbGdGdEIzZW9YYmFMeVRKZ05LUlJRIiwgIn
N1YiI6ICJkZW1vIiwgImlzcyI6ICJodHRwOi8vb3BlbmFtLmV4YW1wbGUuY29tOjE4MDgwL29wZW5hbS9vYXV0aDI
iLCAidG9rZW5OYW1lIjogImlkX3Rva2VuIiwgImF1ZCI6IFsgIm15Q2xpZW50SUQiIF0sICJvcHMiOiAiNmMyZWIwYj
ctYmMzMS00MjNhLWIyYTQtOTliNTVjZGNhYmQ5IiwgImF6cCI6ICJteUNsaWVudElEIiwgImF1dGhfdGltZSI6IDE0
Nzk0NzkzMjQsICJyZWFsbSI6ICIvIiwgImV4cCI6IDE0Nzk0ODI5MjQsICJ0b2tlblR5cGUiOiAiSldUVG9rZW4iLCAia
WF0IjogMTQ3OTQ3OTMyNCB9.b9IjRpKn6S5_eByN4_Awu6sZslSOPHXRu8GRBNoaUoroXeAieNPTyozKEBuAa
2Dwb2NShicThvzmg0PRxmnPFeNfN0S6A94y6K-u5bjErGxAJjia2Fdx4IicUb6bmXisgCh9aCkxfMCpEUspPqIlAp-
FywGV4q53an-ewrn2x7E","token_type":"Bearer","expires_in":3599}
26. OpenAM et OpenID Connect
● OpenAM permet de definir un OpenID/Oauth2
provider et de meme client Oauth2
● Interfacage :
– Provider
● Definir un Oauth2/OpenID Server provider (IDP openID) en utilisant
OpenAM
● Definir les scopes necessaires
– Client:
● Enregistrer un Oauth2 Client (mode implicite) aupres de l'IDP
openID connect dans l'openAM (possibel de facon dynamique)
● Recuperer 2 jetons dans la reponse: id_token et access_token
● Validations de l'id_token
27. OpenID Connect Concepts (2)
● Dans le cas de mode implicite, les 2 tokens sont
renvoyés dans la reponse. Exemple :
● curl -i --cookie "iplanetDirectoryPro=$1"
http://openam.example.com:18080/openam/oauth2/authorize
--data "realm=%2f&scope=openid%20profile&
response_type=id_token%20token&
client_id=myClientID&
redirect_uri=http://openam.example.com:18080/openid/cb-implicit.html&
decision=Allow"
● Location: http://openam.example.com:18080/openid/cb-implicit.html#access_token=295768a3-6303-47a0-b31a-
5ab82d4f27be&scope=openid
%20profile&id_token=eyAidHlwIjogIkpXVCIsICJraWQiOiAiU3lsTEM2Tmp0MUtHUWt0RDlNdCswemNlUVNVPSIsICJj
dHkiOiAiSldUIiwgImFsZyI6ICJSUzI1NiIgfQ.eyAiYXRfaGFzaCI6ICJMZUlZbkduR3pDMEx5eUZNWk51S2hBIiwgInN1Yi
I6ICJkZW1vIiwgImlzcyI6ICJodHRwOi8vb3BlbmFtLmV4YW1wbGUuY29tOjE4MDgwL29wZW5hbS9vYXV0aDIiLCAidG
9rZW5OYW1lIjogImlkX3Rva2VuIiwgImF1ZCI6IFsgIm15Q2xpZW50SUQiIF0sICJvcHMiOiAiZDBiNWJiNTItYWM2YS00
NjRlLWJlMDItYTY3MjNmNGViZWQ2IiwgImF6cCI6ICJteUNsaWVudElEIiwgImF1dGhfdGltZSI6IDE0Njc4NDI4MTAsIC
JyZWFsbSI6ICIvIiwgImV4cCI6IDE0Njc4NDM0MTAsICJ0b2tlblR5cGUiOiAiSldUVG9rZW4iLCAiaWF0IjogMTQ2Nzg0M
jgxMCB9.asSMNjQ29gqrXtLCkTigswFOhtAN-e8lfeU-nESmK0P09hA7OLhfpR10L1ta-
f646i0i5728OVAqC7du0EP5Bmm9w1xL__JqMzCFXnHI-jYVGKGKVrGIVtIy9kS2Zj86E4zLTVsiy7egX-
ZKXGZSTpNjD8E6yS51mL28Knwvt44&token_type=Bearer&expires_in=8399