14 messaggi dal 14 marzo 2019
Ciao a tutti,

sto cercando di configurare una web app che abbia la gestione del login interamente demandata ad Azure Active Directory, in pratica non voglio avere un DB per gestire gli utenti, ma voglio che se ne occupi l'app AD in Azure.

Allo stato attuale sono riuscito a creare dei gruppi, come spiegato qui, e ad assegnare dei ruoli attraverso il manifest della mia app Azure AD, come spiegato qui. Gli utenti si riescono a loggare, e ad ora non è stato necessario creare alcun DB per gestirli.

Quello che vorrei aggiungere è una gestione CRUD, che mi permetta di abilitare un utente appartenente ad un determinato gruppo, ed avente un determinato ruolo, alle funzioni di create, read update o delete.

Come posso fare? devo sfruttare i gruppi per la gestione del CRUD, o i ruoli? Voi come fareste?
Da quanto riportato qui sembra che nei "Claim", oltre al ruolo, sia possibile recuperare il gruppo di appartenenza di un utente.
Potrei anche gestire il tutto attraverso delle policy, ma ciò che non mi è chiaro è come assegnare il CRUD ad un determinato utente.

Grazie
14 messaggi dal 14 marzo 2019
Ciao a tutti,

stavo leggendo questo articolo che descrive la fase di "Authorization" basata sulle policy, ma quello che non mi è chiaro è nel paragrafo intitolato "What's a Policy, Anyway?", in particolare da dove recupera i claim "editor" e "contents". Infatti nella guida non mostra come li setta.

Questo il punto:

var policy = new AuthorizationPolicyBuilder()
  .AddAuthenticationSchemes("Cookie, Bearer")
  .RequireAuthenticatedUser()
  .RequireRole("Admin")
  .RequireClaim("editor", "contents")  .RequireClaim("level", "senior")
  .Build();


La mia domanda rimane comunque quella del post in apertura della discussione: come fare una gestione CRUD?

Grazie
11.886 messaggi dal 09 febbraio 2002
Contributi
Ciao,
non ho ben capito che granularità vuoi ottenere: un utente che è abilitato a fare CRUD lo può fare su tutte le entità? Oppure solo su alcuni tipi da te concessi (es. su Prodotti ma non su Categorie)? Oppure vuoi affinare ulteriormente e concedere lettura e/o inserimento e/o modifica e/o eliminazione per ogni singolo tipo di entità?

Potresti crearti un claim personalizzato chiamato "Privilege" e concedere più istanze ai tuoi utenti. Per esempio all'utente Mario potresti dare:
Privilege: Product.CanRead
Privilege: Product.CanInsert
Privilege: Product.CanUpdate
Privilege: Product.CanDelete
Privilege: Category.CanRead
Privilege: Orders.CanRead
Privilege: Orders.CanInsert


Poi nella tua applicazione autorizzi l'esecuzione dell'action solo in presenza del relativo claim.
Questo ti permetterebbe di conferire dei privilegi in maniera molto granulare e di personalizzarli per il singolo utente.

Se non hai bisogno di tutta questa precisione, puoi definire dei ruoli e assegnare un utente a ciascun ruolo.

ciao,
Moreno

Enjoy learning and just keep making
14 messaggi dal 14 marzo 2019
Ciao Moreno,

grazie per la risposta.

Al momento ho creato due gruppi lato Azure, che ho chiamato "TestApp-Admin" e "TestApp-StandardUser", all'interno di questi gruppi ho inserito delle persone con ruolo di "Admin" e "StandardUser".
Anche se ridondanti, ho necessità di creare i due gruppi perché la gestione dell'aggiunta/rimozione delle persone sarà delegata a terzi con permessi di accesso limitati alla sottoscrizione Azure.

Ora, quello che vorrei fare è permettere sia agli "Admin" che agli "StandardUser" di vedere una determinata "View", ma solo agli "Admin" far comparire il bottone "Modifica" di un form.
Agendo solo sui ruoli, come spiegato nella guida che hai realizzato, attraverso l'uso degli attributi "Authorize" sui controller, filtrando per ruolo, escluderei un intero ruolo:

[Authorize(Roles = "StandardUser")]

Ho pensato quindi che la via migliore per ottenere questo comportamento è con l'uso delle "Policy", ma leggendo questo articolo non capisco su che base aggiunge i "Claim" alle singole persone. Io non voglio avere un DB per la gestione degli utenti, ma voglio delegare l'intera gestione ad Azure, quindi come recupero un "Claim" che non ho assegnato da nessuna parte?
Lato Azure come posso assegnare Claim aggiuntivi?


Per i ruoli è stato possibile definirli lato Azure nell'app AD, dal "manifest" come spiegato qui. L'app AD l'ho realizzata come spiegato in questo thread.

Come posso fare? Perdonami, ma sono un newbie nell'uso di AD

Grazie

---
Aggiornamento

Sto dando uno sguardo a questo progetto ed in particolare al suo readme, dove spiegano come aggiungere i Claim con i dettagli del gruppo di appartenenza modificando il "manifest" dell'app AD.
Non è proprio quello che voglio, ma ciò sembra dimostrare che via manifest è possibile agire sui Claim.



Modificato da mee il 16 aprile 2019 17:22 -
Modificato da mee il 16 aprile 2019 17:22 -
14 messaggi dal 14 marzo 2019
Ciao Moreno,

sto cercando di seguire le tue indicazioni, ed ho trovato una guida su "Microsoft Docs" che spiega come configurare una classe "Operations" contenente i CRUD, inoltre consigliano di configurare un "AuthorizationHandler" personalizzato da istanziare attraverso la classe "Startup.cs", qui la guida.

In particolare, a causa della mia scarsa conoscienza di Active Directory, non mi è chiaro dove viene settato il valore di "requirement.Name", quindi chi lo passa al mio "AuthorizationHandler"? Non ho questo valore nei Claim.

public class DocumentAuthorizationCrudHandler :
    AuthorizationHandler<OperationAuthorizationRequirement, Document>
{
    protected override Task HandleRequirementAsync(AuthorizationHandlerContext context,
                                                   OperationAuthorizationRequirement requirement,
                                                   Document resource)
    {
        if (context.User.Identity?.Name == resource.Author &&
            requirement.Name == Operations.Read.Name)
        {
            context.Succeed(requirement);
        }

        return Task.CompletedTask;
    }
}


Pensi questa possa essere la cosa corretta da fare?

Grazie

Torna al forum | Feed RSS

ASPItalia.com non è responsabile per il contenuto dei messaggi presenti su questo servizio, non avendo nessun controllo sui messaggi postati nei propri forum, che rappresentano l'espressione del pensiero degli autori.