Guide til designdatabase til RBAC i MySQL

Denne vejledning indeholder komplette trin til at designe et databaseskema for et rollebaseret adgangskontrolsystem (RBAC) til at administrere brugere, roller og tilladelser. Det kan yderligere bruges til at beslutte adgang til specifikke ressourcer baseret på specifikke tilladelser. Brug af et RBAC-system bør betragtes som en integreret del af enhver applikation, der deler ressourcerne mellem flere brugere. For eksempel. medarbejderne i en organisation kan få adgang til eller administrere produkterne baseret på de tilladelser, der er tildelt dem. Ideelt set kan tilladelserne tildeles via roller.

Entity Relationship Diagram eller visuelle databasedesign er vist nedenfor.

Fig. 1

Noter :Rolle- og tilladelsestabellerne, der diskuteres i dette selvstudie, kan føjes til applikationsdatabaserne, der er diskuteret i selvstudierne Blog og Poll &Survey. Denne vejledning antager, at tilladelserne er hårdkodede på kodeniveau for at kontrollere adgangen.

Du kan også besøge de populære selvstudier, herunder hvordan man installerer MySQL 8 på Ubuntu, hvordan man installerer MySQL 8 på Windows, blogdatabase i MySql, meningsmåling og undersøgelsesdatabase i MySql og lær grundlæggende SQL-forespørgsler i MySQL.

RBAC-database

Det allerførste trin er at oprette RBAC-databasen. Den kan oprettes ved hjælp af forespørgslen som vist nedenfor.

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

Jeg har brugt tegnsættet utf8mb4 for at understøtte en bred vifte af tegn.

Brugertabel

I dette afsnit vil vi designe Brugertabellen at gemme brugeroplysninger. Nedenfor nævnt er beskrivelsen af ​​alle kolonnerne i brugertabellen.

Brugertabellen med de relevante begrænsninger er som vist nedenfor.

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

Rolletabel

I dette afsnit vil vi designe Rolletabellen at gemme systemrollerne. Nedenfor nævnt er beskrivelsen af ​​alle kolonnerne i rolletabellen.

Rolletabellen med de relevante begrænsninger er som vist nedenfor.

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

Tabel med tilladelser

I dette afsnit vil vi designe Tilladelsestabellen for at gemme systemtilladelserne. Nedenfor nævnt er beskrivelsen af ​​alle kolonnerne i Tilladelsestabellen.

Tilladelsestabellen med de relevante begrænsninger er som vist nedenfor.

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

Tabel med rolletilladelser

Rolletilladelsestabellen kan bruges til at gemme tilknytningerne af tilladelserne til rollerne. Nedenfor nævnt er beskrivelsen af ​​alle kolonnerne i Rolletilladelsestabellen.

Rolletilladelsestabellen med de relevante begrænsninger er som vist nedenfor.

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

Brugerrolle

Vi kan holde systemet enkelt ved at tildele en enkelt rolle til brugeren. Den tildelte rolle kan bruges til at trække de tilladelser, der er knyttet til rollen. Adgangen til den specifikke ressource eller tilladelse kan kontrolleres ved at sammenligne den hårdkodede tilladelse, listen over tilladelser, der er knyttet til den rolle, der er tildelt brugeren.

Det kan gøres ved at bruge forespørgslen som vist nedenfor.

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;

Avancerede indstillinger

Man kan tænke på at tildele flere roller til brugeren ved hjælp af brugerrolletabellen. De mere avancerede muligheder inkluderer hierarkisystemet til at gruppere tilladelserne eller rollerne. Disse muligheder komplicerer yderligere forespørgslen for at trække tilladelseslisten og kræver derfor optimering ved at have en passende cache-mekanisme.

Oversigt

I denne øvelse har vi diskuteret databasedesignet af et RBAC-system for at sikre specifikke anmodninger og ressourcer ved kun at tillade adgang, hvis brugeren har passende tilladelse.

Du kan indsende dine kommentarer for at deltage i diskussionen. Du kan også være interesseret i at designe databasen med Blog- og Poll &Survey-applikationerne.

Det komplette databaseskema er også tilgængeligt på GitHub.