Schema del database basato sul ruolo

3

Sto progettando un database per un'applicazione di gestione dei documenti per il mio ufficio. Voglio ottenere il back-end in modo da non avere problemi in futuro. Fondamentalmente tutti gli utenti saranno categorizzati in ruoli, ad esempio super amministratore, amministratore, personale e stagisti. Tutti i documenti avranno restrizioni di accesso, ad esempio public (tutti i ruoli utente possono visualizzare il documento), privati (solo l'utente che l'ha creato può visualizzare), basati sui ruoli (questo significa che solo gli utenti con gli stessi ruoli possono visualizzare questi documenti). Tuttavia, amministratori e super amministratori possono visualizzare tutti i documenti. Un utente può avere molti documenti. Anche i ruoli degli utenti possono essere aggiornati, ad esempio, da personale ad amministratore, ecc. Utilizzerò Postgres con Sequelize come mio ORM per questo progetto. In base alla descrizione di cui sopra, questo è un buon design? Cosa può essere migliorato? Qualsiasi input sarà apprezzato.

    
posta ss_millionaire 10.06.2017 - 14:52
fonte

3 risposte

2

Un problema che vedo con

role-based (this means only users with the same roles can view these documents)

è che se creo un documento con questo tipo come stagista e in seguito viene promosso a una posizione di staff, quel documento sarà visibile agli stagisti o allo staff?

Preferirei impostare il campo access_type su Document stesso, e usare l'entità DocumentPermission per specificare quali ruoli hanno accesso a un certo Document (se il tipo di accesso è basato sui ruoli).

Inoltre (ma questa è la mia opinione , ho visto più implementazioni come la tua), metterei i ruoli (superadmin, admin, staff, stagista) in un'entità separata e ho il collegamento di entità UserRole a quell'entità anziché la colonna role_name . Il tuo design potrebbe salvarti un join, ma alla fine è meno flessibile.

    
risposta data 10.06.2017 - 15:45
fonte
1

Questo design è un inizio sonoro:

  • hai users
  • users può avere diversi roles
  • documents sono relativi agli utenti (presumo che un utente sia il proprietario dei suoi documenti qualunque sia il suo ruolo o sarà)
  • documents può avere più access types

Ma penso che sia incompleto. Queste due cose mancano:

  • di sicuro: hai detto che volevi la possibilità di avere accessi basati su ruoli, cioè dare le autorizzazioni su un documento a ruoli specifici. Ciò significa che dovresti avere anche una relazione facoltativa tra DocumentPermission e UserRoles .
  • potrebbe essere: a meno che non si desideri gestire l'accesso "pubblico" e "privato" e le relative eccezioni per amministratori e super-utenti (e in seguito per gli auditor) in modo codificato (come vengono identificati questi ruoli speciali, la via?), avresti bisogno di una tabella AccessPolicy che crei la relazione tra un tipo di accesso e i ruoli che hanno privilegi speciali per i documenti correlati.
risposta data 10.06.2017 - 16:10
fonte
-2

Per quanto a mia conoscenza, dovremmo dare il permesso ai ruoli non ai documenti o agli utenti. Come requisito per ur in futuro se aggiungete nuovi ruoli e taggateli agli utenti, dovreste farlo funzionare. Algoritmo RBAC su google puoi trovare n no.doc su di esso

    
risposta data 13.06.2017 - 05:11
fonte

Leggi altre domande sui tag