Autorizzazione su proprietà complessa

1

Ho problemi con la proprietà dell'oggetto nella mia applicazione web. Nella mia applicazione web. Esistono tipi di oggetto:

1. Faculty
2. Student
3. Student Group
4. Student Lesson 

Sono disponibili i seguenti ruoli utente:

1. Group Leader
2. Teacher
3. Dean
4. Admin

Ogni tipo di oggetto ha molti oggetti. Nell'applicazione, il ruolo "Utente" dispone di autorizzazioni per tipi di oggetto specifici, ad esempio:

GroupLeader1 has permission on StudentGroup5
Dean4 has permission on Faculty2

E i tipi di oggetto hanno una gerarchia:

Faculty has Students.
StudentGroup has Students.
Student has Lessons



Dean4 has permission on all students which corresponds to Faculty2.
Dean3 has permission on all students which corresponds to Faculty4.
GroupLeader1 has permission on all student which corresponds to StudentGroup5.

Come posso gestire questo complesso problema di proprietà, esistono dei modelli per questa situazione?

    
posta Taleh Ibrahimli 18.03.2016 - 21:13
fonte

2 risposte

2

Questo è un problema classico. Sono stato interessato a questo da qualche tempo a questa parte e non sono a conoscenza di nessun modello standard che lo risolva veramente (ancora).

L'RBAC può essere adattato per funzionare per la tua situazione introducendo i parametri. Esistono diversi nomi per questi adattamenti, il più comune è l'RBAC parametrizzato (pRBAC). Ho anche visto nomi come RBAC Context Aware, RBAC Object Aware e RBAC relazionale, che sono incarnazioni diverse della stessa idea di base. Sfortunatamente, alcuni di questi termini, perché non c'è standardizzazione o consenso, si riferiscono anche ad altri modelli di accesso.

Ci sono molti concetti di pRBAC che fluttuano, che differiscono tutti nei dettagli ma sono ancora in gran parte la stessa idea.
Puoi dare un'occhiata ai documenti A Design for Parameterized Roles di Mei Ge e Sylvia L. Osborn . Un modello formale è stato descritto da Ali E. Abdallah e Etienne J. Khayat nel loro documento Un modello formale per il controllo degli accessi con controllo parametrico basato sui ruoli .

Proprio come in RBAC standard, in pRBAC, a un soggetto viene assegnato un ruolo. Il ruolo consiste in una o più autorizzazioni, ciascuna autorizzazione consiste in un'operazione, una coppia di oggetti.
In estensione a RBAC, pRBAC consente agli oggetti di avere parametri e utenti da inizializzare per un determinato ruolo con i valori dei parametri per un oggetto su cui hanno un'autorizzazione in quel ruolo.

Quindi, ad esempio, all'oggetto studentCourseResult verrebbe assegnato il parametro studentId . Invece di avere un ruolo chiamato Teacher , definirai il ruolo TeacherOf con i valori parametro studentId = {1, 2, 7, 9, 11} .
Se il valore del parametro per l'oggetto si trova all'interno dell'insieme di valori di parametro assegnati a un oggetto per questo ruolo, l'accesso è concesso.

Si noti che è un passo facile da qui per non solo consentire l'operatore = per i vincoli dei parametri, ma anche consentire > , < , <= , ecc.


Oltre a pRBAC potresti dare un'occhiata a Controllo dell'accesso basato sugli attributi (ABAC) , che al momento è abbastanza di moda ( ma risolve un problema diverso e ne crea di nuovi) e controllo dell'accesso basato su autorizzazione (ZBAC) che è sicuramente un concetto molto interessante, ma probabilmente eccessivo per il caso d'uso che descrivi, in quanto per lo più (e molto ordinatamente) risolve il problema dell'autorizzazione cross domain.

    
risposta data 18.03.2016 - 22:40
fonte
0

Anche se mi piacciono molto i concetti menzionati da @Jacco, la verità è che sarebbe molto eccitante nel tuo scenario. Persino l'RBAC è davvero l'inverso di quello che ti serve ...

L'unico modello di cui hai bisogno qui è semplicemente DAC - con ereditarietà. Cioè, nel tuo esempio, Faculty2 avrà un ACE che concede l'autorizzazione a Dean4 - e tutti gli studenti che corrispondono a Faculty2 erediteranno queste autorizzazioni. Quindi se Dean4 va a eseguire qualche operazione su Student6 , che appartiene a Faculty2 , sarà autorizzato lo stesso ACE che è stato impostato su Faculty2 ed è ereditato da tutti gli studenti.

Se lo desideri, puoi trattare il requisito di GroupLeaders can only get permissions on StudentGroups ed ecc. come una sorta di "meta-vincolo RBAC", quindi non concedere l'accesso in base al ruolo dell'utente, ma trattandolo in modo applicativo come una restrizione di runtime.

Da lì, dovresti semplicemente considerare il sistema concettualmente come un sistema basato su DAC standard.

La cosa importante in questi tipi di sistemi è di supportare solo la complessità richiesta strettamente - ma non di più.
A volte è meno complicato invertire la prospettiva del controllo.

    
risposta data 18.12.2016 - 16:17
fonte

Leggi altre domande sui tag