Controllo degli accessi in base al ruolo (RBAC) vs. controllo degli accessi in base ai reclami (CBAC) in ASP.NET MVC

Quali sono i principali vantaggi dell'utilizzo di CBAC vs. RBAC ? Quando è meglio usare CBAC e quando è meglio usare RBAC?

Sto cercando di comprendere i concetti generali del modello CBAC, ma l'idea generale non è ancora chiara per me.

Proverò a mostrare come è possibile beneficiare del controllo degli accessi in base al reclamo in un contesto MVC ASP.NET.

Quando si utilizza l'autenticazione basata sul ruolo, se si dispone di un'azione per la creazione di un cliente e si desidera che le persone che ricoprono il ruolo di "vendita" siano in grado di farlo, allora si scrive un codice come questo:

[Authorize(Roles="Sale")]
public ActionResult CreateCustomer()
{
    return View();
}

Successivamente, ti sei reso conto che, a volte, le persone con il ruolo di "Marketing" dovrebbero essere in grado di creare clienti. Quindi aggiorni il tuo metodo di azione in questo modo

[Authorize(Roles = "Sale", "Marketing")]
public ActionResult CreateCustomer()
{
    return View();
}

Ora, ti sei reso conto che alcune persone del marketing non devono essere in grado di creare un cliente, ma non è possibile assegnare un ruolo diverso a quelle persone che sono nel marketing. Quindi, sei costretto a consentire a tutti gli addetti al marketing di creare clienti.

hai riscontrato un altro problema, ogni volta che decidi che gli addetti al marketing dovrebbero poter creare clienti, devi aggiornare tutti i metodi di azione MVC Autorizzare l'attributo, compilare l'applicazione, testare e distribuire. Alcuni giorni dopo, hai deciso di non fare marketing ma a qualche altro ruolo dovrebbe essere permesso di svolgere l'attività, quindi cerca nella tua base di codice ed elimina tutto il 'Marketing' dall'attributo Autorizza e aggiungi il tuo nuovo nome di ruolo nell'attributo Autorizza ... Non un soluzione salutare. A quel punto, ti accorgeresti della necessità di un controllo di accesso basato sulle autorizzazioni.

Il controllo degli accessi in base alle autorizzazioni è un modo per assegnare varie autorizzazioni a vari utenti e verificare se un utente dispone delle autorizzazioni per eseguire un'azione dal codice in fase di esecuzione. Dopo aver assegnato varie autorizzazioni a vari utenti, ti rendi conto che devi consentire ad alcuni utenti di eseguire del codice se l'utente ha proprietà come "Utente Facebook", "Utente da molto tempo" ecc. Lasciami fare un esempio. Supponi di voler consentire l'accesso a una pagina specifica se l'utente ha effettuato l'accesso tramite Facebook. Ora, creeresti un'autorizzazione "Facebook" per quell'utente? No, "Facebook" non sembra un'autorizzazione. Vero? Piuttosto sembra un reclamo. Allo stesso tempo, anche i permessi possono sembrare Claim !! Quindi, è meglio controllare i reclami e consentire l'accesso.

Ora, torniamo all'esempio concreto di controllo degli accessi basato su attestazioni.

Puoi definire un insieme di affermazioni come questo:

"CanCreateCustomer", "CanDeleteCustomer", "CanEditCustomer" .. ecc.

Ora puoi decorare il tuo metodo di azione in questo modo:

        [ClaimAuthorize(Permission="CanCreateCustomer")]
        public ActionResult CreateCustomer()
        {
            return View();
        }

(si noti che [ClaimAuthorize (Permission = "CanCreateCustomer")] potrebbe non essere integrato nella libreria di classi MVC, sto solo mostrando come esempio, è possibile utilizzare alcune librerie di classi che hanno tale definizione di classe Attributo)

Ora puoi vedere che il metodo di azione CreateCustomer avrà sempre bisogno dell'autorizzazione 'CanCreateCustomer' e non cambierà o difficilmente cambierà. Quindi, nel tuo database, crei una tabella di autorizzazioni (attestazioni) e relazione di autorizzazione utente. Dal tuo pannello di amministrazione, puoi impostare l'autorizzazione (reclamo) per ogni utente che può fare cosa. Puoi assegnare l'autorizzazione "CanCreateCustomer" (reclamo) a chiunque ti piaccia e solo l'utente autorizzato sarà in grado di creare un cliente e l'utente autorizzato sarà in grado di creare solo un cliente e nient'altro (a meno che tu non assegni altre autorizzazioni allo stesso utente).

