Come gestire al meglio le autorizzazioni (non i ruoli) nell'appartenenza a asp.net, in particolare in ASP.NET MVC

Question

Ci sono un sacco di domande (e informazioni) sulla creazione di membri di asp.net, fornitori di ruoli e simili. Se si debba o meno utilizzare la piattaforma integrata fornita da microsoft, o il ruolo estendere le classi base e il proprio ruolo.

Ho deciso di estendere i provider predefiniti e implementare i miei provider di appartenenza e ruolo. Ora la mia domanda riguarda specificamente l'autenticazione dei ruoli.

Tradizionalmente, si creano ruoli come "Manager, Amministratore, Dipendente, Super utente" o qualsiasi altra cosa. Ma cosa dovrei/dovresti fare riguardo alle autorizzazioni che considero un granello di controllo più fine? Lasciatemi elaborare ...

All'interno del mio sito asp.net mvc ho diverse aree come amministrazione, gestione, messaggistica, reporting, ecc. Creerei ruoli per ognuno di questi come "Amministratore", "Manager", " Reporter 'ecc. Senza il ruolo appropriato, non è possibile accedere a quell'area del sito. Quindi avrei bloccato tutti i controller con questo a livello di classe.

Ma ora prendi un'area come un esempio; messaggistica, e dire che volevo avere autorizzazioni di grana più fine per CRUD; creare un messaggio, visualizzare/leggere messaggi, modificare messaggi, eliminare messaggi, ecc.

Finalmente la mia domanda. Come sarebbe meglio implementare questo più fine grana di controllo? Un approccio che vedo (non è sicuro se è buono), è quello di creare semplicemente i ruoli di appartenenza di asp.net per tutto. Quindi potrei avere ...

Messenger (ruolo a livello generale), CreateMessage, ReadMessage, EditMessage, DeleteMessage.

Da una parte vorrei che alcuni utenti fossero in grado di leggere/visualizzare i messaggi. Ma non necessariamente li crea o li elimina. Le singole azioni del controller possono avere i ruoli specifici applicati.

Vedi qualche problema con questo approccio? Hai un'idea migliore?

Soluzione So Far

ho deciso di creare il mio schema e implementare appartenenze personalizzato e provider di ruoli. Il mio schema include;

• utente
• ProfiloUtente
• permesso
• PermissionAssignment
• Ruolo
• RoleAssignment

assentate per il giorno successivo o due, ma verrà aggiornato con ulteriori informazioni quando Ho una possibilità

Answer 1

Penso che dovresti dimenticare i ruoli sul meccanismo di autorizzazione, chiedere invece i permessi (alla fine un ruolo è una conversione di permessi), quindi se lo guardi in questo modo, l'attributo Authorize dovrebbe chiedere un'entità e azione, non per un ruolo particolare. Qualcosa di simile:

[Authorize(Entities.Message, Actions.Create)] 
public ActionResult CreateMessage() 

[Authorize(Entities.Message, Actions.Edit)] 
public ActionResult EditMessage() 

[Authorize(Entities.Message, Actions.View)] 
public ActionResult ViewMessage() 

In questo modo i ruoli fanno quello che fanno raccolta migliori, i permessi astratti invece di determinare il modo inflessibile del livello di accesso.

EDIT: Per gestire norme specifiche come quello indicato da David Robbins, Direttore di A non è consentito di eliminare i messaggi creati da Manager B, ammesso che entrambi hanno l'autorizzazione necessaria per accedere a questa azione di controllo, l'Autorizza non è responsabile di controllare questo tipo di regole, e anche se si prova a controllare che a livello del filtro azione sia un problema, quindi ciò che si può fare è estendere la convalida Autorizza a ActionResult (iniettando un parametro di azione contenente il risultato della convalida), e lascia che ActionResult prenda la decisione logica lì con tutti gli argomenti in atto.

This è una domanda simile, non è esattamente il caso indicato qui, ma è un buon punto di partenza per estendere la convalida Autorizza con i parametri di azione.

Answer 2

Oltre ad aggiungere [Authorize(Roles="Administrator")] sopra il controller. Puoi anche inserire nelle singole azioni

Answer 3

Per quanto riguarda l'esempio CRUD, non stai realmente parlando di autorizzazione e l'autorizzazione potrebbe variare tra i ruoli di iscrizione "Manager" e "Reporter"?Penso che sia necessario creare un meccanismo separato per quelle attività a grana fine se i ruoli non distinguono tra un'autorizzazione di lettura e scrittura tra i messaggi.

Se si dovesse creare un ruolo per ogni azione - EditMessage, DeleteMessage - cosa farai nel caso in cui Manager A NON dovrebbe essere in grado di eliminare i messaggi per Manager B?