Sécurité

Vous avez dit protocoles Web d’authentification et

d’autorisation! De quoi parlez-vous ?Philippe Beraud

Jean-Yves GrassetDirection Technique | Microsoft France

philippe.beraud@microsoft.com, @philberdjyvesg@microsoft.com,

#mstechdaysSécurité

Depuis votre smartphone sur :http://notes.mstechdays.fr

De nombreux lots à gagner toute les heures !!!Claviers, souris et jeux Microsoft…

Merci de nous aider à améliorer les Techdays !

Donnez votre avis !

Anatomie d’une application moderne

Reposent sur une grande variété de langages / plates-formes /appareils

Navigateur

App native

App serveur

Application Web

API (service)

Web

Reposent sur une grande variété de langages / plates-formes

Basic, SAML 2.0, WS-Fed, OpenID Connect

(WS-Trust,) OAuth 2.0

OAuth 2.0

OAuth 2.0

Des protocoles standard fondés sur HTTP pour une portée maximale

Sécurité#mstechdays

AUTHENTIFICATION BASIQUE HTTP

Pour commencer par le début…

#mstechdaysSécurité

• Protocole d’authentification défini dans le RFC 2617

• Fondé sur un Challenge / Réponse• Utilise le protocole HTTP pour l’échange des

messages

Vue d’ensemble de l’authentification basique

#mstechdaysSécurité

Le navigateur envoie une requête

Entête WWW-AuthenticateRenvoyée avec un 401Listes sur les méthodes d'authentification prises en charge

Entête AuthorizationMéthode d’authentification: BasicInformations d’identification: encodes en Base64

Authentification basique

#mstechdaysSécurité

Echanges pour l’authentificationRequête HTTP usuelle

Réponse HTTP avec le code 401, comprenant l’entête

WWW-Authenticate: Basic

Même requête HTTP, comprenant l’entête

Authorization: Basic <Cred>Réponse HTTP usuelle

1ère requête

client

L’utilisateur entre ses informations

d’identification

Requête HTTP usuelle, comprenant l’entête Authorization: Basic

<Cred>Réponse HTTP usuelle

2nde requête

client

Client (Navigateur)

Serveur Web

Sécurité#mstechdays

OASIS SAML 2.0

#mstechdaysSécurité

Paquet d’information sur une identité

Synonyme de "jeton (de sécurité)"

Fondé sur XML

Se compose de déclarations :Déclarations d’authentificationDéclarations d’attributDéclarations de décision d’autorisation

SAML 2.0 - Assertions

#mstechdaysSécurité

Concerne le format des éléments de requête et de réponse

Sur la base de Requête / Réponse

Définis dans la spécification SAML Core

Protocoles SAML 2.0Authentication RequestArtifact ResolutionSingle LogoutAssertion Query and RequestName Identifier ManagementName Identifier Mapping

SAML 2.0 - Protocoles

#mstechdaysSécurité

Associent un message de protocole avec un protocole de transport

ExemplesLa liaison POST HTTP spécifie comment un message de protocole SAML est envoyé par les méthode POST HTTPLa liaison SOAP SAML spécifie comment un message de protocole SAML est envoyé avec SOAP 1.1

Liaisons SAML 2.0HTTP RedirectHTTP POSTHTTP ArtifactSAML SOAPReverse SOAPSAML URI

SAML 2.0 - Liaisons

#mstechdaysSécurité

Décrit comment les assertions, les protocoles et les liaisons se combinent pour former un scénario

Exemple : Profil Web SSOAuthentication Request ProtocolLiaison Redirection HTTP au niveau fournisseur d’identité (IdP)Liaison POST HTTP au niveau fournisseur de service (SP)

Profils SAML 2.0Profils SSO• Web Browser SSO Profile• Enhanced Client or Proxy (ECP) Profile• Identity Provider Discovery Profile• Single Logout Profile• Name Identifier Management Profile

Artifact Resolution ProfileAssertion Query/Request ProfileName Identifier Mapping ProfileSAML Attribute Profiles • Basic Attribute Profile• X.500/LDAP Attribute Profile• UUID Attribute Profile• DCE PAC Attribute Profile• XACML Attribute Profile

SAML 2.0 - Profils

#mstechdaysSécurité

Application Web

Emetteur SAML

Profil SAML Web SSO

Utilisateur

Confiance

Navigue

Est redirigé

TUne relation de confiance est établie entre l'application Web et l’émetteur SAML

L'utilisateur accède à l'application Web

L’application Web détecte que l'utilisateur n'est pas authentifié et le redirige vers l'émetteur SAML

L’utilisateur accède automatiquement à l'émetteur SAML

L’utilisateur s'authentifie auprès de l’émetteur SAML

L’émetteur SAML construit le jeton et le renvoie à l'utilisateur

