Ce didacticiel fournit des étapes complètes pour concevoir un schéma de base de données d'un système de contrôle d'accès basé sur les rôles (RBAC) pour gérer les utilisateurs, les rôles et les autorisations. Il peut également être utilisé pour décider de l'accès à des ressources spécifiques en fonction d'autorisations spécifiques. L'utilisation d'un système RBAC doit être considérée comme faisant partie intégrante de toute application partageant les ressources entre plusieurs utilisateurs. Par exemple. les employés d'une organisation peuvent accéder ou gérer les produits en fonction des autorisations qui leur sont attribuées. Idéalement, les autorisations peuvent être attribuées via des rôles.
Le diagramme de relation d'entité ou la conception visuelle de la base de données est illustré ci-dessous.
Image 1
Remarques :Les tables de rôles et d'autorisations décrites dans ce didacticiel peuvent être ajoutées aux bases de données d'application décrites dans les didacticiels Blog et Sondage et enquête. Ce didacticiel suppose que les autorisations sont codées en dur au niveau du code pour vérifier l'accès.
Vous pouvez également consulter les didacticiels populaires, notamment Comment installer MySQL 8 sur Ubuntu, Comment installer MySQL 8 sur Windows, Blog Database dans MySql, Poll and Survey Database dans MySql et Learn Basic SQL Queries In MySQL.
Base de données RBAC
La toute première étape consiste à créer la base de données RBAC. Il peut être créé à l'aide de la requête comme indiqué ci-dessous.
CREATE SCHEMA `rbac` DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
J'ai utilisé le jeu de caractères utf8mb4 pour prendre en charge un large éventail de caractères.
Tableau des utilisateurs
Dans cette section, nous allons concevoir la table des utilisateurs pour stocker les informations de l'utilisateur. Vous trouverez ci-dessous la description de toutes les colonnes de la table des utilisateurs.
| Identifiant | L'identifiant unique pour identifier l'utilisateur. |
| Prénom | Le prénom de l'utilisateur. |
| Deuxième prénom | Le deuxième prénom de l'utilisateur. |
| Nom de famille | Le nom de famille de l'utilisateur. |
| Mobile | Le numéro de portable de l'utilisateur. Il peut être utilisé à des fins de connexion et d'enregistrement. |
| L'adresse e-mail de l'utilisateur. Il peut être utilisé à des fins de connexion et d'enregistrement. | |
| Hachage du mot de passe | Le hachage du mot de passe généré par l'algorithme approprié. Nous devons éviter de stocker des mots de passe simples. |
| Enregistré à | Cette colonne peut être utilisée pour calculer la durée de vie de l'utilisateur avec l'application. |
| Dernière connexion | Il peut être utilisé pour identifier la dernière connexion de l'utilisateur. |
| Introduction | La brève présentation de l'utilisateur. |
| Profil | Les détails de l'utilisateur. |
La table utilisateur avec les contraintes appropriées est illustrée ci-dessous.
CREATE TABLE `rbac`.`user` (
`id` BIGINT NOT NULL AUTO_INCREMENT,
`firstName` VARCHAR(50) NULL DEFAULT NULL,
`middleName` VARCHAR(50) NULL DEFAULT NULL,
`lastName` VARCHAR(50) NULL DEFAULT NULL,
`mobile` VARCHAR(15) NULL,
`email` VARCHAR(50) NULL,
`passwordHash` VARCHAR(32) NOT NULL,
`registeredAt` DATETIME NOT NULL,
`lastLogin` DATETIME NULL DEFAULT NULL,
`intro` TINYTEXT NULL DEFAULT NULL,
`profile` TEXT NULL DEFAULT NULL,
PRIMARY KEY (`id`),
UNIQUE INDEX `uq_mobile` (`mobile` ASC),
UNIQUE INDEX `uq_email` (`email` ASC) );
Tableau des rôles
Dans cette section, nous allons concevoir la table des rôles pour stocker les rôles système. Vous trouverez ci-dessous la description de toutes les colonnes de la table des rôles.
| Identifiant | L'identifiant unique pour identifier le rôle. |
| Titre | Le titre du rôle. |
| limace | Le slug unique pour rechercher le rôle. |
| Description | La description pour mentionner le rôle. |
| Actif | L'indicateur pour vérifier si le rôle est actuellement actif. |
| Créé à | Il stocke la date et l'heure auxquelles le rôle est créé. |
| Mis à jour à | Il stocke la date et l'heure auxquelles le rôle est mis à jour. |
| Contenu | Les détails complets sur le rôle. |
La table des rôles avec les contraintes appropriées est illustrée ci-dessous.
CREATE TABLE `rbac`.`role` (
`id` BIGINT NOT NULL AUTO_INCREMENT,
`title` VARCHAR(75) NOT NULL,
`slug` VARCHAR(100) NOT NULL,
`description` TINYTEXT NULL,
`active` TINYINT(1) NOT NULL DEFAULT 0,
`createdAt` DATETIME NOT NULL,
`updatedAt` DATETIME NULL DEFAULT NULL,
`content` TEXT NULL DEFAULT NULL,
PRIMARY KEY (`id`),
UNIQUE INDEX `uq_slug` (`slug` ASC) );
Tableau des autorisations
Dans cette section, nous allons concevoir le tableau des autorisations pour stocker les autorisations système. Vous trouverez ci-dessous la description de toutes les colonnes du tableau des autorisations.
| Identifiant | L'identifiant unique pour identifier l'autorisation. |
| Titre | Le titre de l'autorisation. |
| limace | Le slug unique pour rechercher l'autorisation. |
| Description | La description pour mentionner l'autorisation. |
| Actif | L'indicateur pour vérifier si l'autorisation est actuellement active. |
| Créé à | Il stocke la date et l'heure auxquelles l'autorisation est créée. |
| Mis à jour à | Il stocke la date et l'heure auxquelles l'autorisation est mise à jour. |
| Contenu | Les détails complets de l'autorisation. |
Le tableau des autorisations avec les contraintes appropriées est illustré ci-dessous.
CREATE TABLE `rbac`.`permission` (
`id` BIGINT NOT NULL AUTO_INCREMENT,
`title` VARCHAR(75) NOT NULL,
`slug` VARCHAR(100) NOT NULL,
`description` TINYTEXT NULL,
`active` TINYINT(1) NOT NULL DEFAULT 0,
`createdAt` DATETIME NOT NULL,
`updatedAt` DATETIME NULL DEFAULT NULL,
`content` TEXT NULL DEFAULT NULL,
PRIMARY KEY (`id`),
UNIQUE INDEX `uq_slug` (`slug` ASC) );
Tableau des autorisations de rôle
Le tableau des autorisations de rôle peut être utilisé pour stocker les mappages des autorisations aux rôles. Vous trouverez ci-dessous la description de toutes les colonnes du tableau des autorisations de rôle.
| ID de rôle | L'identifiant du rôle pour identifier le rôle. |
| Identifiant d'autorisation | L'identifiant d'autorisation pour identifier l'autorisation. |
| Créé à | Il stocke la date et l'heure auxquelles le mappage est créé. |
| Mis à jour à | Il stocke la date et l'heure auxquelles le mappage est mis à jour. |
Le tableau des autorisations de rôle avec les contraintes appropriées est illustré ci-dessous.
CREATE TABLE `rbac`.`role_permission` (
`roleId` BIGINT NOT NULL,
`permissionId` BIGINT NOT NULL,
`createdAt` DATETIME NOT NULL,
`updatedAt` DATETIME NULL,
PRIMARY KEY (`roleId`, `permissionId`),
INDEX `idx_rp_role` (`roleId` ASC),
INDEX `idx_rp_permission` (`permissionId` ASC),
CONSTRAINT `fk_rp_role`
FOREIGN KEY (`roleId`)
REFERENCES `rbac`.`role` (`id`)
ON DELETE NO ACTION
ON UPDATE NO ACTION,
CONSTRAINT `fk_rp_permission`
FOREIGN KEY (`permissionId`)
REFERENCES `rbac`.`permission` (`id`)
ON DELETE NO ACTION
ON UPDATE NO ACTION);
Rôle d'utilisateur
Nous pouvons garder le système simple en attribuant un rôle unique à l'utilisateur. Le rôle attribué peut être utilisé pour extraire les autorisations mappées au rôle. L'accès à la ressource ou à l'autorisation spécifique peut être vérifié en comparant l'autorisation codée en dur à la liste des autorisations mappées au rôle attribué à l'utilisateur.
Cela peut être fait en utilisant la requête comme indiqué ci-dessous.
ALTER TABLE `rbac`.`user`
ADD COLUMN `roleId` BIGINT NOT NULL AFTER `id`,
ADD INDEX `idx_user_role` (`roleId` ASC);
ALTER TABLE `rbac`.`user`
ADD CONSTRAINT `fk_user_role`
FOREIGN KEY (`roleId`)
REFERENCES `rbac`.`role` (`id`)
ON DELETE NO ACTION
ON UPDATE NO ACTION;
Options avancées
On peut penser à attribuer plusieurs rôles à l'utilisateur à l'aide de la table des rôles d'utilisateur. Les options les plus avancées incluent le système de hiérarchie pour regrouper les autorisations ou les rôles. Ces options compliquent davantage la requête pour extraire la liste des autorisations, et nécessitent donc une optimisation en disposant d'un mécanisme de cache approprié.
Résumé
Dans ce didacticiel, nous avons abordé la conception de la base de données d'un système RBAC pour sécuriser des demandes et des ressources spécifiques en n'autorisant l'accès que si l'utilisateur dispose de l'autorisation appropriée.
Vous pouvez soumettre vos commentaires pour participer à la discussion. Vous pourriez également être intéressé par la conception de la base de données des applications Blog et Poll &Survey.
Le schéma complet de la base de données est également disponible sur GitHub.
