Application des RBAC aux infrastructures micro-services
Avec les différentes évolutions d’internet ces dernières années, l’apparition du cloud et des applications mobiles afin de rendre notre vie privée et professionnelle plus simple, la question de simplifié et unifié tous nos services est venue se poser. Et c’est avec ces nouveautés que différentes technologies, protocoles et paradigmes sont apparus.
L’approche micro-services
L’idée de l’approche micro-service est de segmenter chaque partie du logiciel en différents services indépendant les uns des autres grâce à leur périmètre fonctionnel.
Chaque service est : petit, conçu pour remplir une seule fonction, résilient, minimaliste, mais complet sur la tâche qu’il doit accomplir. Cela permet de rendre chaque service indépendant des autres, simple à remplacer, simple à mettre à jour et cela facilite donc le déploiement.
OAuth, un protocole de délégation d’autorisation
Il permet ainsi à un logiciel, processus ou application (le consommateur) d’utiliser l’API sécurisée d’un autre logiciel (le fournisseur) pour le compte d’un utilisateur. Il repose sur un mécanisme d’échange de jeton. Il a l’avantage de ne pas faire confiance à la machine cliente qui n’est pas sécurisé et de pouvoir signer le token afin de pouvoir vérifier sa provenance par la suite.
RBAC (contrôle d’accès basé sur les rôles) : une méthode pour donnée un accès à des ressources en fonction du rôle d’un utilisateur
Le RBAC (contrôle d’accès basé sur les rôles) est une méthode pour donnée un accès à des ressources en fonction du rôle d’un utilisateur. Les utilisateurs se voient attribué un rôle par le serveur d’autorité qui leur permet ou non d’accéder à une ressource. Le RBAC permet ainsi d’associer le même rôle à plusieurs utilisateurs qui doivent pouvoir accéder à la même ressource. C’est donc un système idéal pour les entreprises avec un turn-over conséquent qui pourront attribuer simplement un rôle à l’utilisateur entrant sans modifier les contrôles d’accès.
Explications par l’exemple
On va alors essayer d’appliquer ces 3 concepts à un exemple réel : un live tchat. On va donc découper notre application en 5 parties :
- Un service d’authentification et de gestion utilisateurs (iam)
- Un service de messagerie temps réel (msg)
- Un service pour la gestion des images (img)
- Une base de données pour sauvegarder les utilisateurs, les rôles, messages et images. (bdd)
Nous aurons 3 utilisateurs :
- Un utilisateur « administrateur » qui peut tout faire
- Un utilisateur « rédacteur » qui ne peut qu’envoyer des messages texte
- Un utilisateur « lecteur » qui ne peut que lire les messages.
La question que l’on peut se poser est : quels sont les échanges entre le client et le serveur ?
On va d’abord voir ce qu’il se passe lorsqu’un utilisateur « administrateur » souhaite envoyer un message :
Voici une représentation des échanges effectués entre l’utilisateur et le service qui le concerne qui lui-même va communiquer avec le composant iam afin de déterminer le rôle de l’utilisateur grâce au token. Cependant, cela reste le service message qui, en fonction du rôle utilisateur que iam lui valide, décide si l’utilisateur à le droit ou non d’effectuer l’action demandée.
3 autres exemples d’échanges :
Dans ces exemples qu’il se passe toujours la même chose, peu importe le service appelé, à la différence que si le rôle ne convient pas au service, celui-ci rejette l’appelle sans même contacter la base de donnée.
Mais du coup que contient ce fameux token ? C’est assez simple, un json web token est une chaine de caractère en trois parties séparée par des points. Chaque partie est encodée en base 64 et une fois décodé, on peut y retrouver :
- La partie 1 qui contient l’en-tête,
- La partie 2 qui contient le payload,
- La partie 3 qui contient la signature
L’en-tête va nous permettre de connaitre l’algorithme de signature pour la troisième partie et le type de token qui est JWT.
Le payload lui contient les données sur l’utilisateur qui l’utilise comme sont nom, prénom, email, identifiant, rôle, la date de réalisation du token, la date de l’expiration du token…
Cette partie peut contenir n’importe quel champ utile sans limites.
Enfin, la dernière partie est la signature des deux premières parties, elle permet de valider que le token est valide ou non.
Conclusion
Donc pour conclure, on peut ici voir que chaque service a le pouvoir de dire quel rôle il accepte pour une action donnée. Cela peut permettre de créer, mettre à jour et supprimer une infinité de services, mais aussi une infinité d’utilisateurs sans que l’un dépende de l’autre. C’est donc très intéressant dans le cas d’entreprise avec un gros turnover et/ou dans le cas d’utilisation d’un logiciel qui est voué a évolué très régulièrement.
Related Articles
Digital projects
Comment améliorer la productivité de votre entreprise grâce à la data visualisation
Les entreprises font une planification et une projection de leurs performances grâce à leurs équipes financières.
Elles partagent les objectifs, mais aussi leurs états d’avancement.
Read the article
Digital projects
How to improve your company's productivity with data visualization
Companies plan and project their performance with the help of their finance teams.
They share objectives and progress reports.
Read the article
Digital projects
Application of RBAC to microservices infrastructures
With the many evolutions of the internet over the past years, the appearance of the cloud, and mobile applications to make our private and professional life easier, the question of simplifying and unifying all our services came up. And it is with these novelties that different technologies, protocols, and paradigms have appeared.
Read the article