Come semplificare questo progetto di gestione dei ruoli e dei permessi?

2

Sto lavorando a un'applicazione Web con utenti con più ruoli e ogni utente può eseguire più operazioni, in base al ruolo dell'utente e il livello di autorizzazione che il ruolo ha sull'operazione. Ho trovato il seguente schema.

Utenti

+--------+-------------------+
| UserID | UserName          |
+--------+-------------------+
| 1      | Alice             |
+--------+-------------------+
| 2      | Bob               |
+--------+-------------------+
| 3      | Charlie           |
+--------+-------------------+
| 4      | David             |
+--------+-------------------+

Ruoli

+--------+-----------------+
| RoleID | RoleName        |
+--------+-----------------+
| 1      | Tech_Admin      |
+--------+-----------------+
| 2      | Tech_Normal     |
+--------+-----------------+
| 3      | Non_Tech_Admin  |
+--------+-----------------+
| 4      | Non_Tech_Normal |
+--------+-----------------+

PermissionLevels

+-------------------+----------------------+
| PermissionLevelID | PermissionLevel      |
+-------------------+----------------------+
| 1                 | Tech_Account         |
+-------------------+----------------------+
| 2                 | Non_Tech_Own_Account |
+-------------------+----------------------+
| 3                 | Non_Tech_Any_Account |
+-------------------+----------------------+
| 4                 | Own_User             |
+-------------------+----------------------+

UserRoles

+--------+--------+
| UserID | RoleID |
+--------+--------+
| 1      | 1      |
+--------+--------+
| 2      | 2      |
+--------+--------+
| 3      | 3      |
+--------+--------+
| 4      | 4      |
+--------+--------+

Comandi

+-----------+--------------+
| CommandID | CommandName  |
+-----------+--------------+
| 1         | CREATE_USER  |
+-----------+--------------+
| 2         | EDIT_USER    |
+-----------+--------------+
| 3         | VIEW_USER    |
+-----------+--------------+
| 4         | EDIT_PROFILE |
+-----------+--------------+
| 5         | VIEW_PROFILE |
+-----------+--------------+
| 6         | SUSPEND_USER |
+-----------+--------------+

RoleCommands

+--------+-----------+-------------------+
| RoleID | CommandID | PermissionLevelID |
+--------+-----------+-------------------+
| 1      | 1         | 1                 |
+--------+-----------+-------------------+
| 1      | 1         | 3                 |
+--------+-----------+-------------------+
| 2      | 2         | 1                 |
+--------+-----------+-------------------+
| 3      | 2         | 2                 |
+--------+-----------+-------------------+
| 4      | 5         | 4                 |
+--------+-----------+-------------------+

Per semplicità, non ho descritto i dettagli dell'account ma ogni utente appartiene a un account: "Tech" o "Non-Tech". C'è solo 1 account Tech nel sistema.

Ecco le regole aziendali di esempio in base alla tabella RoleCommands .

  • L'amministratore tecnico può creare utenti nell'account tecnico.
  • L'amministratore tecnologico può creare utenti in qualsiasi account non tecnologico.
  • Tech Normal può modificare gli utenti nell'account tecnico.
  • L'amministratore non tecnico può modificare gli utenti nel proprio account non tecnico.
  • Non Tech Normal può visualizzare il proprio profilo, che dalla tabella significa che altri utenti non possono visualizzare il profilo di questo utente.

Quando ricevo una nuova richiesta API REST, identifico l'operazione in base ai parametri della richiesta e verifica se l'utente dispone dell'autorizzazione per eseguire le operazioni in base alla tabella RoleCommands. Questo sembra un progetto ragionevole per la gestione dei ruoli e dei permessi?

Aggiorna

Sembra che ci saranno troppi record nella tabella RoleCommands perché, per ogni comando, ci saranno diverse combinazioni con ruoli e livelli di autorizzazione. Per un dato oggetto, possono esserci n (per es .: 10) stati in cui l'oggetto può essere. Voglio dare l'autorizzazione del comando View_Object_Status1 a un utente in modo che l'utente possa visualizzare l'oggetto quando il suo stato è Status1. Ciò sta facendo esplodere la tabella RoleCommands. Qual è il modo migliore per semplificare questo?

    
posta TechCrunch 08.07.2016 - 23:41
fonte

