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)

2. Vous avez dit protocoles Web
d’authentification et
d’autorisation! De quoi parlezvous ?
Philippe Beraud
Jean-Yves Grasset
Direction Technique | Microsoft France
philippe.beraud@microsoft.com, @philberd
jyvesg@microsoft.com,
Sécurité

3. Donnez votre avis !
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 !
#mstechdays
Sécurité

4. Anatomie d’une application moderne

5. AUTHENTIFICATION BASIQUE HTTP
Pour commencer par le début…
#mstechdays
Sécurité

6. Vue d’ensemble de l’authentification
basique
• Protocole d’authentification défini dans le RFC 2617
• Fondé sur un Challenge / Réponse
• Utilise le protocole HTTP pour l’échange des messages
#mstechdays
Sécurité

7. Authentification basique
Le navigateur envoie une
requête
Entête WWW-Authenticate
Renvoyée avec un 401
Listes sur les méthodes d'authentification prises
en charge
Entête Authorization
Méthode d’authentification: Basic
Informations d’identification: encodes en Base64
#mstechdays
Sécurité

8. Echanges pour l’authentification
WWW-Authenticate: Basic
Authorization: Basic <Cred>
Authorization: Basic <Cred>
#mstechdays
Sécurité

9. OASIS SAML 2.0
#mstechdays
Sécurité

10. SAML 2.0 - Assertions
Paquet d’information sur une
identité
Synonyme de "jeton (de
sécurité)"
Fondé sur XML
Se compose de déclarations
:
Déclarations d’authentification
Déclarations d’attribut
Déclarations de décision d’autorisation
#mstechdays
Sécurité

11. SAML 2.0 - Protocoles
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
#mstechdays
Sécurité
Protocoles SAML 2.0
Authentication Request
Artifact Resolution
Single Logout
Assertion Query and Request
Name Identifier Management
Name Identifier Mapping

12. SAML 2.0 - Liaisons
Associent un message de
protocole avec un protocole
de transport
Exemples
La liaison POST HTTP spécifie comment un
message de protocole SAML est envoyé par les
méthode POST HTTP
La liaison SOAP SAML spécifie comment un
message de protocole SAML est envoyé avec
SOAP 1.1
#mstechdays
Sécurité
Liaisons SAML 2.0
HTTP Redirect
HTTP POST
HTTP Artifact
SAML SOAP
Reverse SOAP
SAML URI

13. SAML 2.0 - Profils
Décrit comment les
assertions, les protocoles et
les liaisons se combinent
pour former un scénario
Exemple : Profil Web SSO
Authentication Request Protocol
Liaison Redirection HTTP au niveau fournisseur
d’identité (IdP)
Liaison POST HTTP au niveau fournisseur de
service (SP)
#mstechdays
Sécurité
Profils SAML 2.0
Profils SSO
•
•
•
•
•
Web Browser SSO Profile
Enhanced Client or Proxy (ECP) Profile
Identity Provider Discovery Profile
Single Logout Profile
Name Identifier Management Profile
Artifact Resolution Profile
Assertion Query/Request Profile
Name Identifier Mapping Profile
SAML Attribute Profiles
•
•
•
•
•
Basic Attribute Profile
X.500/LDAP Attribute Profile
UUID Attribute Profile
DCE PAC Attribute Profile
XACML Attribute Profile

14. Profil SAML Web SSO
Une 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
#mstechdays
Sécurité

15. OASIS WS-FEDERATION
#mstechdays
Sécurité

16. WS-Federation – Profil de demandeur
passif
Relation avec SAML-P
Similaire au profil SAML Web SSO mais
non compatible
•
•
•
Messages de requête et de réponse différents
Pas de cas d’utilisation IdP-initiated
Pas de profil Assertion Query
#mstechdays
Sécurité

17. IETF OAUTH 2.0
#mstechdays
Sécurité

18. L’objectif d’OAuth 2.0
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 passe
Vous voulez contrôler ce que l'application peut faire
Vous souhaitez révoquer les autorisations d’accès aux données d'une application plus tard
Vous souhaitez modifier votre mot de passe sans avoir à le mettre à jour dans toutes les applications
#mstechdays
Sécurité

19. Les différents rôles
Le serveur de ressources
Le client
Héberge la ressource
Typiquement un fournisseur d'API
L’application invoquant des API pour
effectuer des actions sur la ressource
Le propriétaire de la
ressource
Le serveur d’autorisation
Possède la ressource
Typiquement un utilisateur de l’application
#mstechdays
Sécurité
Emet le jeton d'accès utilisé par le client pour
accéder à la ressource
Authentifie le propriétaire de la ressource
Obtient du propriétaire de la ressource un
consentement d’accès