Questo modello di sicurezza offre una pratica del codice pulita. Inoltre, quando scrivi il tuo metodo di azione, non devi pensare a chi può usare questo metodo, ma puoi sempre essere certo che chiunque stia usando questo metodo avrà l'autorizzazione (reclamo) fornita dall'amministratore. Quindi, l'amministratore può decidere chi sarà in grado di fare cosa. Non tu come sviluppatore. Ecco come la tua logica aziendale è separata dalla logica di sicurezza.

Ogni volta che qualcuno accede, l'applicazione verifica quali autorizzazioni sono disponibili per quell'utente e tale set di autorizzazioni (reclamo) sarà disponibile come proprietà aggiuntive dell'utente attualmente connesso (di solito il set di reclami è memorizzato come cookie per l'utente che ha effettuato l'accesso), quindi non è necessario controllare le autorizzazioni impostate continuamente dal database. La linea di fondo è che si ottiene un maggiore controllo della logica di sicurezza nella propria applicazione se si applica l'accesso basato su attestazioni anziché l'accesso basato sui ruoli. In effetti, anche un ruolo può essere considerato come un reclamo.

Se la tua applicazione è una piccola applicazione in cui ci sarebbero solo 2 ruoli: Cliente e Amministratore e non vi è alcuna possibilità che il Cliente sarà in grado di fare qualsiasi altra cosa diversa da quella che dovrebbe fare nella tua applicazione, quindi forse, in base al ruolo il controllo dell'accesso servirà allo scopo, ma man mano che la tua applicazione cresce, inizierai a sentire la necessità di un controllo dell'accesso basato sui reclami ad un certo punto.

Ho implementato molti modelli di sicurezza ora e ho dovuto avvolgere la mia testa anche su questi concetti. Avendolo fatto molte volte, ecco la mia comprensione di questi concetti.

Cosa sono i ruoli

Ruolo = Unione di utenti e autorizzazioni.

Da un lato, un ruolo è una raccolta di autorizzazioni. Mi piace chiamarlo un profilo di autorizzazione. Quando si definisce un ruolo, in pratica si aggiunge una serie di autorizzazioni in quel ruolo, in tal senso un ruolo è un profilo di autorizzazione.

D'altra parte, un ruolo è anche una raccolta di utenti. Se aggiungo Bob e Alice al ruolo "Gestori", allora "Gestori" ora contiene una raccolta di due utenti, un po 'come un gruppo.

La verità è che un ruolo è ENTRAMBI una raccolta di utenti e una raccolta di autorizzazioni messe insieme. Visivamente questo può essere visto come un diagramma di Venn.

Che cos'è un gruppo

Gruppo = Raccolta di utenti

Un "Gruppo" è rigorosamente una raccolta di Utenti. La differenza tra un gruppo e un ruolo è che un ruolo ha anche una raccolta di autorizzazioni ma un gruppo ha solo una raccolta di utenti.

Che cos'è un'autorizzazione

Autorizzazione = Cosa può fare un soggetto

Che cos'è un set di autorizzazioni

Set di autorizzazioni = Una raccolta di autorizzazioni

In un robusto sistema RBAC, le autorizzazioni possono anche essere raggruppate come Utenti. Mentre i gruppi sono solo una raccolta di utenti, un insieme di autorizzazioni è solo una raccolta di autorizzazioni. Ciò consente a un amministratore di aggiungere contemporaneamente intere raccolte di autorizzazioni ai ruoli.

Come utenti, gruppi, ruoli e autorizzazioni si incontrano

In un robusto sistema RBAC, gli utenti possono essere aggiunti a un ruolo singolarmente per creare la raccolta di utenti nel ruolo o è possibile aggiungere gruppi a un ruolo per aggiungere una raccolta di utenti al ruolo contemporaneamente. In entrambi i casi, il ruolo ottiene la sua raccolta di utenti dall'aggiunta individuale o dall'aggiunta di gruppi al ruolo o dall'aggiunta di un mix di utenti e gruppi al ruolo. Le autorizzazioni possono essere pensate allo stesso modo.

