Authentification et autorisation

Difficulté Facile
Note
Thématiques
PHP, Web
Mis à jour le vendredi 3 mai 2013

La sécurité sous Symfony2 est très poussée, vous pouvez la contrôler très finement, mais surtout très facilement. Pour atteindre ce but, Symfony2 a bien séparé deux mécanismes différents : l'authentification et l'autorisation. Prenez le temps de bien comprendre ces deux notions pour bien attaquer la suite du cours. :)

Les notions d'authentification et d'autorisation

L'authentification

L'authentification est le processus qui va définir qui vous êtes, en tant que visiteur. L'enjeu est vraiment très simple : soit vous ne vous êtes pas identifié sur le site et vous êtes un anonyme, soit vous vous êtes identifié (via le formulaire d'identification ou via un cookie « Se souvenir de moi ») et vous êtes un membre du site. C'est ce que la procédure d'authentification va déterminer. Ce qui gère l'authentification dans Symfony2 s'appelle un firewall.

Ainsi vous pourrez sécuriser des parties de votre site internet juste en forçant le visiteur à être un membre authentifié. Si le visiteur l'est, le firewall va le laisser passer, sinon il le redirigera sur la page d'identification. Cela se fera donc dans les paramètres du firewall, nous les verrons plus en détail par la suite.

L'autorisation

L'autorisation est le processus qui va déterminer si vous avez le droit d'accéder à la ressource (la page) demandée. Il agit donc après le firewall. Ce qui gère l'autorisation dans Symfony2 s'appelle l'access control.

Par exemple, un membre identifié lambda aura accès à la liste de sujets d'un forum, mais ne peut pas supprimer de sujet. Seuls les membres disposant des droits d'administrateur le peuvent, ce que l'access control va vérifier.

Exemples

Pour bien comprendre la différence entre l'authentification et l'autorisation, je reprends ici les exemples de la documentation officielle, qui sont, je trouve, très intéressants et illustratifs. Dans ces exemples, vous distinguerez bien les différents acteurs de la sécurité.

Je suis anonyme, et je veux accéder à la page /foo qui ne requiert pas de droits

Dans cet exemple, un visiteur anonyme souhaite accéder à la page /foo. Cette page ne requiert pas de droits particuliers, donc tous ceux qui ont réussi à passer le firewall peuvent y avoir accès. La figure suivante montre le processus.

Schéma du processus de sécurité
Schéma du processus de sécurité

Sur ce schéma, vous distinguez bien le firewall d'un côté et l'access control (contrôle d'accès) de l'autre. C'est très clair, mais reprenons-le ensemble pour bien comprendre :

  1. Le visiteur n'est pas identifié, il est anonyme, et tente d'accéder à la page /foo.

  2. Le firewall est configuré de telle manière qu'il n'est pas nécessaire d'être identifié pour accéder à la page /foo. Il laisse donc passer notre visiteur anonyme.

  3. Le contrôle d'accès regarde si la page /foo requiert des droits d'accès : il n'y en a pas. Il laisse donc passer notre visiteur, qui n'a aucun droit particulier.

  4. Le visiteur a donc accès à la page /foo.

Je suis anonyme, et je veux accéder à la page /admin/foo qui requiert certains droits

Dans cet exemple, c'est le même visiteur anonyme qui veut accéder à la page /admin/foo. Mais cette fois, la page /admin/foo requiert le rôle ROLE_ADMIN ; c'est un droit particulier, nous le verrons plus loin. Notre visiteur va se faire refuser l'accès à la page, la figure suivante montre comment.

Schéma du processus de sécurité
Schéma du processus de sécurité

Voici le processus pas à pas :

  1. Le visiteur n'est pas identifié, il est toujours anonyme, et tente d'accéder à la page /admin/foo.

  2. Le firewall est configuré de manière qu'il ne soit pas nécessaire d'être identifié pour accéder à la page /admin/foo. Il laisse donc passer notre visiteur.

  3. Le contrôle d'accès regarde si la page /admin/foo requiert des droits d'accès : oui, il faut le rôle ROLE_ADMIN. Le visiteur n'a pas ce rôle, donc le contrôle d'accès lui interdit l'accès à la page /admin/foo.

  4. Le visiteur n'a donc pas accès à la page /admin/foo, et se fait rediriger sur la page d'identification.

Je suis identifié, et je veux accéder à la page /admin/foo qui requiert certains droits

Cet exemple est le même que précédemment, sauf que cette fois notre visiteur est identifié, il s'appelle Ryan. Il n'est donc plus anonyme.

Schéma du processus de sécurité
Schéma du processus de sécurité
  1. Ryan s'identifie et il tente d'accéder à la page /admin/foo. D'abord, le firewall confirme l'authentification de Ryan (c'est son rôle !). Visiblement c'est bon, il laisse donc passer Ryan.

  2. Le contrôle d'accès regarde si la page /admin/foo requiert des droits d'accès : oui, il faut le rôle ROLE_ADMIN, que Ryan n'a pas. Il interdit donc l'accès à la page /admin/foo à Ryan.

  3. Ryan n'a pas accès à la page /admin/foo non pas parce qu'il ne s'est pas identifié, mais parce que son compte utilisateur n'a pas les droits suffisants. Le contrôle d'accès lui affiche donc une page d'erreur lui disant qu'il n'a pas les droits suffisants.

Je suis identifié, et je veux accéder à la page /admin/foo qui requiert des droits que j'ai

Ici, nous sommes maintenant identifiés en tant qu'administrateur, on a donc le rôle ROLE_ADMIN ! Du coup, nous pouvons accéder à la page /admin/foo, comme le montre la figure suivante.

Schéma du processus de sécurité
Schéma du processus de sécurité
  1. L'utilisateur admin s'identifie, et il tente d'accéder à la page /admin/foo. D'abord, le firewall confirme l'authentification d'admin. Ici aussi, c'est bon, il laisse donc passer admin.

  2. Le contrôle d'accès regarde si la page /admin/foo requiert des droits d'accès : oui, il faut le rôle ROLE_ADMIN, qu'admin a bien. Il laisse donc passer l'utilisateur.

  3. L'utilisateur admin a alors accès à la page /admin/foo, car il est identifié et il dispose des droits nécessaires.

Processus général

Lorsqu'un utilisateur tente d'accéder à une ressource protégée, le processus est finalement toujours le même, le voici :

  1. Un utilisateur veut accéder à une ressource protégée ;

  2. Le firewall redirige l'utilisateur au formulaire de connexion ;

  3. L'utilisateur soumet ses informations d'identification (par exemple login et mot de passe) ;

  4. Le firewall authentifie l'utilisateur ;

  5. L'utilisateur authentifié renvoie la requête initiale ;

  6. Le contrôle d'accès vérifie les droits de l'utilisateur, et autorise ou non l'accès à la ressource protégée.

Ces étapes sont simples, mais très flexibles. En effet, derrière le mot « authentification » se cache en pratique bien des méthodes : un formulaire de connexion classique, mais également l'authentification via Facebook, Google, etc., ou via les certificats X.509, etc. Bref, le processus reste toujours le même, mais les méthodes pour authentifier vos internautes sont nombreuses, et répondent à tous vos besoins. Et, surtout, elles n'ont pas d'impact sur le reste de votre code : qu'un utilisateur soit authentifié via Facebook ou un formulaire classique ne change rien à vos contrôleurs !

L'auteur