Come posso semplificare la seguente progettazione del sistema di controllo accessi?

1

Non sono riuscito a trovare un titolo migliore per questo ...

Sto provando a creare un controllo di accesso per la mia applicazione e sto avendo seri problemi con la creazione di un sistema non folle, principalmente per le prestazioni poiché questo sistema risiederà in un database SQL e sarà usato eccessivamente in tutta l'app (ogni query lo userà per il recupero dei dati)

Quindi ecco il mio scenario e il mio progetto attuale:

Il mio sistema ha 3 moduli e ognuno ha le azioni generali di CRUD - elenca, visualizza, aggiorna, crea, cancella; e a volte ha azioni più specifiche come: user.view.creator, user.update.photo, user.update.metadata, storage.upload, storage.download ecc.

Voglio che il mio sistema abbia "compiti" o "operazioni" e saranno gerarchici, ad esempio storage.view avrà un child storage.download.

Questo è per le operazioni. Questa parte non ha problemi nell'implementazione e nella progettazione. Il mio problema più grande è la progettazione della connessione tra un utente e le attività. Sia RBAC che ACL non si adattano alle mie esigenze in questo caso, quindi sto cercando di crearne di nuovi. Non riesco ad implementare l'RBAC perché in RBAC i ruoli sono statici ma nel mio caso i ruoli stessi dipendono dalla risorsa e dal gruppo a cui appartiene questa risorsa. Ad esempio, il fotografo di ruolo del Gruppo A può solo caricare una foto dall'archivio, mentre il fotografo del Gruppo B può anche eliminare la foto dall'archivio. Pertanto, per mantenere le cose un po 'semplici, ho deciso di aggiungere una nuova risorsa GROUP e tutti i file, i ruoli ecc. DEVONO APPARTENGLIARE ad alcuni gruppi. D'altra parte, l'utente viene appena mappato a un gruppo; non appartengono mai a un gruppo, accedono semplicemente alle risorse in gruppi. Questo ha perfettamente senso e funziona perfettamente e non è molto complesso - le query sono più semplici, quindi ho spazio per raggruppare i database ecc.

Tuttavia, ora arriva il problema che non si adatta al mio attuale design. Ho un'altra risorsa, CLIENT. Il problema è che, in una organizzazione, un utente può avere un accesso diverso a diversi client. Quindi, per esempio, diciamo che ho il gruppo A, che ha i client da 1 a 25. Un utente specifico che appartiene a quel gruppo, può avere qualcosa del tipo:

Client 1 - Manager
Client 2 - Assistant
Client 3 - SomeOtherRole

E quando recupera un elenco di client, l'utente vedrà solo 3 client. Non so davvero cosa dovrei fare per ottenere questo nel modo più performante possibile. La mia domanda è, come devo procedere con la progettazione di questa parte del mio sistema? E una domanda migliore, come posso semplificare questo sistema?

    
posta Gasim 05.09.2014 - 09:25
fonte

1 risposta

1

Gli ACL (anche noti come IBAC o controllo di accesso basato sull'identità) e l'RBAC (controllo dell'accesso basato sui ruoli) non sono sufficienti come hai scoperto nel tuo caso d'uso. Il motivo è: stai usando ulteriori metadati o attributi. Gli attributi sono semplicemente coppie chiave-valore, ad esempio la proprietà di una foto, la natura dell'azione (ad esempio CRUD come nel tuo esempio) o il tipo di oggetto su cui stai lavorando (immagine, post di blog, metadati, pagina ...) .

Quello che vuoi fare è creare semplici regole di autorizzazione basate su quegli attributi, ad es.

A user with the role=editor can do the action=edit on an object of type=photo if and only if photo.owner==user.id

Per fare questo, è necessario passare a ABAC - controllo degli accessi basato sugli attributi. ABAC estende RBAC poiché fornisce attributi aggiuntivi in base ai quali è possibile prendere decisioni e, soprattutto, fornisce relazioni (ad esempio, la relazione di proprietà nel mio esempio).

ABAC rende estremamente semplice implementare i casi d'uso. Esiste uno standard chiamato XACML (eXtensible Access Control Markup Language) che implementa ABAC e risolverebbe il problema in modo relativamente semplice. XACML ti offre:

  • un'architettura di autorizzazione con la nozione di punto di applicazione della politica (PEP) che protegge la tua risorsa, un punto di decisione politica (PDP) che prende decisioni basate sulle politiche di autorizzazione precedentemente definite e un punto di informazione della politica (PIP) da cui puoi recuperare ulteriori metadati (ad es. il proprietario dell'oggetto).
  • un linguaggio di policy che puoi utilizzare per implementare i tuoi scenari authZ più avanzati
  • uno schema di richiesta / risposta utilizzato per inviare una domanda come "Può Alice modificare il documento # 123?" e ricevere una risposta, ad es. "Permesso".

La cosa interessante di XACML è che puoi estenderlo per soddisfare il controllo degli accessi basato su dispositivo, il controllo degli accessi sensibile al tempo o anche il controllo degli accessi sensibile all'autenticazione.

Ecco alcune altre risorse per aiutarti a iniziare:

  • ABAC - un rapporto di NIST
  • OASIS XACML - il sito web standard
  • ALFA Axiomatics Language for Authorization - uno strumento di creazione di policy gratuito per Eclipse
risposta data 03.10.2014 - 19:06
fonte

Leggi altre domande sui tag