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

Naviga le tue risposte
9

Ho bisogno di implementare semplici E flessibili (se esiste una cosa del genere) e allo stesso tempo utilizzare mezzi integrati, se possibile

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

Mi sento come se avessi bisogno di aggiungere il termine "Priviledge" e di codificare quelli all'interno dell'applicazione. Gli utenti configureranno i ruoli per aggiungere Privilidges ai ruoli e assegnare ruoli agli utenti.

Sembra 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.

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

Un'altra idea: Lasciare ruoli come titolare "privilegiato" e hardcode. Quindi posso codificare i ruoli all'interno dell'app utilizzando tutti i markup / attributi disponibili, ecc. Tutto Microsoft.

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

  • Utenti
  • Gruppi utenti
  • Gruppi
  • RoleGroups
  • Ruoli

In questo modo posso raccogliere ruoli in gruppi e assegnare tali gruppi agli utenti. Sembra eccezionale e corrisponde ad altri modelli di software. Ma poi non posso davvero implementare le cose all'interno di RoleProvider come:

  • AddUsersToRoles
  • RemoveUsersFromRoles

E alcune cose non hanno più senso perché saranno hard-coded

  • DeleteRole
  • CreateRole
posta katit 14.06.2011 - 21:34
fonte

1 risposta

5

Se l'autorizzazione basata sui ruoli non è abbastanza granulare per te allora considera di usare Autorizzazione basata sulle attestazioni .

Un'asserzione descrive una risorsa e un'attività - un po 'come una voce in una ACL, ma più flessibile, perché la "risorsa" non deve essere un oggetto fisico, può essere qualsiasi cosa tu voglia che sia e può contiene tutte le informazioni che desideri.

In questo modello, un reclamo equivale a ciò che chiami "privilegio" e raggruppa le rivendicazioni in serie di richieste, che è grosso modo equivalente a ciò che stai definendo un "ruolo". Tutte queste API e altre sono già nello spazio dei nomi System.IdentityModel .

Ovviamente tu parli di MembershipProvider e RoleProvider e se stai cercando di stipare tutto questo nel modello di appartenenza ASP.NET (come implicano tali nomi), allora dimenticalo. Se si desidera utilizzare tali API del provider, è necessario farlo a modo loro e la loro modalità non diventa più granulare del concetto di ruolo.

Invece, in ASP.NET, il concetto di "privilegio" è effettivamente codificato al livello azione o operazione , dove dichiari quali ruoli sono autorizzati ad eseguire quell'azione. Questo è molto più facile da gestire in ASP.NET MVC in cui si esegue uno slap di [AuthorizeAttribute] su controller o azioni del controller; in ASP.NET "vecchia scuola", gestisci gli eventi, quindi l'autorizzazione tende ad essere ad-hoc oa livello di pagina (o entrambi).

    
risposta data 14.06.2011 - 22:36
fonte

Leggi altre domande sui tag

Linee guida per la revisione del codice per CSS, JS e HTML Esiste un valido motivo per cui le colonne in SQL sono annullabili per impostazione predefinita?