Esiste una semplice implementazione generica del controllo degli accessi basato su regole?

Question

Sto implementando il controllo degli accessi di un sito intranet. Sarebbe facile se la società non avesse più di 200 dipendenti e autorizzazioni personalizzate per quasi tutti. È una follia, lo so, ma non posso cambiarlo.

Quindi, ho cercato di trovare un'implementazione generica che potesse soddisfare le mie esigenze, ma non riuscivo a trovarla, quindi sono andato a farlo da solo. Alla fine, ho trovato una soluzione abbastanza generica che mi ha fatto pensare: qualcuno deve averlo fatto prima!

L'ho chiamato STOP (oggetto Oggetto autorizzazione) Controllo accesso. Ho la seguente relazione:

.-------.  .-----------.  .-------. 
| users |1---*| STOPRules |*---1| tasks | 
`-------'  '-----------'  '-------' 

Un ARRESTO regola ha i seguenti attributi

STOPRule { 
    Subject; 
    Task; 
    ObjectType; 
    Permission; 
    Relation; 
} 

La relazione oggetto può essere: proprietario, creatore, revisore, ecc Questo campo non è obbligatorio, per supportare compiti generici. Quando è lì, la relazione tra l'utente corrente e l'istanza dell'oggetto viene calcolata da un delegato. La relazione corrente viene quindi confrontata con la relazione richiesta sulla regola per consentire o negare l'accesso.

Fammi sapere se non ero abbastanza chiaro.

Due domande sorgono:

1. C'è un'implementazione open source come questo?

2. Vedi qualche problema che incontrerei seguendo questo percorso?

EDIT: Sono andato avanti e in realtà iniziato ad attuare questo modello. Il primo problema era che avevo bisogno della relazione tra soggetto e oggetto per supportare qualsiasi caso d'uso. Ora, posso memorizzare la seguente regola:

John (soggetto) può (permesso) modifica (task) un ordine (oggetto) se egli è il creatore (relazione) del ordine.

Per favore, potete fornire un caso d'uso REALISTICO che non potrebbe essere espresso usando questo modello?

Answer 1

Che dire di avere effettivamente una tabella con autorizzazioni raggruppate per determinati ruoli e utilizzare un'altra tabella per autorizzazioni estese che sovrascrivere quelle generali. Se è il caso di lasciare solo a John accedere a qualcosa, perché anche menzionare che l'altra persona non può? Come per l'ultimo esempio che hai fornito nel commento precedente: esiste una tabella con le autorizzazioni. Un record assomiglia a: 1645 edit_some_field. Quindi group_permissions assomiglia a: 1645 everyone false e la tabella delle eccezioni finale sarebbe 1645 (Jane Doe's ID) true.

Se, diciamo che ci sono 50 persone che hanno accesso a modificare questo campo, quindi basta aggiungere un altro gruppo nella tabella gruppo come: 89 editors_of_field_X, mettere gli ID della gente in una tabella group_members come 89 (John Smith's ID) true. E poi sul passo finale puoi scavalcare quelli con le autorizzazioni di una sola persona come ho detto sopra. Quindi, in conclusione, avresti uno schema a 3 livelli. Ognuno-gruppo-persona.E più approfondisci la tua importanza più alta di quel ruolo. Ad esempio se tutti non sono ammessi, ma il gruppo in cui ti trovi è consentito, puoi modificare qualcosa.

Inoltre, se non ti è consentito accedere a livello di terza persona, poi di nuovo, sei diventato un'eccezione nel gruppo. In questo modo sarai in grado di riutilizzare i gruppi per dopo, aggiungendo solo modifiche minori.

Answer 2

John ha creato un ordine e vuole consentire a Bob di visualizzarlo.