Este tutorial proporciona pasos completos para diseñar un esquema de base de datos de un sistema de control de acceso basado en roles (RBAC) para administrar los usuarios, los roles y los permisos. Se puede utilizar además para decidir el acceso a recursos específicos en función de permisos específicos. El uso de un sistema RBAC debe considerarse como una parte integral de cualquier aplicación que comparta los recursos entre múltiples usuarios. P.ej. los empleados de una organización pueden acceder o gestionar los productos en función de los permisos que se les asignen. Idealmente, los permisos se pueden asignar a través de roles.
El Diagrama de Relación de Entidades o el diseño de la base de datos visual se muestra a continuación.
higo 1
Notas :Las tablas de roles y permisos que se analizan en este tutorial se pueden agregar a las bases de datos de la aplicación que se analizan en los tutoriales Blog y Poll &Survey. Este tutorial asume que los permisos están codificados a nivel de código para verificar el acceso.
También puede visitar los populares tutoriales, que incluyen Cómo instalar MySQL 8 en Ubuntu, Cómo instalar MySQL 8 en Windows, Base de datos de blogs en MySql, Base de datos de sondeos y sondeos en MySql y Aprenda consultas SQL básicas en MySQL.
Base de datos RBAC
El primer paso es crear la base de datos RBAC. Se puede crear usando la consulta como se muestra a continuación.
CREATE SCHEMA `rbac` DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
He usado el conjunto de caracteres utf8mb4 para admitir una amplia gama de caracteres.
Tabla de usuarios
En esta sección, diseñaremos la Tabla de usuarios para almacenar información del usuario. A continuación se menciona la descripción de todas las columnas de la tabla de usuarios.
| Id | La identificación única para identificar al usuario. |
| Nombre | El nombre del usuario. |
| Segundo Nombre | El segundo nombre del usuario. |
| Apellido | El apellido del usuario. |
| Móvil | El número de móvil del usuario. Se puede utilizar con fines de inicio de sesión y registro. |
| Correo electrónico | El correo electrónico del usuario. Se puede utilizar con fines de inicio de sesión y registro. |
| Hash de contraseña | El hash de contraseña generado por el algoritmo apropiado. Debemos evitar almacenar contraseñas sin formato. |
| Registrado en | Esta columna se puede utilizar para calcular la vida del usuario con la aplicación. |
| Último inicio de sesión | Se puede utilizar para identificar el último inicio de sesión del usuario. |
| Introducción | La breve introducción del Usuario. |
| Perfil | Los detalles del usuario. |
La tabla de usuarios con las restricciones adecuadas se muestra a continuación.
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) );
Mesa de funciones
En esta sección, diseñaremos la tabla de roles para almacenar los roles del sistema. A continuación se menciona la descripción de todas las columnas de la tabla de funciones.
| Id | La identificación única para identificar el rol. |
| Título | El título del rol. |
| Babosa | El slug único para buscar el rol. |
| Descripción | La descripción para mencionar el rol. |
| Activo | La bandera para verificar si el rol está actualmente activo. |
| Creado en | Almacena la fecha y hora en que se crea el rol. |
| Actualizado en | Almacena la fecha y hora en que se actualiza el rol. |
| Contenido | Los detalles completos sobre el rol. |
La tabla de roles con las restricciones apropiadas se muestra a continuación.
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) );
Tabla de permisos
En esta sección, diseñaremos la Tabla de permisos para almacenar los permisos del sistema. A continuación se menciona la descripción de todas las columnas de la Tabla de permisos.
| Id | La identificación única para identificar el permiso. |
| Título | El título del permiso. |
| Babosa | El slug único para buscar el permiso. |
| Descripción | La descripción para mencionar el permiso. |
| Activo | La bandera para verificar si el permiso está actualmente activo. |
| Creado en | Almacena la fecha y hora en que se crea el permiso. |
| Actualizado en | Almacena la fecha y hora en que se actualiza el permiso. |
| Contenido | Los detalles completos sobre el permiso. |
La tabla de permisos con las restricciones apropiadas se muestra a continuación.
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) );
Tabla de permisos de roles
La tabla de permisos de roles se puede utilizar para almacenar las asignaciones de los permisos a los roles. A continuación se menciona la descripción de todas las columnas de la Tabla de permisos de roles.
| Id. de función | La identificación del rol para identificar el rol. |
| Id. de permiso | La identificación del permiso para identificar el permiso. |
| Creado en | Almacena la fecha y hora en que se crea el mapeo. |
| Actualizado en | Almacena la fecha y hora en que se actualiza el mapeo. |
La tabla de permisos de roles con las restricciones apropiadas se muestra a continuación.
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);
Rol de usuario
Podemos mantener el sistema simple asignando un solo rol al usuario. El rol asignado se puede usar para extraer los permisos asignados al rol. El acceso al recurso o permiso específico se puede comprobar comparando el permiso codificado de forma rígida con la lista de permisos asignados a la función asignada al usuario.
Se puede hacer usando la consulta como se muestra a continuación.
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;
Opciones avanzadas
Uno puede pensar en asignar múltiples roles al usuario utilizando la Tabla de roles de usuario. Las opciones más avanzadas incluyen el sistema de jerarquía para agrupar los permisos o roles. Estas opciones complican aún más la consulta para extraer la lista de permisos, por lo que necesitan optimización al tener un mecanismo de caché adecuado.
Resumen
En este tutorial, analizamos el diseño de la base de datos de un sistema RBAC para proteger solicitudes y recursos específicos al permitir el acceso solo si el usuario tiene el permiso adecuado.
Puede enviar sus comentarios para unirse a la discusión. También te puede interesar diseñar la base de datos de las aplicaciones Blog y Poll &Survey.
El esquema completo de la base de datos también está disponible en GitHub.
