DB Schema di un controllo di accesso basato sui ruoli

Question

Attualmente sto sviluppando un'amministrazione membro per un'associazione locale qui e sto sviluppando lo schema del database al momento. Mi piacerebbe condividerlo con te per migliorarlo e dare un altro esempio di un modello di accesso basato sui ruoli (RBAC). Apprezzerei qualsiasi critica costruttiva, specialmente riguardo alle relazioni che ho usato tra i tavoli.

Link highres: http://i.stack.imgur.com/WG3Vz.png

Heres lo schema:

Come funziona:

sto mappatura clienti esistenti (in realtà i membri dell'associazione) da un'applicazione esterna nella mia amministrazione applicazione. (tabella clienti)

L'associazione è strutturata in Divisione, Suddivisioni, ecc. (tabella intern_structures). Ogni cliente può essere un membro in più Divisioni, Sottodivisioni, Sezioni ecc.

Ogni cliente può avere uno o più ruoli in tali membri (divisioni, ...) come Presidente, Attuario, Tesoriere ecc. E ogni ruolo ha certe privilegi che il proprietario del ruolo può applicare ad altri nella sua divisione, sottodivisione, sezione ecc.

Una credenziale è collegata a una determinata azione di un'applicazione. Il proprietario della credenziale può eseguire questa azione su altri membri nel suo ambito. Possono esserci più applicazioni "standalone" ma tutte condividono lo stesso sistema di autenticazione/autorizzazione.

Un'applicazione è strutturata in Moduli/Sottomoduli/Azioni ecc. Un esempio potrebbe essere un modulo "Dettagli personali" e questo modulo contiene un sottomodulo chiamato "Immagine" e potresti applicare le azioni "Visualizza, elimina, modifica" su questa immagine. Ma non è possibile eliminare alcuna immagine a meno che la persona la cui immagine si tenta di eliminare si trova in una divisione/sezione in cui si ha il ruolo adeguato per farlo.

La struttura interna e di applicazione sono entrambi alberi, implementati come elenco di adiacenza e set nidificato. L'elenco di adiacenze garantisce l'integrità e il set nidificato mi consente di attraversare l'albero rapidamente.

Un'eccezione è che è possibile fornire a qualcuno determinate credenziali direttamente (client_credentials). Questo è necessario se qualcuno ha bisogno di eseguire determinate azioni su qualcuno che non è nella sua divisione/sezione.

Quindi, qualcuno può essere membro di più divisioni/sezioni e ottenere più ruoli in ogni divisione/sezione di cui è membro. Ho intenzione di unire tutte le credenziali che qualcuno ha attraverso i suoi molteplici ruoli. E le credenziali sono sempre positive, significa che le credenziali restrittive non sono possibili.

Answer 1

ho intenzione di dare un altro esempio di un sistema RBAC mi piace molto. si prega di consultare il quadro Radicore di Tony Marston here.

Non sono sicuro che soddisfi tutte le vostre esigenze, ma qualcosa che potete confrontare con il vostro lavoro può aiutare.

Answer 2

Non mi sembra di vedere gran parte delle mappature RBAC, come ad esempio:

Operation = Any action, such as CRUD operations 
Object  = Reference to any object instance 

Permission = Mapping of 'Operation' + 'Object' 

Non sono sicuro di quello che tutti i tavoli "credenziali" sono? Una credenziale normalmente detiene proprietà per dimostrare la propria identità (es: username/password). Perché hai le credenziali per i ruoli?