Le autorizzazioni possono essere aggiunte ai ruoli singolarmente per creare la raccolta di autorizzazioni all'interno del ruolo oppure è possibile aggiungere un set di autorizzazioni a un ruolo. Infine, è possibile aggiungere una combinazione di autorizzazioni e set di autorizzazioni a un ruolo. In entrambi i casi, il ruolo ottiene la raccolta di autorizzazioni da aggiungere individualmente o aggiungendo set di autorizzazioni a un ruolo.

Lo scopo di Ruoli è quello di sposare gli utenti alle autorizzazioni. Pertanto, un ruolo è l'UNIONE di utenti e autorizzazioni.

Quali sono i reclami

Reclamo = What a Subject "is"

I reclami NON sono permessi. Come sottolineato nelle risposte precedenti, un reclamo è ciò che un soggetto "non è" ciò che un soggetto "può fare".

I reclami non sostituiscono i ruoli o le autorizzazioni, sono informazioni aggiuntive che è possibile utilizzare per prendere una decisione di autorizzazione.

Quando utilizzare i reclami

Ho riscontrato che i reclami sono utili quando è necessario prendere una decisione di autorizzazione quando l'utente non può essere aggiunto a un ruolo o la decisione non è basata sull'associazione dell'utente all'autorizzazione. L'esempio di un utente di Facebook causa questo. Un utente di Facebook potrebbe non essere qualcuno che viene aggiunto a un "ruolo" ... sono solo alcuni visitatori autenticati tramite Facebook. Sebbene non si adatti perfettamente a RBAC, è una informazione su cui prendere una decisione di autorizzazione.

@CodingSoft ha usato la metafora del night club in una risposta precedente, che vorrei estendere. In quella risposta, la patente di guida è stata utilizzata come esempio che conteneva una serie di reclami in cui la data di nascita rappresenta una delle rivendicazioni e il valore del reclamo DateOfBirth viene utilizzato per verificare la regola di autorizzazione. Il governo che ha rilasciato la patente di guida è l'autorità che dà l'autenticità del reclamo. Pertanto, in uno scenario da night club, il buttafuori alla porta osserva la patente di guida della persona, assicura che sia stata rilasciata da un'autorità fidata esaminando se si tratta di un documento falso (ovvero deve essere un documento di identità valido rilasciato dal governo), quindi esamina la Data di nascita (una delle tante affermazioni sulla patente di guida), quindi utilizza quel valore per determinare se la persona è abbastanza grande per entrare nel club. Se è così,

Ora, con quella base in mente, vorrei estenderlo ulteriormente. Supponiamo che l'edificio in cui si trova il night club contenga uffici, stanze, una cucina, altri piani, ascensori, un seminterrato, ecc. Dove possano entrare solo i dipendenti del club. Inoltre, alcuni dipendenti potrebbero avere accesso a determinati luoghi che altri dipendenti potrebbero non avere. Ad esempio, un Manager può avere accesso a un piano superiore al quale altri dipendenti non possono accedere. In questo caso ci sono due ruoli. Manager e dipendente.

Mentre l'accesso dei visitatori all'area del night club pubblico è autorizzato da un unico reclamo, come spiegato sopra, i dipendenti hanno bisogno dell'accesso per ruolo ad altre sale riservate non pubbliche. Per loro, una patente di guida non è sufficiente. Ciò di cui hanno bisogno è un badge per i dipendenti che scansionano per entrare nelle porte. Da qualche parte c'è un sistema RBAC che garantisce ai badge nel ruolo di Manager l'accesso all'ultimo piano e ai badge nel ruolo del dipendente l'accesso ad altre stanze.

Se, per qualsiasi motivo, determinate stanze devono essere aggiunte / rimosse da Role, questo può essere fatto utilizzando RBAC, ma non è adatto per un reclamo.

Autorizzazioni nel software

