2010-02-25 15 views
8

Abbiamo un sistema piuttosto complicato di gestione dei permessi nella nostra applicazione (ASP.NET web). Gli utenti possono disporre di autorizzazioni specifiche su diversi tipi di oggetti, alcune autorizzazioni vengono persino raggruppate in gruppi/ruoli assegnati agli utenti. Tutto questo finisce in un pasticcio piuttosto complicato in cui per determinare se un utente può fare/vedere qualcosa è necessario valutare molte diverse fonti di permessi e questo viene fatto in qualche modo su richiesta e in base a situazioni specifiche.Modelli/suggerimenti di progettazione per la gestione delle autorizzazioni

La mia domanda è (da un punto di vista di alto livello) se ci sono alcuni suggerimenti/schemi di progettazione comuni per gestire il concetto di autorizzazione in generale e probabilmente anche la vostra esperienza con la gestione di tali architetture.

+1

Inoltre, in 3.5 è presente "Appartenenza ASP.NET" che ha alcune funzionalità per gestire questo problema, ma non so quanto sia amichevole per il programmatore. – AaronLS

+0

Una buona domanda, che richiede una risposta migliore rispetto a quelle elencate di seguito. Sto guardando qualcosa di simile in Java, ma permetto autorizzazioni ereditate. Ho avuto difficoltà a trovare schemi/algoritmi sulla rete. – cs94njw

risposta

5

Utenti e gruppi con la possibilità di testare bool UserHasPermission(SOME_PERMISSION) per un permesso atomica associato ad un gruppo è l'approccio standard per l'autorizzazione, ma le cose stanno cambiando per basata sulle attestazioni:

http://msdn.microsoft.com/en-us/magazine/ee335707.aspx

http://msdn.microsoft.com/en-us/magazine/cc163366.aspx

http://www.infoq.com/news/2009/10/Guide-Claim-Based-Identity

Tuttavia, non è l'ideale per tutte le situazioni.

Per il vecchio modello, trovo che le prestazioni può essere ottenuto utilizzando Memoizzazione durante autorizzazioni assegni. In questo modo non vado al database n volte per sessione per controllare il controllo degli accessi. Memoization memorizza in modo efficace in una cache il risultato di una chiamata con gli stessi parametri, quindi tutte le chiamate di un particolare utente per controllare l'autorizzazione XYZ restituirebbero lo stesso risultato. Naturalmente, assicurati di aver archiviato le autorizzazioni memoized per l'utente nella Session in modo che sia per utente. Se si caricano le autorizzazioni all'accesso, non è necessario memorizzarle nella cache, ma in sistemi di grandi dimensioni con molte autorizzazioni a volte è meglio ottenerle solo quando necessario.

http://www.infoq.com/news/2007/01/CSharp-memory

2

non ho affrontato questo dal punto di vista lo sviluppo di applicazioni, ma spesso quando si tratta di permessi è una buona pratica per impostare le autorizzazioni per gli oggetti utilizzando i ruoli, piuttosto che dare agli utenti l'autorizzazione direttamente all'oggetto. Se un utente ha bisogno di accedere a un particolare insieme di oggetti, non gli si dà accesso direttamente, ma si dà loro un ruolo, che a sua volta ha l'accesso necessario. Questo in un certo senso "riutilizza" il lavoro che è stato messo nella creazione del ruolo.

La gestione di questo codice tuttavia può risultare complicata, poiché è necessario eseguire un'iterazione di ciascuno dei ruoli di un utente e determinare se il ruolo fornisce all'utente l'autorizzazione per l'oggetto. Non conosco alcun suggerimento specifico su come trattare con altro che l'ovvio tentativo di includere quel tipo di codice nel suo stesso framework.

+0

Forse non esiste un modo migliore, questa è fondamentalmente la domanda;) In realtà abbiamo questi concetti di gruppi e ruoli che lo rendono molto conveniente per l'utente finale che ha vari modi diversi di configurare le autorizzazioni. Il problema è più di un problema di manutenzione per noi, dove la gestione di tutte queste diverse fonti diventa sempre più noiosa. –

6

Ho visto diversi complicati schemi di autorizzazione. C'era sempre una giustificazione, ma sfortunatamente, a un certo punto nel tempo, erano diventati troppo complicati da affrontare e ridotti a qualcosa di più semplice.

La mia conclusione personale ora è: attenersi a Controllo accessi di base dei ruoli (RBAC) questo è l'unico ragionevole che tutti capiscano. È in qualche modo limitato, ma sufficiente per la maggior parte dei casi.

Inoltre, utilizzare negare per impostazione predefinita la politica, vale a dire, si concedono solo i diritti.Ancora una volta, ho visto il sistema con il contrario (consentire per impostazione predefinita) o anche la politica predefinita configurabile (!) E non penso che sia ragionevole.

Problemi correlati