4 risposte

2

Il tuo design attuale è questo:

Dovrestichiederti:

  • l'entitàPERMISSION_LEVELrappresentailivellieffettivi?

Sonolivellirealisignificachequandounutentericevedueruolidiversiedentrambiiruolihannolostessocomandomaconlivellidiversi,l'appdovrebbeassumerneillivellopiùalto.Neimodellidipermessidiruolosenzalivellodiautorizzazione,vieneutilizzatalalogicadell'insieme,quindiseunutentefinisceconlastessaautorizzazioneduevolte,nonimporta.Ciòcheimportaècheilpermessoesistanelset,nonquantevolteessoesista.Mailtuomodellohaillivellodiautorizzazioneequindidovrestideciderecosafarequandounutentefinisceperaverelostessocomandodiruolopiùdiunavoltacondiversilivellidiautorizzazione.

D'altrapartenell'aggiornamentodellatuadomandamenzioniunanuovaentitàchenonèmostratanelmodellocheèOBJECT.

  • Dovesitroval'oggettonelmodello?

Perquellochepossovedereilmodellodovrebbeessereaggiornatoinquestomodo:

Ciò aumenterebbe considerevolmente il numero di riga della tabella risultante. Ma questo non dovrebbe preoccuparti troppo se crei gli indici e FK appropriati. Ciò che mi preoccupa è la complessità che assembla i ruoli, ma almeno dovrebbe essere fatto solo una volta.

Non sono sicuro di aver raccolto più domande rispetto alle risposte che ho dato.

    
risposta data 11.07.2016 - 15:05
fonte
1

Does this look like a reasonable design for Role and Permission management ?

Il termine "ragionevole" è alquanto ambiguo qui.

Adatta allo scopo

Questo design raggiunge il suo scopo. Permette di determinare quali operazioni qualsiasi utente loggato può fare su qualsiasi oggetto di business specifico:

  • Gli utenti sono identificati
  • I ruoli sono identificati
  • Gli utenti sono assegnati ai ruoli
  • I comandi sono identificati - a quanto pare un comando fa riferimento a un'operazione su un oggetto business (account utente in questo esempio)
  • I livelli di autorizzazione sono identificati - a quanto pare il livello di autorizzazione limita gli oggetti di business che sono gestiti nei comandi
  • I comandi con i livelli di autorizzazione sono assegnati ai ruoli

Forza

Questo design consente una facile gestione quotidiana degli accessi basata sui ruoli, come previsto nelle moderne applicazioni aziendali.

Questo design è flessibile. Consente di adattare i ruoli con una granularità molto fine, in modo da consentire l'implementazione di qualsiasi configurazione di accesso possibile che potrebbe essere desiderata (presupponendo che il livello di autorizzazione rappresenti adeguatamente le esigenze di segmentazione in tale materia).

Debolezza

La costruzione dei ruoli richiede l'inserimento esplicito di tutte le combinazioni. Questo potrebbe essere noioso, se i comandi oi livelli di autorizzazione sono troppo chiari.

Il livello di autorizzazione è comune a tutti gli oggetti di business:

  • Se gestisci solo un paio di oggetti business, che condividono regole di accesso simili, è ok.
  • Se ti occorrono regole di accesso diffenet su diversi oggetti business, dovrai aggiungere più livelli di autorizzazione, con il rischio di incoerenza tra il comando e il livello di autorizzazione.

A proposito, l'attuale elenco di livelli di permessi non copre in modo inequivocabile l'intero insieme di dati: suggerirei di rinominare "Proprio" in "Tech_Own" e "Tech" in "Tech_any". Capisco che "qualsiasi" significa "qualsiasi eccetto la sua".

Modifica:

Seguendo il tuo commento sulla gestione di diversi oggetti di business, ti suggerisco di aggiungere una tabella dell'oggetto business e di modificare la tabella dei comandi e i livelli di autorizzazione, in modo che entrambi siano correlati a un oggetto business.