La codifica dei ruoli nell'applicazione è una cattiva idea. In questo modo si codifica lo scopo del ruolo nell'applicazione. Quello che l'applicazione dovrebbe avere sono solo le autorizzazioni che agiscono come flag di funzionalità. Laddove i flag delle funzionalità sono resi accessibili dalla configurazione, le autorizzazioni sono rese accessibili dal contesto di sicurezza dell'utente derivato dalla raccolta DISTINCT di autorizzazioni raccolte da tutti i ruoli in cui è stato inserito l'utente. Questo è ciò che chiamo "autorizzazioni effettive". L'applicazione dovrebbe presentare solo un menudi possibili autorizzazioni per funzioni / azioni. Il sistema RBAC dovrebbe svolgere il compito di sposare tali autorizzazioni agli utenti attraverso i ruoli. In questo modo, non esiste una codifica rigida dei ruoli e l'unica volta in cui un'autorizzazione cambia è quando viene rimossa o se ne aggiunge una nuova. Una volta che un'Autorizzazione è stata aggiunta al software non dovrebbe mai essere cambiata. Dovrebbe essere rimosso solo quando necessario (cioè quando una funzione viene interrotta in una nuova versione) e solo quelle nuove possono essere aggiunte.

Un'ultima nota.

Grant vs Deny

Un robusto sistema RBAC e persino un sistema CBAC dovrebbero distinguere tra sovvenzioni e rifiuti.

L'aggiunta di un'autorizzazione a un ruolo dovrebbe avere una CONCESSIONE o un DENY. Quando le autorizzazioni sono selezionate, tutte le autorizzazioni concesse devono essere aggiunte all'elenco Utenti delle autorizzazioni effettive. Quindi, dopo tutto ciò, un elenco di autorizzazioni DENIED dovrebbe far sì che il sistema rimuova tali autorizzazioni dall'elenco delle autorizzazioni effettive.

Ciò consente agli amministratori di "modificare" le autorizzazioni finali di un soggetto. È meglio se le autorizzazioni possono anche essere aggiunte direttamente agli utenti. In questo modo, è possibile aggiungere un utente a un ruolo di manager e ottenere l'accesso a tutto, ma forse si desidera negare l'accesso al bagno della signora perché l'utente è un maschio. Quindi aggiungi l'Utente maschio al ruolo Manager e aggiungi un'Autorizzazione all'oggetto Utente con DENY in modo da rimuovere solo l'accesso alla stanza di quella Signora.

In realtà, questo sarebbe un buon candidato per un reclamo. Se l'utente ha un reclamo "gender = male", quindi essere nel ruolo di manager dà accesso a tutte le stanze ma il bagno della signora richiede anche il reclamo gender = female e il bagno degli uomini richiede il reclamo gender = male. In questo modo non si dovrebbe configurare un'autorizzazione DENY per gli utenti di sesso maschile poiché l'applicazione del reclamo si occupa di ciò per tutti con una singola regola di autorizzazione. Tuttavia, potrebbe essere fatto in entrambi i modi.

Il punto è che con DENIAL dei permessi semplifica la gestione dei ruoli perché possono essere implementate eccezioni.

Di seguito è riportato un diagramma che ho fatto molto tempo fa che mostra il modello RBAC. Non ho una grafica per i reclami, ma puoi immaginare che siano solo attributi associati agli Utenti ovunque si trovino. Inoltre, il diagramma non mostra i gruppi (a un certo punto devo aggiornarlo).

Spero che aiuti.

Questo è un diagramma dell'RBAC sopra descritto

Aggiornamento del 7 aprile 2019 In base al feedback di @Brent (grazie) ... rimosso i riferimenti non necessari alle risposte precedenti e spiegato la base originale della metafora del "night club" fornita da @CodingSoft al fine di rendere comprensibile questa risposta senza per leggere altre risposte.

Non sono pienamente d'accordo con la risposta di Emran

[Authorize(Roles="Sale")]

È ingenuo

La domanda è come

  [Authorize(Roles="CustomerCreator")]

è diverso da

 [ClaimAuthorize(Permission="CanCreateCustomer")]

Se entrambi sono ugualmente buoni, perché abbiamo bisogno di un reclamo?

Penso perché

Il concetto di reclami è più generico rispetto al ruolo

