Come progettare il controllo degli accessi in base al ruolo?

Sto cercando di seguire il modello di controllo dell'accesso basato sui ruoli per limitare ciò che gli utenti possono o non possono fare nel mio sistema.

Finora ho le seguenti entità:

utenti : persone che useranno il sistema. Qui ho nomi utente e password. ruoli : raccolta di ruoli che gli utenti possono avere. Oggetti come risorse manager, admin, ecc. - Cose che gli utenti possono manipolare. Come contratti, utenti, bozze di contratto, ecc. Operazioni : cose che gli utenti possono fare con le risorse. Come creare, leggere, aggiornare o eliminare.

Ora, il mio dubbio sorge qui nel diagramma in cui ho una relazione come questa:

le operazioni (0 .. *) vengono eseguite su risorse (0 .. *) che genera una tabella che ho chiamato permessi e che memorizzerà l' operazione e la risorsa .

La tabella delle autorizzazioni sarà simile a questa (una riga): ID: 1, operazione: crea, risorsa: contratto.

Il che significa un'autorizzazione per creare un contratto .

L'ho fatto in questo modo perché ritengo che alcune risorse potrebbero non avere tutti i tipi di operazioni. Ad esempio, per la registrazione dei contratti , gli utenti possono caricare file , ma questa operazione non è disponibile per la registrazione di un provider .

Quindi ora quando l' amministratore darà le autorizzazioni a un ruolo , non avrà un elenco di risorse con ogni singola operazione registrata nel sistema.

Penso che ogni risorsa abbia una propria raccolta di operazioni che possono essere eseguite su di lui.

Posso chiarire se qualcosa non è comprensibile.

È questo il modo corretto di implementare l'rbac?

MODIFICARE

Quello che voglio dire è che avendo una tabella delle autorizzazioni che ha operazioni e risorse , ho DUE tabelle extra perché voglio associare risorse alle operazioni . Avrei potuto anche semplicemente fare delle risorse con autorizzazioni in cui la tabella delle autorizzazioni avrebbe memorizzato le autorizzazioni.

Ma ciò che sarebbe accaduto è che alcune autorizzazioni che non esistono nemmeno per alcune risorse sarebbero apparse quando l'amministratore le avrebbe assegnate.

Quindi voglio sapere dal punto di vista della progettazione del database se questa autorizzazione della tabella che ha un'operazione di colonna e un'altra risorsa è corretta? Incontrerò problemi se rimane così?

Il tuo design mi sembra molto vicino. Solo un paio di suggerimenti.

utenti: persone che useranno il sistema. Qui ho nomi utente e password.

bene

ruoli: raccolta di ruoli che gli utenti possono avere. Roba come manager, admin, ecc.

Anche bene. Ma avrai anche bisogno di un'entità / tabella "UserRoles" che ti dirà quali utenti hanno quali ruoli. È probabile che un determinato utente possa avere due o più ruoli.

risorse - Cose che gli utenti possono manipolare. Come contratti, utenti, bozze di contratto, ecc.

Potrebbe essere solo una questione di semantica. Non credo che gli utenti manipolino direttamente le risorse; i ruoli lo fanno. Così va utente -> ruolo utente -> ruolo -> operazione -> risorsa

operazioni: cose che gli utenti possono fare con le risorse. Come creare, leggere, aggiornare o eliminare.

sì, tranne "ruoli" anziché "utenti"

La tabella delle autorizzazioni sarà simile a questa (una riga): ID: 1, operazione: crea, risorsa: contratto. Il che significa un'autorizzazione per creare un contratto.

Hmmm. Ci sono due modi per andare con questo. Potresti avere la tabella delle autorizzazioni che descrivi, ma ti servirà anche una RolePermissionstabella / entità aggiuntiva che ti dice quale ruolo ha quale autorizzazione. Ma non sono sicuro che sia necessario.

Un modo più semplice per farlo è una tabella / entità di autorizzazioni con queste colonne / attributi: ID ruolo, ID operazione, ID risorsa. In questo modo, le operazioni x combinazioni di risorse vengono assegnate direttamente a un ruolo, anziché essere caricate in un'autorizzazione assegnata a un ruolo. Elimina un'entità. Non c'è davvero bisogno di una tabella di autorizzazioni indipendente dal ruolo, a meno che non si desideri predefinire quali combinazioni di autorizzazioni sono consentite e quali no.

Non vorrei utilizzare o implementare RBAC. Invece vorrei usare ABAC. Lasciatemi spiegare...

• L'RBAC o il controllo degli accessi in base al ruolo riguarda la gestione degli utenti e l'assegnazione dei ruoli. In RBAC, puoi dire che Alice è un manager. È possibile definire autorizzazioni statiche insieme a quella. Ad esempio, un manager può approvare i prestiti. Quindi c'è un link da Alice al manager per approvare il prestito come permesso. Esistono molti sistemi che ti permetteranno di farlo, quindi non è necessario implementare le tue tabelle. Anche LDAP ha il supporto per set limitati di RBAC. Va bene finché si dispone di un set relativamente piccolo di ruoli e autorizzazioni. Ma cosa succede se si desidera prendere in considerazione autorizzazioni specifiche come nel tuo caso? Visualizza, elimina, inserisci? Cosa succede se si desidera tenere conto delle relazioni?
• Il controllo di accesso ABAC o basato sugli attributi riguarda l'autorizzazione basata su criteri e granulare. Con ABAC è possibile utilizzare i ruoli definiti in RBAC e scrivere politiche ad es
  • I manager possono visualizzare i documenti nel loro reparto
  • I dipendenti possono modificare i documenti di loro proprietà

Nella tua domanda, hai essenzialmente definito il modello informativo. I tuoi oggetti e i loro attributi, ad esempio un utente (nome, password, dipartimento ...); un oggetto (ad es. un contratto) e così via.

In ABAC, pertanto, dovresti disaccoppiare completamente il codice / la logica dell'app dalla logica di autorizzazione che viene quindi archiviata come criteri utilizzando gli attributi. Le autorizzazioni stesse sono archiviate nel criterio (vedere l'esempio sopra). L'architettura di distribuzione ABAC è simile alla seguente

Il punto è che se si adotta un approccio ABAC, si scrivono politiche per ABAC (in XACML o ALFA - ci sono molti strumenti per quello) e non è necessario codificare in modo personalizzato o implementare RBAC personalizzato o controllare nuovamente l'accesso.