Costruisci un sistema di controllo di accesso migliore

Question

Sono in procinto di costruire un sistema di controllo degli accessi come parte di un framework web che sto sviluppando. Voglio renderlo super flessibile e fantastico. Potete aiutarmi fornendo input e informazioni sul mio design? Qui è il mio lavoro fino ad ora (le mie domande specifiche sono in fondo):

Utenti

• Gli utenti hanno un nome utente (32 caratteri, senza spazi) e la password
• Gli utenti hanno uno o più indirizzi di posta elettronica che devono essere verificate
• Gli utenti possono effettuare il login utilizzando un nome utente o qualsiasi dei loro indirizzi e-mail
• Gli utenti possono essere associati a zero o più conti

Conti

• conti rappresentano uno o più utenti
• Ogni utente può disporre di autorizzazioni specifiche o ruoli per un account (ad esempio, l'account proprietario o "può aggiungere nuovo utente")
• Tutto conti sono legate a un tipo di account

Tipi di conto

• tipi di account hanno zero o molti ruoli tipo di conto
• tipi di account hanno zero o molti tipo di conto presenta

Tipo di account ruoli

• ad esempio, "Owner", "Amministratore", "Utente avanzato", "Ospite", ecc.
• I ruoli del tipo di account sono una raccolta di autorizzazioni per il tipo di account

Permessi Tipo di account

• tipo di account permessi sono azioni specifiche nel sistema che la logica applicazione verificherà contro
• Essi possono fare riferimento a un genitore, in modo che possano essere gerarchicamente raggruppati
• Per esempio:
  • "Gestione utenti"
    • "Aggiungi utente"
    • "Rimuovi utente"
• Tali autorizzazioni possono essere specificamente per una funzione di tipo di account

Tipo di account Funzionalità

• caratteristiche tipo di account possono essere attivati ​​su un conto per dare più permessi
• ad esempio, "account standard" o "Premium Account"
• Queste caratteristiche, se attivato su un conto, darà il account del proprietario maggiore accesso al sistema
• sono tracciati quando sono attivati ​​o disattivati ​​e possono essere fatturati contro periodicamente o su richiesta

Quest ioni

Qual è il modo migliore per verificare la logica dell'applicazione rispetto a un'azione dell'utente? Stavo pensando di archiviare tutte le autorizzazioni di un utente in un oggetto per la sua sessione (che richiederebbe un logout/login per aggiornare le autorizzazioni, di cui non sono un fan - qualsiasi idea sulla gestione dei permessi in tempo reale?):

{ 
    "All Permissions": { 
    "User Management": { 
     "Add User", 
     "Delete User" 
    }, 
    "Premium Account": { 
     "Download Files", 
     "Upload Files" 
    }, 
    } 
} 

Vorrei quindi dichiarare le autorizzazioni necessarie per un'azione specifica nel sistema. Forse qualcosa del tipo:

Permission::require('Add User'); 

Se le autorizzazioni dichiarate non erano nell'oggetto di autorizzazione degli utenti, la richiesta non avrebbe avuto esito positivo. Questo sembra piuttosto intenso per ogni azione dell'utente. Inoltre, cosa succede se un altro sottoinsieme di permessi ha la stringa "Aggiungi utente"?

Grazie in anticipo per qualsiasi aiuto con questo!

Answer 1

Un modo in cui ho visto che mi piace è una specie di permessi "a cascata". Hai un nucleo di permessi - diciamo leggi, scrivi, cancella - e quelli possono essere assegnati ad un gruppo o ad un utente.

READ USER1 
READ USER2 
WRITE USER2 
READ USER3 
WRITE USER3 
DELETE USER3 

In alternativa è possibile specificare un "gruppo" anziché un nome utente.

READ SUBSCRIBER 
READ EDITOR 
READ ADMIN 
WRITE EDITOR 
WRITE ADMIN 
DELETE ADMIN 
USER1 SUBSCRIBER 
USER2 EDITOR 
USER3 ADMIN 

E allora si può semplicemente utilizzare i valori nella tabella per ordinare e cercare i record. Ciò consente la flessibilità di essere membro di più gruppi con permessi mutuamente esclusivi, ecc.

Answer 2

Osservando il tipo di account Autorizzazioni, sembra che si abbia in mente un design di sistema in stile elenco di controllo di accesso (ACL).

Se vuoi renderlo super flessibile e fantastico, allora suggerirei che questo è non un buon design.Il lavoro del sistema ACL per permessi semplici - e forse questo è davvero ok nel tuo scenario - ma non appena le regole per concedere l'autorizzazione diventano anche il minimo bit dinamico - cioè, facendo affidamento su qualsiasi dato contestuale oltre l'identità o i ruoli dell'utente - Caduta di ACL piatto veloce.

This video entra in dettaglio sui difetti degli ACL e discute metodi alternativi per implementare il controllo dell'accesso che tiene conto delle situazioni del mondo reale.

Inoltre, questo è stato fatto prima (anche se c'è sorprendentemente poco là fuori per le implementazioni che possiamo guardare); forse dare un'occhiata a Rhino Security. Il collegamento originale http://ayende.com/Blog/category/548.aspx è danneggiato, pertanto è necessario mantenere il collegamento all'archivio Internet come riferimento.

Answer 3

Non ho un consiglio specifico, ma due sistemi con cui ho familiarità con sistemi di accesso/autorizzazione flessibili molto buoni sono Drupal e Plone. Potresti fare ben peggio che copiare come funzionano entrambi. Hanno avuto anni di test nel mondo reale dietro di loro.

Answer 4

vorrei prendere uno sguardo al sistema di Java per le autorizzazioni:

http://download.oracle.com/javase/6/docs/api/java/security/Permission.html

utilizza "logica implicazione"; cioè, l'oggetto permesso è ciò che decide se l'azione data è consentita (cioè se le autorizzazioni "implicano" l'accesso a una risorsa). Vorrei anche verificare il BasicPermission in quanto ha una specifica abbastanza spazio per lo spazio dei nomi per le autorizzazioni. Nel tuo esempio, sarebbe (seguendo la nomenclatura CRUD)

• user.create
• user.delete
• file.read
• file.create

Nella nostra webapp, abbiamo assegnare un permesso a ciascuna risorsa o procedura che può essere richiesta e una serie di permessi a ciascun utente. Facciamo quindi un

boolean isAuthorized = user.permissions.implies (requestedResource.permission); (incapsulamento standard implicito)

per determinare se l'utente è autorizzato ad accedere.

Answer 5

Zed Shaw ha avuto alcune cose interessanti da dire su ACL e sui loro limiti. Sicuramente vale la pena guardare prima di proseguire su questa rotta.

http://vimeo.com/2723800

Answer 6

La semantica si sta utilizzando sono un po 'di confusione. Ad esempio, i tipi di conto di "Proprietario", "Amministratore", "Utente avanzato", "Ospite" sembrano più simili a "Tipi utente".

Inoltre, è possibile che le voci denominate "AccountPermissions" siano una sottoclasse di Account. In questo modo, a seconda del tipo di account, verranno applicate autorizzazioni diverse.

Answer 7

Ecco i miei due sensi, per quello che vale.

Innanzitutto, quando inizi a progettare questo, pensa a OOP e come si applicherà alle entità all'interno del sistema. Utenti, Ruolo utente, Ruoli, Role_Permissions, Account, Account_Types, Account_Type_Features, ecc.

UTENTI: - dovrebbe essere consentito di utilizzare OpenID come si sta guadagnando trazione - la possibilità di scegliere tra un ID o UUID per il database di portabilità

ruoli utente: (non tengono conto RUOLI TIPO) Ti incoraggio a essere molto specifico qui. Ad esempio, dove traccia la linea tra power user e administrator? Qual è la differenza tra ADMIN e OWNER? Finché questi sono chiaramente definiti (e non sfocati), allora funzionerà. Se c'è qualche domanda tra la tua base di utenti, molto presto avrai un insieme contorto di ruoli e permessi. Lo terrei al minimo per mantenere le cose pulite. Gli utenti scopriranno come lavorare con ciò che viene dato. Inoltre, lo cambierei in RUOLO DI TIPO UTENTE. I ruoli dovrebbero applicarsi all'utente, non all'account.

autorizzazioni di ruolo: (non all'account autorizzazioni TIPOLOGIA) Questo si deve ricorrere ad autorizzazioni del ruolo. Le autorizzazioni vengono estese a un ruolo utente, non a un account o a un utente. Nella mia esperienza, più chiaro il design, meno spazio per la confusione lungo la strada. Inoltre, evitare ACL come la peste. Rendilo una semplice relazione one-to-one. Devo ancora trovare una ragione per implementare ACL per qualsiasi sistema basato sul web. Altri sistemi basati su permessi sono molto più facili da capire, mantenere e usare. Non ha senso a complicare la faccenda.

TIPO ACCOUNT CARATTERISTICHE: Fare attenzione a non oscurare il tipo di account Autorizzazioni e caratteristiche del tipo di account. Il tuo primo punto elenco utilizza le autorizzazioni di parola. Passa alle funzioni. Il tipo di account attiverà funzionalità più avanzate/premium (non permessi).

Gestione autorizzazioni: Per un'applicazione senza stato in esecuzione sul Web, le sessioni sono la strada da percorrere. Il vantaggio non è un viaggio di andata e ritorno verso il DB a costantemente verificato se un utente è autorizzato.

Permission::require() dovrebbe seguire le stesse definizioni di parametro delle Sessioni. Ciò impedirà la sovrapposizione di altri sottoinsiemi di autorizzazioni. Quindi la chiamata sarebbe qualcosa come Permission::require('User Management', 'Add User'); Ciò significa che cercherebbe $_SESSION['All Permissions']['User Management']['Add User'] Ciò impedirà l'ambiguità.

Ricordare SEMPLICE è MEGLIO.

Answer 8

Vi consiglio di consultare Zend_Acl da Zend Framework. Come la maggior parte dei pacchetti Zend ha una curva di apprendimento ripida. Ma quando si coglie pienamente la risorsa, l'azione, la relazione di ruolo diventa una base versatile e potente per le proprie implementazioni ACL.

Esegui delle ricerche su pacchetti e modelli di ACL esistenti.

Answer 9

Date un'occhiata qui http://www.sqlrecipes.com/database_design/fine_grained_role_based_access_control_rbac_system-3/

I concetti sono fondamentalmente la stessa e la sua piacevole da usare e molto veloce per il controllo di accesso a grana molto fine.