Nel contesto dell'esempio precedente possiamo dire che "CustomerCreator" è un'affermazione di tipo "ruolo" fornita da "Asp.NETroleProvider"

Ulteriori esempi di reclami.

1. "AAA" è un reclamo di tipo "MYExamSite.Score" fornito da "MYExamSite.com"

2. "Oro" è un reclamo di tipo "MYGYM.Membershiptype" fornito da "MYGYMApp"

La risposta accettata sembra posizionare i ruoli come oggetto contundente e i reclami come strumento flessibile, ma per il resto li fa sembrare quasi identici. Sfortunatamente, questo posizionamento fa un cattivo servizio al concetto di reclami e può fondamentalmente riflettere un leggero fraintendimento del loro scopo.

I ruoli esistono e hanno senso solo all'interno di un ambito implicito. Generalmente si tratta di un'applicazione o di un ambito organizzativo (ad es. Ruolo = Amministratore). I reclami, d'altra parte, possono essere "fatti" da chiunque. Ad esempio, l'autenticazione di Google può produrre reclami, inclusa la "email" di un utente, allegando tale email a un'identità. Google presenta il reclamo, l'applicazione sceglie se comprendere e accettare tale reclamo. L'applicazione stessa potrebbe successivamente allegare un reclamo chiamato "metodo di autenticazione" (come fa ASP.NET MVC Core Identity) con un valore di "Google". Ogni reclamo include un ambito in modo che sia possibile identificare se un reclamo ha un significato esternamente, localmente o entrambi (o più grana fine secondo necessità).

I punti chiave sono che tutte le affermazioni sono esplicitamente associate a un'identità e includono un ambito esplicito. Tali affermazioni possono ovviamente essere utilizzate per l'autorizzazione - e ASP.NET MVC fornisce supporto tramite l'attributo Autorizza, ma questo non è l'unico o necessariamente principale scopo delle richieste. Certamente non lo distingue dai ruoli, che possono essere utilizzati esattamente allo stesso modo per l'autorizzazione con ambito locale.

Pertanto, si può scegliere di utilizzare i ruoli, i reclami, o entrambi ai fini dell'autorizzazione e probabilmente non trovare alcun vantaggio o svantaggio inerente a entrambi, a condizione che tali ruoli e reclami siano localizzati nell'ambito. Ma se, ad esempio, l'autorizzazione dipende da rivendicazioni di identità esterne, i ruoli saranno inadeguati. Dovresti accettare il reclamo esterno e tradurlo in un ruolo con ambito locale. Non c'è necessariamente nulla di sbagliato in questo, ma introduce un livello di riferimento indiretto e scarta il contesto.

Più in generale, è necessario considerare il controllo degli accessi basato sugli attributi (ABAC). RBAC e ABAC sono entrambi concetti definiti da NIST, l'Istituto Nazionale di Standard e Tecnologia. CBAC, d'altra parte, è un modello spinto da Microsoft che è molto simile a ABAC.

Leggi di più qui:

• Pagina NIST per il controllo degli accessi in base al ruolo
• Controllo dell'accesso basato sugli attributi Pagina NIST di

Il fondamentale tra RBAC e CBAC è che:

RBAC : un utente deve essere assegnato a un ruolo per essere autorizzato ad eseguire un'azione.

CBAC : l'utente deve avere un reclamo con il valore corretto, come previsto dall'applicazione, per essere autorizzato. Il controllo degli accessi basato sui reclami è elegante da scrivere e più facile da mantenere.

Inoltre, i reclami vengono inviati all'applicazione da un servizio di rilascio dell'autorizzazione (token di servizio di sicurezza STS) considerato attendibile dall'applicazione (Relying Party)

Il ruolo è solo un tipo di reclamo. In questo modo, ci possono essere molti altri tipi di reclami, ad esempio il nome utente è uno dei tipi di reclamo

