Réflexion sur la sécurisation d’une application web

de | septembre 20, 2019

A force de refaire encore et encore les mêmes systèmes pour gérer l’authentification et les droits d’accès dans des applications, je me suis aperçu que :

  • C’est chiant
  • C’est chronophage
  • Source d’erreurs
  • Inadaptable d’une application à une autre la plupart du temps
  • Cela manque de granularité

Défauts d’une implémentation par application

C’est chiant

Ce n’est pas du fonctionnel. Donc c’est une perte de temps de réaliser cela à chaque fois. En plus sur toutes les applications on y a le droit. En tant que développeur j’aime le challenge et les nouveautés. Je déteste refaire en boucle la même tâche fastidieuse.

C’est chronophage

Le sujet de la gestion des droits est tellement complexe psi vous voulez avoir quelque chose de fin et dynamique qu’on y passe très vite un temps conséquent.

Source d’erreur

Si vous vous plantez dans votre implémentation, votre application aura des failles de sécurité béante. La complexité de la chose fera que vous en aurez surement, ou vous manquerez de granularité pour garder les choses simples.

Inadaptable d’une application à une autre la plupart du temps

Découlant directement du manque de temps et de la complexité, vous serez certainement tenté de faire du spécifique pour répondre à des contraintes métier du genre « untel a le droit d’accéder à telle ressource si untel appartient à tel bureau et qu’il est le chef de projet contenant la dite ressource ». Bon courage pour implémenter cela avec un RBAC classique

Cela manque de granularité

On va en parler en détail plus tard mais si vous voulez avoir une granularité fine, par exemple « Le rôle consultant n’a pas le droit de voir les informations des utilisateurs de l’application. Mais Martine Consultant en relation de travail doit pouvoir avoir accès aux données de l’utilisateur Bob dans le cadre de sa mission sans pour autant voir l’adresse postal de BoB ». Encore une fois bonne chance avec un RBAC.

Caractéristique d’un bon système d’authentification et d’autorisation

  • Non intrusif
  • Granulaire
  • Dynamique
  • Performant
  • Agnostique

Non intrusif

Un système d’Authentification et d’Autorisation ( SAA) doit pouvoir s’apposer sur une application sans altérer le code métier. Le code métier ne doit pas contenir de code lié au système SAA

Granulaire

Le SAA doit permettre de prendre en compte les cas les plus généraux comme les plus spécifiques. Je distingue les cas suivants :

  • L’accès à une ressource
  • L’accès à un ensemble de ressource du même type
  • L’accès à un sous-ensemble de ressource du même type (cas d’un filtre)
  • L’accès à un sous-ensemble d’attribut d’une ressource.
  • L’accès à un ensemble de ressource de type différent
  • L’accès contextualisé ( la localisation, la plage horaire … )

Dynamique

Le SAA doit permettre de modifier l’ensemble des utilisateurs, des rôles, des ressources et des permissions gérés sans devoir ni recompiler ni redéployer l’application. L’héritage et la composition de rôle doivent être possibles. Les permissions doivent pouvoir être aussi bien positive que négative.

Performant

Le SAA ne doit pas altérer de manière significative ni le temps de réponse ni la capacité à monté en charge de l’application.

Agnostique

Le SAA doit être entièrement agnostique du langage utilisé dans l’application à sécuriser de manière à pouvoir être réutilisable.

Solution?

La solution à tous ces pré-requis, s’appelle OpenId Connect. Plusieurs acteurs se partagent le marché. Dans un prochain article, je vous présenterai cette Norme ainsi qu’une de ces implémentations au travers de Keycloak

00

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.