L’utilisateur POSTe le jeton à l’application Web

S’authentifie

Sécurité#mstechdays

OASIS WS-FEDERATION

#mstechdaysSécurité

Relation avec SAML-PSimilaire au profil SAML Web SSO maisnon compatible• Messages de requête et de réponse différents• Pas de cas d’utilisation IdP-initiated• Pas de profil Assertion Query

WS-Federation – Profil de demandeur passif

Requête d’authentification SAML 2.0

Requête de jeton de sécurité WS-Federation

Sécurité#mstechdays

IETF OAUTH 2.0

#mstechdaysSécurité

Permettre aux utilisateurs de fournir à une application un accès limité à leurs données de manière fiable

Résoudre la problématique de stockage des informations d’identification :Vous n'avez pas assez confiance en l'application pour lui donner votre mot de passeVous voulez contrôler ce que l'application peut faireVous souhaitez révoquer les autorisations d’accès aux données d'une application plus tardVous souhaitez modifier votre mot de passe sans avoir à le mettre à jour dans toutes les applications

L’objectif d’OAuth 2.0

#mstechdaysSécurité

Le serveur de ressourcesHéberge la ressourceTypiquement un fournisseur d'API

Le propriétaire de la ressourcePossède la ressourceTypiquement un utilisateur de l’application

Le clientL’application invoquant des API pour effectuer des actions sur la ressource

Le serveur d’autorisationEmet le jeton d'accès utilisé par le client pour accéder à la ressourceAuthentifie le propriétaire de la ressourceObtient du propriétaire de la ressource un consentement d’accès

Les différents rôles

#mstechdaysSécurité

Flux Code d’autorisationApplications Web côté Serveur (par ex. Amazon accédant à Facebook en votre nom)

Flux impliciteUtilisé pour des applications Web côté client s’exécutant dans le navigateur (JavaScript)

Flux Mot de passe du propriétaire de la ressourceClients (dignes) de confiance, tels que les applications mobiles client obtenus à partir du serveur de ressources (par ex. le client officiel Facebook)

Flux Informations d’identification du clientLes clients qui peuvent utiliser des ressources indépendamment de l'autorisation du propriétaire de la ressource

Les 4 flux officiels

#mstechdaysSécurité

ScénarioLe client OAuth 2.0 est une application serveur WebUn accès à long terme est nécessaire pour la ressourceLe jeton d'accès ne doit pas être divulgué au navigateur

ExempleJacques veut partager un achat sur Amazon sur son journal FacebookRôle OAuth 2.0 :• Propriétaire de la ressource : Jacques• Client : Amazon• Serveur de ressources : Facebook• Ressource : journal Facebook de Jacques

Flux Code d’autorisation

#mstechdaysSécurité

Résumé du flux Code d’autorisation

Client

Serveur d’autorisation OAuth 2.0

Propriétaire de la ressource

1. Le client redirige le propriétaire de la ressource vers le serveur d'autorisation

2. Le propriétaire de la ressource s’authentifie et donne son consentement

3. Le serveur d’autorisation redirige le propriétaire de la ressource vers le client avec le code d’autorisation

4. Le client demande un jeton d'accès au serveur d'autorisation

5. Le serveur d’autorisation renvoie un jeton d’accès au Client

1 3

3

4

5

12

#mstechdaysSécurité

ScénarioLe client OAuth 2.0 est un composant client du navigateur (c.à.d. JavaScript ou Flash)Le navigateur est (fortement) digne de confianceL’accès à la ressource n'est que temporaire…

ExempleJacques utilise une application Web utilisant JavaScript dans le navigateur, et qui souhaite accéder à ses photos sur FacebookRôles OAuth 2.0 :• Propriétaire de la ressource : Jacques• Client : Application Web (Serveur et composants JavaScript)• Serveur de ressources : Facebook• Ressource : Photos Facebook de Jacques

Flux implicite

#mstechdaysSécurité

Client(Application Web)

Résumé du flux implicite

Propriétaire de la ressource

Composant JavaScript

(Navigateur)

Serveur d’autorisation OAuth 2.0

Composant Serveur Web

1. Le client redirige le propriétaire de la ressource vers le serveur d'autorisation

2. Le propriétaire de la ressource s’authentifie et donne son consentement

3. Le serveur d’autorisation redirige le propriétaire de la ressource vers le composant serveur du client avec le jeton d’accès dans un fragment URL

4. Le composant serveur sur le client renvoie un script qui permet d’extraire le jeton d’accès à partir du fragment URL

2

1 4

4

1

3

3

#mstechdaysSécurité

ScénarioL’application client est digne d’une grande confiance