È importante analizzare innanzitutto per cosa è necessaria l'autenticazione prima di decidere quale sia il metodo migliore. Dalla documentazione Microsoft di seguito, si afferma che "Un reclamo non è ciò che il soggetto può fare. Ad esempio, potresti avere una patente di guida, rilasciata da un'autorità locale di patente di guida. La patente di guida ha la tua data di nascita su di essa. In questo caso il nome del reclamo sarebbe DateOfBirth, il valore del reclamo sarebbe la tua data di nascita, ad esempio l'8 giugno 1970 e l'emittente sarebbe l'autorità della patente di guida. L'autorizzazione basata sui reclami, nella sua forma più semplice, controlla il valore di un reclamo e consente l'accesso a una risorsa basata su quel valore. Ad esempio, se si desidera accedere a un night club, il processo di autorizzazione potrebbe essere: 6 "

Da questo esempio possiamo vedere che l'accesso a un night club con un'autorizzazione basata sui reclami è diverso dal tipo di autorizzazione che sarà richiesto dal personale che lavora nel night club, in questo caso il personale del night club richiederà un'autorizzazione basata sul ruolo che non è richiesta per i visitatori del night club poiché i visitatori del night club hanno tutti uno scopo comune nel night club, pertanto in questa situazione un'autorizzazione basata sui reclami è adatta per i visitatori del night club.

Autorizzazione basata sul ruolo https://docs.microsoft.com/en-us/aspnet/core/security/authorization/roles 14/10/2016 Quando viene creata un'identità, può appartenere a uno o più ruoli. Ad esempio, Tracy può appartenere ai ruoli di amministratore e utente mentre Scott può appartenere solo al ruolo di utente. La modalità di creazione e gestione di questi ruoli dipende dall'archivio di backup del processo di autorizzazione. I ruoli sono esposti allo sviluppatore tramite il metodo IsInRole sulla classe ClaimsPrincipal.

Autorizzazione basata sui reclami https://docs.microsoft.com/en-us/aspnet/core/security/authorization/claims 14/10/2016 Quando viene creata un'identità, può essere assegnato uno o più reclami emessi da una parte fidata. Un'affermazione è una coppia nome-valore che rappresenta ciò che l'oggetto è, non ciò che l'oggetto può fare. Ad esempio, potresti avere una patente di guida, rilasciata da un'autorità locale di patente di guida. La patente di guida ha la tua data di nascita. In questo caso il nome del reclamo sarebbe DateOfBirth, il valore del reclamo sarebbe la tua data di nascita, ad esempio l'8 giugno 1970 e l'emittente sarebbe l'autorità della patente di guida. L'autorizzazione basata sui reclami, nella sua forma più semplice, controlla il valore di un reclamo e consente l'accesso a una risorsa in base a tale valore. Ad esempio, se si desidera accedere a un night club, il processo di autorizzazione potrebbe essere:

