Autorizzazioni / modello / modello corretti per l'applicazione .NET

Ho bisogno di implementare flessibile e semplice (se tale cosa esiste) e allo stesso tempo utilizzare mezzi integrati, se possibile

Finora ho implementato MembershipProvider e RoleProviders. È bello, ma dove andrò dopo?

Mi sento come se dovessi aggiungere il termine "Privilegio" e non codificare quelli all'interno dell'applicazione. Gli utenti configureranno i ruoli per aggiungere privilegi ai ruoli e assegnare ruoli agli utenti.

Suona come un buon modello? Dovrei pensare di aggiungere privilegi a livello di utente oltre ad aggiungerli ai ruoli? Potrei ma immagino problemi con l'installazione (confusione) e il supporto successivo.

Se non lo faccio e alcuni utenti specifici avranno bisogno di privilegi minori, l'amministratore dovrà creare un altro ruolo, ecc.

Qualche proiettile d'argento per un sistema come questo? E perché Microsoft non è andato oltre i soli provider di appartenenza e di ruolo?

Un'altra idea: lasciare ruoli come "privilegio" e codificarli. Quindi posso codificare quei ruoli all'interno dell'app usando tutti i markup / attributi disponibili, ecc. Tutti Microsoft.

Aggiungi una nuova entità "Gruppo" e crea una relazione come questa

• utenti
• UserGroups
• gruppi
• RoleGroups
• ruoli

In questo modo posso raccogliere ruoli in gruppi e assegnare tali gruppi agli utenti. Suona alla grande e si adatta ad altri schemi software. Ma poi non riesco davvero ad implementare cose all'interno di RoleProvider come:

• AddUsersToRoles
• RemoveUsersFromRoles

E alcune cose non hanno più senso perché saranno codificate

• deleteRole
• CreateRole

Se l'autorizzazione basata sul ruolo non è abbastanza granulare per te, ti consigliamo di utilizzare l' autorizzazione basata sulle attestazioni .

Un'affermazione descrive una risorsa e un'attività - una sorta di voce simile a una voce in un ACL, ma più flessibile, poiché la "risorsa" non deve essere un oggetto fisico, può essere qualsiasi cosa tu voglia che sia e può contenere qualsiasi informazione tu vuoi.

In questo modello, un reclamo equivale a quello che tu chiami un "privilegio" e raggruppa i reclami in insiemi di reclami, che è approssimativamente equivalente a quello che stai chiamando un "ruolo". Tutte queste API e altre ancora sono già nello System.IdentityModelspazio dei nomi.

Naturalmente menzionate MembershipProvidere RoleProvidere se state cercando di inserire tutto questo nel modello di appartenenza ASP.NET (come suggeriscono quei nomi), dimenticatene. Se desideri utilizzare quelle API del provider, devi farlo a modo loro e il loro modo non diventa più granulare del concetto di ruolo.

Invece, in ASP.NET, il concetto di "privilegio" è effettivamente codificato a livello di azione o operazione , in cui si dichiarano quali ruoli sono autorizzati a eseguire quell'azione. Questo è davvero molto più facile da gestire in ASP.NET MVC in cui basta dare uno schiaffo [AuthorizeAttribute]sui controller o sulle azioni dei controller; in ASP.NET "vecchia scuola", stai gestendo eventi, quindi l'autorizzazione tende ad essere ad-hoc o a livello di pagina (o entrambi).