Dovrebbe essere un reclamo, un ruolo o una politica?

Question

Dovrebbe essere un reclamo, un ruolo o una politica?

#1 da (2 voti)
#2 da (0 voti)
#3 da (0 voti)

1

La distinzione tra ruoli e attestazioni è che i ruoli descrivono un insieme di utenti e le attestazioni descrivono una proprietà di un utente. Quindi può esserci un ruolo "Amministratore", ma può anche esserci un reclamo "HasElevatedPrivilegeBadge". Entrambi possono consentire la stessa azione. Ora quale devo scegliere se voglio consentire solo a certe persone di fare certe cose, ad esempio:

CanAddItem, CanUpdateItem, CanDeleteItem,
CanAddProduct, CanUpdateProduct, CanDeleteProduct

Potrei creare un ruolo "Amministratore" e aggiungere ad esso "CanAddItem", "CanUpdateItem", ecc., ma "CanAddItem" non descrive una proprietà di un utente. Dice ciò che l'utente può fare, che non è quello che dovrebbe fare un reclamo, dovrebbe?

Un altro approccio è quello di creare criteri, come ad esempio:

policy.AddPolicy("CanAddItem", policy => {
    policy.RequireAuthenticatedUser()
          .RequireRole("Administrator");
});

Ma per più di 20 criteri, ci vorrà una buona parte della mia classe Startup . C'è un altro modo per farlo, o è uno di questi il preferito?

Vorrei sottolineare che sono specificamente alla ricerca di una soluzione per .Net Core Identity. Sto chiedendo una soluzione su come adattare il mio requisito alle tabelle di identità fornite dal framework.

c# authorization asp.net-core razor .net-core

posta FCin 25.09.2018 - 09:04

fonte

3 risposte

Leggi altre domande sui tag c# authorization asp.net-core razor .net-core

Rileva le catene di inclusione di intestazione e le dipendenze in C ++ Formazione distribuita di molti piccoli modelli ML

score 2 · Answer 1

In sostanza, stai descrivendo una mappatura di Ruolo all'autorizzazione.

Penso che questo sia praticamente coperto dallo standard [Authorize (Role = xxx)] sulle azioni del controller, in cui l'autorizzazione implicita è CanExecuteThisAction. Non c'è bisogno di politiche aggiuntive in quanto agiscono semplicemente come una mappatura, potenzialmente confondendo il problema e, come dici tu, aggiungendo un sacco di codice boilerplate.

Le policy sembrano mirate a permessi più complicati, in cui è necessario eseguire qualche logica contro le attestazioni o altre proprietà dell'utente, ad esempio la politica AtLeast21 in cui gli utenti dichiarano di essere una data di nascita.

Direi che sostituire le classi AuthorizeAttribute personalizzate.

Non li userei quando l'attributo di autorizzazione predefinito può gestirlo da solo, come nel caso del controllo dei ruoli.

score 0 · Answer 2

In genere optiamo per le politiche poiché consentono un controllo granulare ed espressivo sull'autorizzazione. Per risolvere il problema su di loro occupando spazio nella classe Startup, è possibile suddividere le policy in una classe statica.

internal static class Policies
{
  public static void CanAddItem(AuthorizationPolicyBuilder policy)
  {
    policy.RequireAuthenticatedUser()
      .RequireRole("Administrator");
  }
}

E quindi in Startup.cs la registrazione di ogni criterio è un one-liner

services.AddAuthorization(options =>
{
  options.AddPolicy(nameof(Policies.CanAddItem), Policies.CanAddItem);
});

Se avevi bisogno di un controllo ancora maggiore, potresti prendere in considerazione l'aggiunta in un IAuthorizationPolicyProvider personalizzato che ti consente di risolvere in modo programmatico le norme.

link

score 0 · Answer 3

Dichiarazione di non responsabilità: non ho mai usato politiche prima. Penso che la risposta al tuo problema dipenda anche dal provider di identità che stai utilizzando. se il provider di identità non è la propria applicazione ma un provider di identità di terze parti O un prodotto standardizzato come server di identità 4, l'utilizzo di ruoli e attestazioni sarebbe migliore, poiché OAUTH / openidconnect può funzionare con ruoli / rivendicazioni nativley.

Usiamo uno schema come il tuo schema, ma lievi colpi di scena: 1. Abbiamo diversi ruoli, ad es. un amministratore, itemManager e un utente. 2. Abbiamo reclami come "item.add", "item.delete", "item.create" 3. Ogni ruolo può avere rivendicazioni N 4. Ogni utente può avere N ruoli Ciò consente molta componibilità, ad es. un utente può ottenere il reclamo "item.delete" a causa del fatto che è un amministratore o perché è un itemManager.

È importante che i nomi dei reclami debbano essere un po 'standardizzati e che la loro granularità sia appropriata per la tua applicazione - ad esempio se il diritto di creare un elemento e di aggiornarlo sono collegati logicamente, crea solo un reclamo, non due.

Inoltre, puoi utilizzare i ruoli per inserire un po 'di logica aziendale, come product.maxnumber.200 = > l'utente può avere solo fino a 200 prodotti, che devono essere convalidati dalla logica aziendale.

Infine, diversi addetti alla sicurezza che ho letto negli ultimi mesi (OWASP) hanno raccomandato di mettere l'autorizzazione accanto alla tua logica di business a causa del fatto che spesso la domanda "l'utente può farlo?" è necessario trovare una risposta nel contesto della logica aziendale: "l'utente ha i ruoli product.add E ha meno di product.maxnumber prodotti?" - > un tale contesto è facile da ottenere in una richiesta particolare, ma è difficile rispondere in generale, come nelle politiche.