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.
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.
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.
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)
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.
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.
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.
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)
(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.
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
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
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.
Recherche sur l'architecture d'un systéme complexe pour un site de freelance .
référence:
https://medium.com/@krishnaanaril/embedding-power-bi-in-angular-part-1-a1847de9a2e8
https://medium.com/@emccul13/socket-io-9bceb00dbf46
Le projet OpenStack vise à créer une plate-forme open source Cloud computing, pour les Clouds publics et privés visant une évolutivité sans complexité. OpenStack est composé d'un certain nombre de composants libres qui forment ensemble une solution Cloud.
La NASA et Rackspace ont été les initiateurs de ce projet. Des grands noms du monde informatique se sont joints au projet tel que IBM, Dell, Canonical, Cisco, … etc. La mutualisation des efforts de développement ont fait du projet OpenStack l'un des projet les plus émergent, avec une release chaque 6 mois.
SOLID : les principes à l’origine du succès de Symfony et de vos applicationsVladyslav Riabchenko
SOLID est un acronyme représentant cinq principes de bases de la programmation orientée objet permettant le développement de logiciels fiables, évolutifs et robustes. Le framework Symfony est un excellent support pour illustrer chacun de ces principes. Nous verrons ainsi que SOLID est à l’origine de sa flexibilité, sa fiabilité mais aussi de sa maintenabilité et son évolutivité. Nous verrons également comment appliquer ces principes pour améliorer son code métier et perfectionner l’architecture de son application.
(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.
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
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
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.
Recherche sur l'architecture d'un systéme complexe pour un site de freelance .
référence:
https://medium.com/@krishnaanaril/embedding-power-bi-in-angular-part-1-a1847de9a2e8
https://medium.com/@emccul13/socket-io-9bceb00dbf46
Le projet OpenStack vise à créer une plate-forme open source Cloud computing, pour les Clouds publics et privés visant une évolutivité sans complexité. OpenStack est composé d'un certain nombre de composants libres qui forment ensemble une solution Cloud.
La NASA et Rackspace ont été les initiateurs de ce projet. Des grands noms du monde informatique se sont joints au projet tel que IBM, Dell, Canonical, Cisco, … etc. La mutualisation des efforts de développement ont fait du projet OpenStack l'un des projet les plus émergent, avec une release chaque 6 mois.
SOLID : les principes à l’origine du succès de Symfony et de vos applicationsVladyslav Riabchenko
SOLID est un acronyme représentant cinq principes de bases de la programmation orientée objet permettant le développement de logiciels fiables, évolutifs et robustes. Le framework Symfony est un excellent support pour illustrer chacun de ces principes. Nous verrons ainsi que SOLID est à l’origine de sa flexibilité, sa fiabilité mais aussi de sa maintenabilité et son évolutivité. Nous verrons également comment appliquer ces principes pour améliorer son code métier et perfectionner l’architecture de son application.
3. oauth2
OAuth 2.0, qui signifie « Open Authorization » (autorisation ouverte), est une norme conçue pour permettre à un site
Web ou à une application d'accéder aux ressources hébergées par d'autres applications Web au nom d'un utilisateur.
Elle a remplacé OAuth 1.0 en 2012 et constitue désormais la norme industrielle de facto pour l'autorisation en ligne.
OAuth 2.0 fournit un accès consenti et limite les actions que l'application cliente peut réaliser sur les ressources au nom
de l'utilisateur, sans jamais partager les informations d'identification de l'utilisateur.
Bien que le Web soit la principale plateforme d'OAuth 2, la spécification décrit également comment gérer ce type
d'accès délégué à d'autres types de clients (applications basées sur un navigateur, applications Web côté serveur,
applications natives/mobiles, appareils connectés, etc.)
https://datatracker.ietf.org/doc/html/rfc6749
https://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2
https://guide-api-rest.marmicode.fr/securite-des-apis-rest/oauth-2/oauth-2-authorization-code-flow
https://www.ibm.com/docs/en/tfim/6.2.2.6?topic=overview-oauth-20-workflow
4. oauth2
Principes d'OAuth 2.0
OAuth 2.0 est un protocole d'autorisation et NON un protocole d'authentification.
En tant que tel, il est principalement conçu comme un moyen d'accorder l'accès à un ensemble de
ressources, par exemple, des API distantes ou des données utilisateur.
OAuth 2.0 utilise des jetons d'accès.
Un jeton d'accès est un élément de données qui représente l'autorisation d'accéder aux ressources au nom
de l'utilisateur final.
OAuth 2.0 ne définit pas de format spécifique pour les jetons d'accès.
Toutefois, dans certains contextes, le format JSON Web Token (JWT) est souvent utilisé.
Cela permet aux émetteurs de jetons d'inclure des données dans le jeton lui-même.
En outre, pour des motifs de sécurité, les jetons d'accès peuvent avoir une date d'expiration.
5. oauth2
Rôles OAuth2.0
Le concept de rôles fait partie de la spécification de base du cadre d'autorisation OAuth2.0.
Ils définissent les composants essentiels d'un système OAuth 2.0, qui sont les suivants :
● Propriétaire des ressources : l'utilisateur ou le système qui possède les ressources protégées et peut en accorder
l'accès ;
● Client : le client est le système qui a besoin d'accéder aux ressources protégées. Pour accéder aux ressources,
le client doit détenir le jeton d'accès approprié ;
● Serveur d'autorisation : ce serveur reçoit les demandes de jetons d'accès de la part du client et les délivre après
authentification et consentement du propriétaire des ressources. Le serveur d'autorisation expose deux points de
terminaison : le point de terminaison d'autorisation, qui gère l'authentification et le consentement interactifs de
l'utilisateur, et le point de terminaison de jeton, qui fait partie d’une interaction de machine à machine ;
● Serveur de ressources : un serveur qui protège les ressources de l'utilisateur et reçoit les demandes d'accès du
client. Il accepte et valide un jeton d'accès du client et lui renvoie les ressources appropriées.
18. A server side def tokens():
"""
Get the lis of the valid tokens
:param None
:return: a list of the valid token used to access to the
api
"""
try:
return self.__read_parameter('tokens')
except:
return None # no default values
def is_token_valid(givenToken:str=None) -> bool:
"""
Check if the token provided is in the list
:param givenToken: token to check
:return: True is the givenToken is one of the valid one,
else False
"""
for token in self.tokens():
if token == givenToken:
return True
return False
#!/usr/bin/env python3.8
# -*- coding:utf8 -*-
from flask import Flask, request, Response
app = Flask(__name__)
@app.route('/api/my_route, methods=['POST'])
def my_route_fctl():
if request.method == 'POST':
data = request.get_json()
client_ip = request.remote_addr
retdata = []
token =
request.headers['Authorization'].split(" ", 1)[1]
#logger.debug(" - Token='%s'" % (token))
if config.is_token_valid(givenToken=token):
(…)
19. Client using curl
$ curl -X POST http://localhost:3526/api/status
-H "Authorization: Bearer eyJpZCI6NDAsIm5hbWUiOiJzdHJlYW1wcm9iZSJ9.BT6_m8L-
MaeVcmEKnTsu55wFev4"
-d '{ }'
-H 'Content-Type: application/json'
21. 1. need an authenticate server (https://ip/auth or https://ip/oauth2) with a login +
password for the API in order to get :
a. an access TOKEN
b. refresh TOKEN
c. timeout
1. then all http(s) request will be done to the API (https://ip/api) with the access token
and must get a 2XX http return code
1. If a 401 return code is obtain a new request must be to authentication server done
using the refresh token in order to get access token + refresh token and timeout in
order to get a new cycle.
1. To be define :
a. which user can use the auth ?
STREAMPROBE NEEDS
22. database
auth api
check
auth
save
client
HTTP(S) / POST request
login+password
get password from login
rc = 200
access_token
refresh token
timeout in s if granted
if denied
rc = 401
HTTP(S) / POST request
barrer acces_token
save access_token, refresh_token and
timeout
check
tokens
check valid token_access
if granted
rc = 200 + response of the request
rc = 401 (timeout on token_access)
HTTP(S) / POST request
barrer refresh_token
if denied
if denied
if granted
save access_token, refresh_token and timeout
rc = 200, access_token, refresh token, timeout in s
redirect to the api
rc = 401, bad refresh
token
redirect rc = 200, access/refresh token, timeout