Quale struttura dati / avrebbe utilizzato per memorizzare ACL all'interno di un sistema ibrido ACL / RBAC?

9

Nel nostro sistema, ogni risorsa ha un elenco di controllo di accesso (ACL), che elenca le voci (voci ACE) che hanno un tipo specifico di accesso a quella risorsa. L'ACE può essere per entità finali (ad esempio utenti come "Mr Q") o entità di gruppo (ad esempio: "Nord Atlantico"); l'inclusione delle entità di gruppo rende questo un sistema ibrido ACL / RBAC.

Dati ACL

Resource #1 => ACL
ACL => ACE#1 Entity(Type:User, ID:006), Rights(~Read, ~Write)) /* Deny */
       ACE#2 Entity(Type:User, ID:007), Rights(Read, Write))
       ACE#3 Entity(Type:User, ID:101), Rights(Write))
       ACE#4 Entity(Type:Group, ID:A01), Rights(Read, Write))
       ACE#5 Entity(Type:Group, ID:B04), Rights(Read, Write))

Qualsiasi cosa che non appare nell'ACL verrà negata e DENY annullerà qualsiasi altra cosa.

Informazioni di sistema

C'è un server online centrale che media l'accesso a dette risorse. Le scritture sull'ACL saranno rare, per lo più saranno lette (forse al rapporto 1:50 o più).

Domanda

Qual è una struttura dati adatta per memorizzare l'ACL sopra? Memorizzare l'intero ACL come una singola stringa JSON in un archivio NoSQL sembra semplice, ma possiamo anche normalizzare i dati ACL e memorizzarli nelle tabelle SQL. Se qualcuno ha esperienza operativa sui pro / contro su entrambi gli approcci, vorrebbe ascoltarli. Ci stiamo inoltre chiedendo se valga la pena di esplorare questo in LDAP ma volevamo stare lontano da X.500 / DER e altre tecnologie di telecomunicazione ... forse ci sono le moderne opzioni LDAP (radicate nel mondo CS) per esplorare oltre NoSQL / SQL ?

    
posta Cat Nap 24.12.2013 - 22:01
fonte

1 risposta

2

Il modo migliore per strutturare un ACL è come una maschera di bit che rende facile determinare rapidamente i diritti di accesso complessi per una risorsa.

Il modo migliore per archiviare questo potrebbe essere un negozio con valore chiave come Redis o qualsiasi tecnologia di caching degli oggetti che si integri bene con il proprio ambiente. La decisione di andare con NoSQL vs SQL sarebbe più una decisione aziendale o IT piuttosto che tecnica perché una semplice ricerca potrebbe essere altrettanto veloce in entrambi i modi.

Ovviamente LDAP sarebbe anche un ottimo modo per andare, ma non ha molto senso se non si stanno integrando le autorizzazioni con altri sistemi.

    
risposta data 07.01.2014 - 22:29
fonte

Leggi altre domande sui tag