Best practice per ruoli e attestazioni in ASP.NET Identity


94

Sono completamente nuovo nell'uso di claimsin ASP.NETIdentitye voglio avere un'idea delle migliori pratiche nell'uso di Roles and/or Claims.

Dopo tutta questa lettura, ho ancora domande come ...

D: Non utilizziamo più i ruoli?
D: In tal caso, perché vengono ancora offerti i ruoli?
D: Dobbiamo usare solo Claims?
D: Dobbiamo utilizzare Ruoli e rivendicazioni insieme?

Il mio pensiero iniziale è che "dovremmo" usarli insieme. Vedo Claimscome sottocategorie quelle Rolesche supportano.

PER ESEMPIO:
Ruolo:
Affermazioni contabili : CanUpdateLedger, CanOnlyReadLedger, CanDeleteFromLedger

D: Devono escludersi a vicenda?
D: O è meglio andare SOLO ai reclami e "qualificare pienamente" i tuoi reclami?
D: Quindi quali sono le migliori pratiche qui?

ESEMPIO: Utilizzo di ruoli e attestazioni insieme
Ovviamente, dovresti scrivere la tua logica degli attributi per questo ...

[Authorize(Roles="Accounting")]
[ClaimAuthorize(Permission="CanUpdateLedger")]
public ActionResult CreateAsset(Asset entity)
{
    // Do stuff here

    return View();
}

ESEMPIO: qualificazione completa delle tue richieste

[ClaimAuthorize(Permission="Accounting.Ledger.CanUpdate")]
public ActionResult CreateAsset(Asset entity)
{
    // Do stuff here

    return View();
}

1
Quindi, sto affrontando lo stesso problema ora, come lo risolvi e come puoi subRuolo il permesso nell'applicazione?
Loai

Risposte:


77

Un ruolo è una categoria simbolica che raccoglie gli utenti che condividono gli stessi livelli di privilegi di sicurezza. L'autorizzazione basata sui ruoli richiede prima l'identificazione dell'utente, quindi l'accertamento dei ruoli a cui è assegnato l'utente e infine il confronto di tali ruoli con i ruoli autorizzati ad accedere a una risorsa.

Al contrario, un'affermazione non è basata sul gruppo, piuttosto è basata sull'identità.

dalla documentazione Microsoft :

Quando viene creata un'identità, possono essere assegnate una o più attestazioni emesse da una parte attendibile. Un'attestazione è una coppia di valori nome che rappresenta ciò che è l'oggetto, non ciò che può fare il soggetto.

Un controllo di sicurezza può successivamente determinare il diritto di accedere a una risorsa in base al valore di una o più attestazioni.

È possibile utilizzare sia in concerto, o utilizzare un tipo in alcune situazioni e l'altro in altre situazioni. Dipende principalmente dall'interazione con altri sistemi e dalla tua strategia di gestione. Ad esempio, potrebbe essere più facile per un manager gestire un elenco di utenti assegnati a un ruolo piuttosto che gestire chi ha una specifica rivendicazione assegnata. Le attestazioni possono essere molto utili in uno scenario RESTful in cui è possibile assegnare un'attestazione a un client e il client può quindi presentare la richiesta di autorizzazione anziché passare il nome utente e la password per ogni richiesta.


6
Non credo che questo sia del tutto esatto. Credo che le affermazioni indichino l'identità, non l'autorizzazione. Ciò che sono autorizzati a fare viene gestito separatamente. Cioè, potrebbero avere un reclamo con la data di nascita che indica che hanno più di 18 anni. Questo reclamo verrebbe trasmesso a un gestore delle autorizzazioni che potrebbe contenere una regola che dice "se hanno più di 18 anni, possono modificare la risorsa X", ma l'affermazione in sé non indica cosa possono / non possono fare o accedere. Lo stesso vale per i ruoli e altre affermazioni. Le affermazioni indicano chi sei e sono utilizzate per determinare cosa puoi fare, ma non te lo dicono direttamente
ChrisC

La documentazione di supporto per @ChrisC proviene dall'autorizzazione basata su attestazioni di Microsoft in ASP.NET Core : " Un'attestazione è una coppia di valori nome che rappresenta ciò che è l'oggetto, non ciò che può fare il soggetto."
DrGriff

@DrGriff Grazie per aver fornito il collegamento; Mi chiedevo da tempo l'accuratezza della descrizione che avevo dato; Penso di aver chiarito la risposta sulla base di quel collegamento ora.
Claies

29

Come ha spiegato perfettamente @Claies, le affermazioni potrebbero essere più descrittive ed è un tipo profondo di ruolo. Penso a loro come ai tuoi ruoli. Ho un ID palestra, quindi appartengo al ruolo di membri. Sono anche nelle lezioni di kickboxing, quindi ho una richiesta di id di kickboxing per loro. La mia domanda richiederebbe la dichiarazione di un nuovo ruolo per soddisfare i miei diritti di membro. Invece, ho gli ID per ogni classe di gruppo a cui appartengo, invece di molti nuovi tipi di appartenenza. Ecco perché le affermazioni si adattano meglio a me.

