Architettura di sicurezza: impostazioni per guidare interfaccia utente e privilegi (diritti) - Basato sui ruoli, per account utente

Hai esaminato l'Autenticazione basata sui crediti? L'idea è quella allegata a ciascun utente autenticato è una raccolta di attestazioni e ogni rivendicazione rappresenta qualcosa sull'utente. Quando l'utente viene autenticato, viene raccolta una raccolta di attestazioni per la particolare applicazione in questione e può contenere un set arbitrario come "CanSubmitGoogleOrders" o "PurchaseLimit = $ 4000".

L'applicazione stessa deve solo sapere quali potenziali rivendicazioni possono ricevere e agire di conseguenza se vede (o non vede) alcuna rivendicazione particolare.

Penso che dipenda molto dall'uso finale. Appena fuori di testa e senza sapere una tonnellata sull'utente finale dell'app, hai pensato all'autenticazione basata su sessioni? Fondamentalmente fai un controllo sulle loro autorizzazioni e applica qualche tipo di identificatore alla loro sessione. In questo modo è possibile concedere le autorizzazioni permesse delle richieste, che dovrebbero essere più veloci del controllo di tutte le autorizzazioni utente su ogni richiesta. Basta disporre di una tabella di ricerca per un'azione e di quali sessioni è possibile utilizzarla, in modo da poter archiviare tutto centralmente, che è molto più facile da gestire. Solo una nota a margine, questa è puramente una risposta alla facilità di implementazione / gestibilità / velocità, più sicuro vuoi che la tua app sia evidente e più sacrifichi la velocità. Ciò che realmente guiderà la tua implementazione è capire il ragionevole punto di equilibrio tra velocità accettabile e sicurezza.

Pubblicherò una risposta più lunga quando ne avrò un po 'più tardi oggi.

Questo è in realtà un problema ben noto, e sfortunatamente non esistono ancora molte soluzioni pacchettizzate, almeno non molto buone.

Il controllo degli accessi basato sui ruoli è solo un compromesso tra amministrazione e sicurezza scalabili. Spesso, questa era una buona scelta, semplicemente perché l'alternativa era - beh, non ci sono state davvero molte alternative fino ad ora ... Coinvolse sempre enormi quantità di codice personalizzato complesso. Tranne che nel caso di requisiti di sicurezza bancari o militari, quella era la strada da percorrere ... ma, era sempre un compromesso nell'interesse di rendere la sicurezza gestibile.

Mentre il suggerimento di @SteveS di un'autenticazione basata sulle attestazioni è buono (per .NET è possibile controllare ciò che era noto come Geneva Framework, o Windows Identity Foundation (WIF) ), ed è decisamente un miglioramento nella direzione di una sicurezza più granulare, non aiuta davvero a risolvere il problema della" scalabilità amministrativa ".

Puoi anche guardare nella direzione di ciò che è (sfortunatamente) noto come "gestione dei diritti", controllo dell'accesso basato su criteri / attributi (ABAC / PBAC), controllo dell'accesso sensibile al contesto, ecc.

A tal fine, puoi consultare XACML - mentre ha sicuramente delle imperfezioni non banali (anche la prossima v3 manca il segno ...), è sicuramente un passo importante nella giusta direzione concettuale. (È solo un formato / protocollo, non familiare con gli strumenti standard per far rispettare questo ...)

In conclusione, sfortunatamente, non ci sono ancora soluzioni valide per la granularità scalabile della gestione del controllo degli accessi. Al giorno d'oggi non richiede ancora una piccola quantità di personalizzazione, né la codifica personalizzata nella tua app, né ampie modifiche ad alcuni prodotti amministrativi passivamente correlati. Forse qualche piccola startup troverà presto la soluzione ...
_{Divulgazione: sto lavorando con uno di questi startup, per rendere la granularità di accesso scalabile qualcosa che puoi usare ...}