Ръководство за проектиране на база данни за RBAC в MySQL

Този урок предоставя пълни стъпки за проектиране на схема на база данни на система за контрол на достъп, базиран на роли (RBAC) за управление на потребителите, ролите и разрешенията. Освен това може да се използва за решаване на достъп до конкретни ресурси въз основа на специфични разрешения. Използването на RBAC система трябва да се разглежда като неразделна част от всяко приложение, споделящо ресурсите между множество потребители. напр. служителите на организация могат да имат достъп или да управляват продуктите въз основа на предоставените им разрешения. В идеалния случай разрешенията могат да бъдат присвоени чрез роли.

Диаграмата на взаимоотношенията на обектите или визуалният дизайн на базата данни е показан по-долу.

Фигура 1

Бележки :Таблиците с роли и разрешения, обсъждани в този урок, могат да бъдат добавени към базите данни на приложенията, обсъждани в уроците за блогове и анкети и анкети. Този урок предполага, че разрешенията са твърдо кодирани на ниво код за проверка на достъпа.

Можете също така да посетите популярните уроци, включително Как да инсталирате MySQL 8 на Ubuntu, Как да инсталирате MySQL 8 на Windows, База данни за блогове в MySql, База данни за анкети и анкети в MySql и Научете основни SQL заявки в MySQL.

База данни RBAC

Първата стъпка е да създадете базата данни RBAC. Може да се създаде с помощта на заявката, както е показано по-долу.

CREATE SCHEMA `rbac` DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

Използвал съм набора от знаци utf8mb4 за поддръжка на широк спектър от знаци.

Таблица с потребители

В този раздел ще проектираме Таблица на потребителите за съхраняване на потребителска информация. По-долу е посочено описанието на всички колони на потребителската таблица.

Потребителската таблица със съответните ограничения е както е показано по-долу.

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) );

Таблица с роли

В този раздел ще проектираме Таблица с роли за съхраняване на системните роли. По-долу е споменато описанието на всички колони на таблицата с роли.

Таблицата на ролите със съответните ограничения е както е показано по-долу.

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) );

Таблица с разрешения

В този раздел ще проектираме Таблица с разрешения за съхраняване на системните разрешения. По-долу е посочено описанието на всички колони на таблицата с разрешения.

Таблицата с разрешения със съответните ограничения е както е показано по-долу.

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) );

Таблица с разрешения за роли

Таблица с разрешения за роли може да се използва за съхраняване на съпоставянията на разрешенията към ролите. По-долу е споменато описанието на всички колони на таблицата с разрешения за роли.

Таблицата с разрешения за роли със съответните ограничения е както е показано по-долу.

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);

Роля на потребителя

Можем да поддържаме системата проста, като присвоим една роля на потребителя. Присвоената роля може да се използва за изтегляне на разрешенията, съпоставени с ролята. Достъпът до конкретния ресурс или разрешение може да се провери чрез сравняване на твърдо кодираното разрешение със списъка с разрешения, съпоставени с ролята, присвоена на потребителя.

Може да се направи с помощта на заявката, както е показано по-долу.

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;

Разширени опции

Може да се мисли за присвояване на множество роли на потребителя с помощта на таблицата с роли на потребителя. По-разширените опции включват йерархичната система за групиране на разрешенията или ролите. Тези опции допълнително усложняват заявката за изтегляне на списъка с разрешения, поради което се нуждаят от оптимизация, като има подходящ механизъм за кеширане.

Резюме

В този урок обсъдихме дизайна на база данни на RBAC система за защита на конкретни заявки и ресурси, като разрешаваме достъп само ако потребителят има подходящо разрешение.

Можете да изпратите вашите коментари, за да се присъедините към дискусията. Може също да се интересувате от проектирането на базата данни на приложенията за блогове и анкети и анкети.

Пълната схема на базата данни е достъпна и на GitHub.