In questo modo, sarai sicuro che i tuoi profili riguarderanno sempre comandi e livelli di autorizzazione compatibili: devi solo introdurre l'ID dell'oggetto di business in questa tabella.

Questo non renderà i ruoli più semplici, ma questo non solo risolverà il tuo problema, ma permetterà anche di offrire al manager di ruolo una bella interfaccia utente per facilitare l'inserimento (sempre scegliendo tra elementi compatibili)

    
risposta data 09.07.2016 - 02:23
fonte
1

Ecco come vorrei affrontare la situazione:

  1. Mantieni la tabella degli utenti
  2. Ciò che consideri come ruoli sono, in sostanza, gruppi di utenti. Quindi, creiamo una nuova tabella Gruppi
  3. Ciò che chiami PermissionLevel è l'equivalente di ruoli che possono avere membri dei gruppi (ad esempio, un utente che è Tech_Admin può avere il ruolo di Tech_Account e Non_Tech_account
  4. Sostituirei la tabella dei comandi con una tabella denominata moduli, in cui mantiene le diverse aree che devono essere applicate le autorizzazioni (ad esempio utente, profilo, report, ecc.)
  5. Per mantenere le autorizzazioni, userei l'approccio CRUD (creare, leggere, aggiornare, eliminare). Sebbene possa essere restrittivo, viene spesso utilizzato per la progettazione delle autorizzazioni. È possibile memorizzare il valore CRUD come byte in cui si controllano i bit o in colonne separate

Qui arriviamo a una domanda importante sulla tua applicazione e progettazione: cosa definisce le autorizzazioni per i comandi? I ruoli, i gruppi o l'utente possono avere autorizzazioni individuali che annullano le autorizzazioni del gruppo?

Possiamo andare con le seguenti tabelle:

GroupPermissions

GPID - ModuleID - CRUD (o colonne separate per C-R-U-D)

RolePermissions

RoleID - ModuleID - CRUD

Domanda successiva: nella tua app, i ruoli possono esistere indipendentemente dai gruppi? Se sì, le tabelle di cui sopra saranno sufficienti. Altrimenti, hai bisogno di una tabella per collegare i due

GroupsRoles

GRID - GroupID - RoleID

Domanda successiva: un utente può essere solo parte di un gruppo o può avere un ruolo indipendentemente dal gruppo che appartiene?

Se il primo, hai bisogno di una tabella come questa?

GroupsUsers

GUID - UserID - GroupID

Se quest'ultimo, è necessaria un'altra tabella

RolesUsers

RUID - UserID - RoleID

Infine, se un utente può avere un singolo livello di permessi indipendentemente dalla partecipazione a gruppi o ruoli, allora questa tabella è richiesta

ModulesUsers

MUID - UserID - ModuleID - CRUD

A seconda della politica sulla propagazione delle autorizzazioni, è possibile iniziare a controllare le ultime tre tabelle e decidere cosa l'utente è autorizzato a fare.

    
risposta data 12.07.2016 - 02:25
fonte
0

PermissionLevels dovrebbe definire i permessi di comando, ti renderebbe la progettazione molto più semplice, quindi ogni livello di autorizzazione verrebbe fornito con autorizzazioni predefinite.

Un'altra opzione sarebbe quella di definire permessi e ruoli come secondo e primo livello di un URN di un servizio di riposo.

Esempio: un servizio di riposo con URN come vendite, operazioni, report, configurazione. Ogni URN sarebbe un ruolo. Ogni ruolo può avere permessi come CRUD: leggi, crea, aggiorna, cancella, verifica, ecc. Per un utente, puoi assegnare una o più autorizzazioni di ruolo, ognuna delle quali dice quali permessi crudele lui / lei ha.

 User1
 Roles           Permissions
 Sales            CRUD
 Report           R
 Operation        CR

Nota: puoi anche implementare la gerarchia dei ruoli, in modo che i fori più alti abbiano i sub-ruoli autorizzati per impostazione predefinita, il che significa meno record del database per applicare le autorizzazioni a un utente.

Maggiori dettagli in link

    
risposta data 25.10.2018 - 03:05
fonte