C'è un ottimo video esplicativo di Barry Dorrans, che parla del vantaggio di utilizzare le rivendicazioni sui ruoli. Afferma inoltre che i ruoli sono ancora in .NET per compatibilità con le versioni precedenti. Il video è molto informativo sul modo in cui funzionano reclami, ruoli, norme, autorizzazione e autenticazione.

Puoi trovarlo qui: ASP.NET Core Authorization with Barr Dorrans


8

Avendo utilizzato varie tecniche di autenticazione e autorizzazione per decenni, la mia attuale applicazione MVC utilizza la seguente metodologia.

Le attestazioni vengono utilizzate per tutte le autorizzazioni. Agli utenti viene assegnato un ruolo (sono possibili più ruoli ma non ne ho bisogno) - ulteriori informazioni di seguito.

Come è prassi comune, viene utilizzata la classe di attributi A ClaimsAuthorize. Poiché la maggior parte delle azioni del controller sono CRUD, ho una routine nella generazione del database code-first che itera tutte le azioni del controller e crea tipi di attestazioni per ogni attributo di azione del controller di Lettura / Modifica / Crea / Elimina. Ad esempio da,

[ClaimsAuthorize("SomeController", "Edit")]
[HttpPost]

Per l'uso in una vista MVC, una classe controller di base presenta gli elementi del carrello di visualizzazione

        protected override void OnActionExecuting(ActionExecutingContext filterContext)
        {
            // get user claims
            var user = filterContext.HttpContext.User as System.Security.Claims.ClaimsPrincipal;

            if (user != null)
            {
                // Get all user claims on this controller. In this controler base class, [this] still gets the descendant instance type, hence name
                List<Claim> claims = user.Claims.Where(c => c.Type == this.GetType().Name).ToList();

                // set Viewbag with default authorisations on this controller
                ViewBag.ClaimRead = claims.Any(c => c.Value == "Read");
                ViewBag.ClaimEdit = claims.Any(c => c.Value == "Edit");
                ViewBag.ClaimCreate = claims.Any(c => c.Value == "Create");
                ViewBag.ClaimDelete = claims.Any(c => c.Value == "Delete");
            }

            base.OnActionExecuting(filterContext);
        }

Per i menu del sito Web e altre azioni non del controller, ho altre affermazioni. Ad esempio, se un utente può visualizzare un particolare campo monetario.

bool UserHasSpecificClaim(string claimType, string claimValue)
{
    // get user claims
    var user = this.HttpContext.User as System.Security.Claims.ClaimsPrincipal;

    if (user != null)
    {
        // Get the specific claim if any
        return user.Claims.Any(c => c.Type == claimType && c.Value == claimValue);
    }

    return false;
}

public bool UserHasTradePricesReadClaim
{
    get
    {
        return UserHasSpecificClaim("TradePrices", "Read");
    }
}

Allora dove si inseriscono i ruoli?

Ho una tabella che collega un ruolo a una serie di attestazioni (predefinita). Quando si imposta l'autorizzazione utente, l'impostazione predefinita è fornire all'utente le rivendicazioni del proprio ruolo. Ogni utente può avere più o meno attestazioni rispetto all'impostazione predefinita. Per semplificare la modifica, l'elenco delle rivendicazioni viene visualizzato dal controller e dalle azioni (di seguito), con altre rivendicazioni elencate. I pulsanti vengono utilizzati con un po 'di Javascript per selezionare una serie di azioni per ridurre al minimo il "clic" richiesto per selezionare le rivendicazioni. Su Salva, le rivendicazioni degli utenti vengono eliminate e tutte le rivendicazioni selezionate vengono aggiunte. L'applicazione Web carica le attestazioni solo una volta, quindi qualsiasi modifica deve richiedere un ricaricamento all'interno di questi dati statici.

I gestori possono quindi selezionare quali attestazioni si trovano in ogni ruolo e quali attestazioni dispone di un utente dopo averli impostati su un ruolo e su tali attestazioni predefinite. Il sistema ha solo un numero limitato di utenti, quindi la gestione di questi dati è semplice


3

Per comprendere la differenza tra ruoli e affermazioni, devi affrontare la limitazione dei ruoli e sentire come le affermazioni derivano da questi problemi, quindi ti consiglio di darti 2 scenari per riconoscere il potere delle affermazioni in cui il ruolo non può risolvere questi problemi:

1- il tuo sito deve avere due moduli (pagine, servizio ..etc) il primo modulo per i bambini (sotto i 18 anni) l'altro per gli adulti (sopra i 18 anni) la tua identità utente ha rivendicazione della data di nascita

è necessario creare una politica su questo reclamo in modo che l'autorizzazione per ciascun modulo venga data su questo valore e se l'età dell'utente supera i 18 anni, può passare al modulo per adulti e non prima di questa età

Il ruolo è il tipo di dati booleano che puoi avere o meno il ruolo del ruolo non aveva valori maltati

2- il tuo sito ha il ruolo di utente e non vuoi impedire l'accesso degli utenti per effettuare alcune operazioni di manutenzione senza modificare il codice

nelle attestazioni è possibile creare criteri UnderConstrain che, se il vero utente non può visualizzare la pagina, concedere l'autorizzazione alla proprietà per il ruolo utente.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.