Spesso, durante lo sviluppo del nostro sito web ASP.NET Core, o del nostro progetto Web API, abbiamo la necessità di impostare un utente fittizio per ragioni di test. Solitamente questo accade quando lo stack di autenticazione è ancora da sviluppare o da integrare, ma comunque vogliamo verificare che la logica di autorizzazione che regola l'accesso ai nostri controller sia corretta.
Il modo migliore per farlo è creare un ClaimsPrincipal durante le fasi iniziali della richiesta, così che il resto della logica possa rimanere invariata. Un custom middleware da configurare nella classe Startup, pertanto, è esattamente ciò che fa al caso nostro:
public void Configure(IApplicationBuilder app, IHostingEnvironment env) { if (env.IsDevelopment()) { app.UseDeveloperExceptionPage(); app.UseDatabaseErrorPage(); app.Use(async (context, next) => { var claims = new List<Claim>() { new Claim(ClaimTypes.Name, "testUser"), new Claim(ClaimTypes.Role, "Admin") }; var scheme = IdentityConstants.ApplicationScheme; var identity = new ClaimsIdentity(claims, scheme); var principal = new ClaimsPrincipal(identity); context.User = principal; await next(); }); } // .. altro codice qui .. }
Il codice in alto è abbastanza intuitivo. Innanzi tutto, è importante segnalare come il codice venga eseguito solo quando si è in modalità "Development", così che non rischiamo di lasciare aperto un evidente buco di sicurezza una volta che l'applicazione sia stata rilasciata.
Il nostro middleware costruisce innanzi tutto una collezione di Claim per l'utente. Nell'esempio in alto abbiamo impostato Name e Role, ma ovviamente possiamo personalizzare questa collection a piacimento, così da poter testare scenari autorizzativi più complessi.
Il passo successivo è costruire un oggetto ClaimsIdentity. Qui l'aspetto importante da specificare è lo schema di autenticazione. ASP.NET Core, infatti, supporta diversi schema (https://docs.microsoft.com/en-us/aspnet/core/security/authorization/limitingidentitybyscheme), per gestire diverse tecniche di autenticazione contemporaneamente ed è importante che questa variabile sia la medesima della tecnologia che andremo a usare.
Per esempio, nel caso di ASP.NET Identity, lo schema è IdentityConstants.ApplicationScheme, mentre se stessimo usando autenticazione basata su Jwt Token in Web API, avremmo dovuto usare
JwtBearerDefaults.AuthenticationScheme
A questo punto non dobbiamo far altro che costruire il ClaimsPrincipal a partire dall'identity appena creata e impostarlo come utente corrente nel context della richiesta, per poi invocare il prossimo middleware e proseguire l'elaborazione della richiesta.
Commenti
Per inserire un commento, devi avere un account.
Fai il login e torna a questa pagina, oppure registrati alla nostra community.
Approfondimenti
Creare agenti facilmente con Azure AI Agent Service
Persistere la ChatHistory di Semantic Kernel in ASP.NET Core Web API per GPT
Utilizzare WhenEach per processare i risultati di una lista di task
Recuperare l'ultima versione di una release di GitHub
Aggiornare a .NET 9 su Azure App Service
Utilizzare il metodo Index di LINQ per scorrere una lista sapendo anche l'indice dell'elemento
Garantire la provenienza e l'integrità degli artefatti prodotti su GitHub
Disabilitare le run concorrenti di una pipeline di Azure DevOps
Esporre i propri servizi applicativi con Semantic Kernel e ASP.NET Web API
Path addizionali per gli asset in ASP.NET Core MVC
Documentare i servizi REST con Swagger e OpenAPI con .NET 9
Recuperare automaticamente un utente e aggiungerlo ad un gruppo di Azure DevOps