ExempleJacques utilise l’application officielle Facebook pour son smartphoneRôles OAuth 2.0 :• Propriétaire de la ressource : Jacques• Client : Application officielle Facebook• Serveur de ressources : Facebook• Ressource : Contenu Facebook de Jacques

Flux Mot de passe du propriétaire de la ressource

#mstechdaysSécurité

Résumé du flux Mot de passe du propriétaire de la ressource

Serveur d’autorisation OAuth 2.0

Propriétaire de la ressource

1. Le propriétaire de la ressource donne ses informations d’identification au Client

2. Le client utilise les informations d’identification pour demander un jeton d’accès au serveur d’autorisation

3. Le serveur d’autorisation procède à une authentification, valide les informations d’identification du propriétaire de la ressource et retourne un jeton d’accès

Client

1

2

3

#mstechdaysSécurité

ScénarioLe client OAuth 2.0 nécessite des données spécifiques non-utilisateur, au nom du client plutôt qu’à celui l'utilisateurLe client OAuth 2.0 peut stocker en toute sécurité une clé utilisée pour l'authentification du client

ExempleJacques utilise une application Web d'entreprise qui lit son appartenance à un groupe depuis Windows Azure Active DirectoryRôles OAuth 2.0 :• Propriétaire de la ressource : John• Client : Application Web Métier• Serveur de ressources: Windows Azure AD• Ressource : Liste des groupes dont Jacques est membre

Flux Informations d’identification du client

#mstechdaysSécurité

Résumé du flux Informations d’identification du client

Serveur d’autorisation OAuth 2.0Client

(Application Web)

1. Le client s’authentifie auprès du serveur d’autorisation et demande un jeton d’accès à partir du point de terminaison jeton

2. Le serveur d’autorisation vérifie les information d’identification du client, et si celles-ci sont valides, émet un jeton d’accès

1

2

Sécurité#mstechdays

IETF OPENID CONNECT

#mstechdaysSécurité

Standard encore à l’état de projet

OAuth 2.0 n'est pas destiné à l'authentificationOpère hors d'une hypothèse; la personne donnant l’accès pourrait ne pas être l'utilisateurAucun jeton d'identité est fourni

Définit une couche d'identité sur le dessus d’OAuth 2.0Utilise deux flux OAuth 2.0 :• Flux Code d’Autorisation• Flux implicite

Ajoute un jeton d’identité dans l’échange OAuth 2.0Ajoute la possibilité de demander des revendications à l’aide d’un jeton d’accès OAuth 2.0

OpenID Connect

#mstechdaysSécurité

Utilisateur

Application Web

Fournisseur OpenID Connect

(OP)

Un client s’enregistre avec le fournisseur OpenID Connect (OP)L'utilisateur accède à l'application Web et initie une connexionL’application Web redirige l’utilisateur vers l’OPL’utilisateur s’authentifie auprès de l’OP et donne son consentement afin que l’application Web utilise son identitéL’OP construit un code d’autorisation [C] L’OP redirige l’utilisateur vers l’application Web avec le code d’autorisationL’application Web envoie le code d’autorisation à l’OPL’OP crée le jeton d’identité [I] et le jeton d’accès et les retourne à l’application WebL’application Web vérifie le jeton d’identité

Authentification avec le flux Code d’autorisation

Enregistrement du client

Navigation et connexion

Requête AuthN

Authentification et consentement

Réponse AuthN

I

T

C

#mstechdaysSécurité

"Qui parle quoi ?" (nov. 2013)Catégorie Protocole AD FS Windows Azure AD

App native OAuth 2.0, flux Code d’autorisation OAuth 2.0, client public

AD FS 3.0 Préversion*

App Web WS-Federation AD FS 2.0+ Disponible

SAML 2.0 AD FS 2.0+ Disponible

OpenID Connect Non disponible En cours d’implémentationWeb vers Web

API OAuth 2.0, flux Code d’autorisation, client confidentiel

Non disponible Préversion*

OAuth 2.0, flux Informations d’authentification du client

Non disponible DisponibleServeur vers Web API OAuth 2.0 "Act As" Non disponible En cours

d’implémentation* Seuls les mono-locataires sont disponibles dans la préversion du flux Code d’autorisation OAuth 2.0 ; multi-locataire à venir

Disponible sur le Centre de téléchargement Microsoft

Leverage Windows Azure AD for modern business applications

Livres blancs et guides Etape-par-Etape

Pour aller plus loinactivdirectory.windowsazure.com/develop

Documentation Microsoft TechNethttp://go.microsoft.com/fwlink/p/?linkid=290967

Documentation Microsoft MSDNhttp://go.microsoft.com/fwlink/p/?linkid=290966

Blog d’équipe Microsoft Active Directoryhttp://blogs.msdn.com/b/active_directory_team_blog

© 2014 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

Digital is business