20. Les 4 flux officiels
Flux Code d’autorisation
Applications Web côté Serveur (par ex. Amazon accédant à Facebook en votre nom)
Flux implicite
Utilisé pour des applications Web côté client s’exécutant dans le navigateur (JavaScript)
Flux Mot de passe du propriétaire de la ressource
Clients (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 client
Les clients qui peuvent utiliser des ressources indépendamment de l'autorisation du
propriétaire de la ressource
#mstechdays
Sécurité

21. Flux Code d’autorisation
Scénario
Le client OAuth 2.0 est une application serveur Web
Un accès à long terme est nécessaire pour la ressource
Le jeton d'accès ne doit pas être divulgué au navigateur
Exemple
Jacques veut partager un achat sur ​Amazon sur son journal Facebook
Rôle OAuth 2.0 :
•
•
•
•
Propriétaire de la ressource : Jacques
Client : Amazon
Serveur de ressources : Facebook
Ressource : journal Facebook de Jacques
#mstechdays
Sécurité

22. Résumé du flux Code d’autorisation
1.
2.
3.
4.
5.
Le client redirige le propriétaire
de la ressource vers le serveur
d'autorisation
Le propriétaire de la ressource
s’authentifie et donne son
consentement
Le serveur d’autorisation redirige
le propriétaire de la ressource
vers le client avec le code
d’autorisation
Le client demande un jeton
d'accès au serveur d'autorisation
Le serveur d’autorisation renvoie
un jeton d’accès au Client
#mstechdays
Sécurité

23. Flux implicite
Scénario
Le client OAuth 2.0 est un composant client du navigateur (c.à.d. JavaScript ou Flash)
Le navigateur est (fortement) digne de confiance
L’accès à la ressource n'est que temporaire…
Exemple
Jacques utilise une application Web utilisant JavaScript dans le navigateur, et qui souhaite accéder à
ses photos sur Facebook
Rô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
#mstechdays
Sécurité

24. Résumé du flux implicite
1.
2.
3.
4.
Le client redirige le propriétaire
de la ressource vers le serveur
d'autorisation
Le propriétaire de la ressource
s’authentifie et donne son
consentement
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
Le composant serveur sur le
client renvoie un script qui
permet d’extraire le jeton
d’accès à partir du fragment
URL
#mstechdays
Sécurité

25. Flux Mot de passe du propriétaire de la
ressource
Scénario
L’application client est digne d’une grande confiance
Exemple
Jacques utilise l’application officielle Facebook pour son smartphone
Rôles OAuth 2.0 :
•
•
•
•
Propriétaire de la ressource : Jacques
Client : Application officielle Facebook
Serveur de ressources : Facebook
Ressource : Contenu Facebook de Jacques
#mstechdays
Sécurité

26. Résumé du flux Mot de passe du propriétaire de
la ressource
1.
2.
3.
Le propriétaire de la ressource donne
ses informations d’identification au
Client
Le client utilise les informations
d’identification pour demander un
jeton d’accès au serveur d’autorisation
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
#mstechdays
Sécurité

27. Flux Informations d’identification du client
Scénario
Le client OAuth 2.0 nécessite des données spécifiques non-utilisateur, au nom du client plutôt qu’à celui
l'utilisateur
Le client OAuth 2.0 peut stocker en toute sécurité une clé utilisée pour l'authentification du client
Exemple
Jacques utilise une application Web d'entreprise qui lit son appartenance à un groupe depuis Windows
Azure Active Directory
Rô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
#mstechdays
Sécurité

28. Résumé du flux Informations d’identification du
client
1.
2.
Le client s’authentifie auprès du
serveur d’autorisation et demande
un jeton d’accès à partir du point de
terminaison jeton
Le serveur d’autorisation vérifie les
information d’identification du
client, et si celles-ci sont
valides, émet un jeton d’accès
#mstechdays
Sécurité

29. IETF OPENID CONNECT
#mstechdays
Sécurité

30. OpenID Connect
Standard encore à l’état de projet
OAuth 2.0 n'est pas destiné à l'authentification
Opère hors d'une hypothèse; la personne donnant l’accès pourrait ne pas être l'utilisateur
Aucun jeton d'identité est fourni
Définit une couche d'identité sur le dessus d’OAuth 2.0
Utilise deux flux OAuth 2.0 :
•
•
Flux Code d’Autorisation
Flux implicite
Ajoute un jeton d’identité dans l’échange OAuth 2.0
Ajoute la possibilité de demander des revendications à l’aide d’un jeton d’accès OAuth 2.0
#mstechdays
Sécurité

31. Authentification avec le flux Code d’autorisation
Un client s’enregistre avec le fournisseur OpenID
Connect (OP)
L'utilisateur accède à l'application Web et initie une
connexion
L’application Web redirige l’utilisateur vers l’OP
L’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’autorisation
L’application Web envoie le code d’autorisation à
l’OP
L’OP crée le jeton d’identité [I] et le jeton d’accès et
les retourne à l’application Web
L’application Web vérifie le jeton d’identité
#mstechdays
Sécurité


32. "Qui parle quoi ?" (nov. 2013)
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émentation
OAuth 2.0, flux Code d’autorisation,
client confidentiel
Non disponible
Préversion*
Non disponible
Disponible
Non disponible
En cours
d’implémentation
Web vers Web
API
OAuth 2.0, flux Informations
Serveur vers Web d’authentification du client
API
OAuth 2.0 "Act As"
#mstechdays
Sécurité

33. Livres blancs et guides Etape-par-Etape
Leverage Windows Azure AD for
modern business applications

34. Pour aller plus loin
activdirectory.windowsazure.com/develop
Documentation Microsoft TechNet
http://go.microsoft.com/fwlink/p/?linkid=290967
Documentation Microsoft MSDN
http://go.microsoft.com/fwlink/p/?linkid=290966
Blog d’équipe Microsoft Active Directory
http://blogs.msdn.com/b/active_directory_team_blog

35. Digital is
business