Cet article fait partie d'une série d'articles :

• Introduction (cet article)
• Mettre en place un serveur OpenID Connect avec Keycloak
• Symfony et Keycloak

Introduction

Après pas mal de recherches sur le sujet et quelques mises en place avec d'autres framework (Node au hasard), on va aujourd'hui s'attaquer à un sujet à la fois simple fonctionnellement mais plus complexe techniquement : "Comment mettre en place un SSO (Single-Sign-On) dans mes applications Symfony ?".

On ne va pas se mentir. Rentrer 20 mots de passe différents pour chaque application de son SI, c'est acceptable pour des applications "publiques" sur Internet, mais pas en entreprise où on a envie de fluidité, surtout sur un réseau "fermé".

Certains l'ont bien compris, comme Google, avec une authentification unique quelle que soit l'application utilisée dans l'univers Google.

Pourquoi OpenID Connect et pas une autre méthode ?
Parce que c'est celle utilisée par de nombreux acteurs (Github, Twitter, Google, ....), et qu'en quelques années c'est devenu le standard de fait.

Elle offre beaucoup d'avantages, dont celui d'être exclusivement basée sur le protocole HTTP.

Quelles briques techniques ?

On a seulement 2 briques ici:

• une brique Symfony, notre application à sécuriser ("fournisseur de service" pour OpenID)
• une brique "serveur SSO". On va voir que cette brique est en fait 3 briques fonctionnelles, résumées souvent à une seule brique technique.

Je vous recommande l'excellent guide de l'ANSSI. LISEZ-LE !

Mais voici en gros comment ça marche ;)

Comme expliqué précédemment, nos 2 briques vont discuter ensemble pour authentifier un utilisateur.

Mais en fait la brique "d'authentification" a 3 rôles :

• fournisseur d'identité : qui est l'utilisateur ? ses informations ? Nom, prénom, username, etc.....
• Authentification: Demander à l'utilisateur de s'authentifier par un moyen X (login/mot de passe dans une base de données, un LDAP/AD, mais aussi via son token Kerberos, etc....)
• Autoriser: OK l'utilisateur existe, il s'est authentifié, mais a-t-il le droit d'accéder à l'application ?

Nous allons utiliser Keycloak, de Redhat (open source).
C'est là-aussi un des standards du marché. Il réunit bien les 3 rôles de la brique SSO, et peut marcher dans différentes configurations.

S'agissant d'une brique centrale d'un système d'information, il ne faut pas faire n'importe quoi. Certes la redonder, mais aussi la mettre dans 2 datacenter différents. Keycloak vous offre ainsi plusieurs "Operating Mode" (cf la doc).

Pas de panique, nous on va faire simple :

• une VM qui hébergera Keycloak (avec un Apache devant, on y reviendra), en mode "standalone"
• une machine de développement pour l'application Symfony.

Et c'est tout !

Heu, rappelle-moi déjà comment ça marche OpenID Connect ?

C'est simple ! (ou pas)

1. L'utilisateur ouvre son navigateur et appelle l'URL de l'application.
2. L'application regarde la requête et constate qu'elle n'est pas une requête authentifiée.
3. Pas de panique, l'application renvoie une requête de redirection (HTTP 302) vers le serveur SSO (avec quelques informations en plus, dont l'URL de redirection, un "client_id", etc...)
4. le navigateur de l'utilisateur, voyant la réponse de l'application (redirection), ouvre l'URL renvoyée, celle du serveur SSO.
5. Le serveur SSO (Keycloak) présente alors une fenêtre de login à l'utilisateur (cas le plus commun)
6. Après la saisie du login/mot de passe par l'utilisateur, le SSO va vérifier si l'utilisateur existe, si les login/mdp sont bons, si l'utilisateur a les droits d'appeler l'application, et enfin renvoyer à son tour une requête de redirection (HTTP 302), agrémentée évidemment des informations de l'utilisateur demandées (le "scope").
7. Après cette 2ème requête de redirection, le navigateur appelle une 2ème fois l'application, mais cette fois-ci avec un "token" lui permettant de s'authentifer.

Et voilà, c'est aussi "simple" que cela :-D

L'aventure vous tente, alors rendez-vous dans les prochains épisodes ! On va parler technique !