L'addetto alla sicurezza della porta valuterà il valore della data del reclamo di nascita e se si fida dell'emittente (l'autorità della patente di guida) prima di concederti l'accesso.

Un'identità può contenere più attestazioni con più valori e può contenere più attestazioni dello stesso tipo.

È anche possibile gestire i ruoli in modo sinistri.

Invece di creare ruoli di autorizzazione che riflettono un ruolo aziendale, creare ruoli che riflettano ruoli di azione, ad esempio Crea cliente, Modifica cliente, Elimina cliente. Annota i metodi come richiesto.

Non è semplice mappare gli individui a una serie di ruoli di azione, specialmente quando l'elenco dei ruoli diventa più grande. Pertanto, dovrai gestire i ruoli aziendali a un livello di granularità inferiore (ad es. Vendite, Marketing) e mappare il ruolo aziendale ai ruoli di azione richiesti. Vale a dire, aggiungere un utente a un ruolo aziendale e li mappa ai ruoli (azione) richiesti nella tabella di autorizzazione esistente.

È anche possibile ignorare il ruolo aziendale e aggiungere direttamente una persona a un ruolo d'azione.

Poiché si basa su ciò che già funziona, non si annulla il processo di autorizzazione esistente. Sono necessarie solo alcune altre tabelle per implementare questo approccio

Penso che a questa domanda si possa rispondere dal potenziale database. se hai notato come le tabelle coinvolte in questo impianto troverai quanto segue

1. AspNetUsers: ogni utente ha una riga con tutti gli attributi richiesti da tutti gli utenti come e-mail, indirizzo telefono, password .....
2. AspNetRoles; definisce ruoli diversi in base ai requisiti dell'applicazione come GM, CTO, HRM, ADMIN, EMP. ciò che ogni ruolo definisce è secondo le esigenze dell'applicazione.
3. AspNetUserRoles: ogni riga collega AspNetUser e AspNetRoles e collega in modo efficace tra un utente e molti ruoli.
4. AspNetUserClaims: ogni riga ha una chiave per AspNetUsers e un tipo e valore. in modo efficace aggiungere un attributo per ogni utente che potrebbe essere aggiunto / rimosso in fase di esecuzione.

L'utilizzo di queste tabelle potrebbe essere modificato in un momento della vita dell'utente / dell'applicazione per soddisfare esigenze specifiche.

Consideriamo la fase iniziale di "Responsabile acquisti" (PM), potremmo avere tre approcci

1. L'applicazione popola AspNetUserRoles con una riga per garantire 'PM' diritto all'acquisto. Per emettere un ordine di acquisto con qualsiasi importo, l'utente deve solo il ruolo "PM".

2. L'applicazione popola AspNetUserRoles con una riga per concedere il diritto di acquisto 'PM' e popola AspNetUser. Reclama un reclamo del tipo "Quantità di acquisto" e il valore "<1000" per impostare il limite di importo. Per emettere un ordine d'acquisto, l'utente deve avere "PM" e l'importo dell'ordine deve essere inferiore al valore del reclamo TIPO "Importo d'acquisto".

3. Applicazione popola AspNetUserClaims con rivendicazione del tipo 'Tipo di acquisto' e del valore "<1000". Qualsiasi utente può emettere un ordine d'acquisto, dato che l'importo è inferiore al valore di rivendicazione del tipo di reclamo "Importo di acquisto" per questo utente.

Come si può notare, la base di ruoli è grossolana di diritti rigidi che semplificherebbero la vita dell'utente dell'applicazione dal punto di vista della gestione del sistema. tuttavia limiterà le capacità dell'utente dal punto di vista dei requisiti aziendali. D'altra parte, la rivendicazione basata su diritti molto fini che devono essere assegnati a ciascun utente. basato sulle richieste spingerà anche l'azienda al limite, tuttavia renderà la gestione del sistema molto complessa.

Controllo degli accessi in base al ruolo (RBAC)

Nella tua organizzazione, potresti avere i seguenti ruoli

Dipendente

Manager

HR

A seconda del ruolo o dei ruoli a cui appartiene l'utente che ha effettuato l'accesso, è possibile o meno autorizzare l'accesso a determinate risorse nell'applicazione. Dal momento che stiamo usando i ruoli per effettuare controlli di autorizzazione, questo è comunemente chiamato controllo di accesso basato sui ruoli (RBAC) o autorizzazione basata sui ruoli.

In ASP.NET Core per implementare l'autorizzazione basata sui ruoli, utilizziamo l'attributo Autorizza con parametro Ruoli.

[Authorize(Roles = "Admin")]
public class AdministrationController : Controller
{
}

Claims Based Access Control (CBAC)

CHE COSA è il reclamo? Un'affermazione è una coppia nome-valore. È davvero un'informazione sull'utente, non ciò che l'utente può e non può fare. Ad esempio nome utente, e-mail, età, genere ecc. Sono tutti reclami. Il modo in cui utilizzi questi reclami per i controlli di autorizzazione nella tua applicazione dipende dai requisiti di business e di autorizzazione della tua applicazione.

Ad esempio, se si sta creando un portale per i dipendenti, è possibile consentire all'utente che ha effettuato l'accesso di richiedere un congedo di maternità se il valore della domanda di genere è di sesso femminile. Allo stesso modo, se stai creando un'applicazione di e-commerce, puoi consentire all'utente che ha effettuato l'accesso di inviare un ordine se il valore della richiesta di età è maggiore o uguale a 18.

I reclami sono basati su criteri. Creiamo una politica e includiamo una o più richieste in tale politica. La politica viene quindi utilizzata insieme al parametro della politica dell'attributo Autorizza per implementare l'autorizzazione basata sulle attestazioni.

[Authorize(Policy = "DeleteRolePolicy")]
public async Task<IActionResult> DeleteRole(string id)
{
}