Eseguire la migrazione di un'API Web basata su OWIN a b2clogin.com o a un dominio personalizzato

Articolo
01/11/2024

Questo articolo descrive una tecnica per abilitare il supporto per più autorità di certificazione token nelle API Web che implementano l'interfaccia Web open per .NET (OWIN). Il supporto di più endpoint token è utile quando si esegue la migrazione delle API B2C (Azure AD B2C) di Azure Active Directory e delle relative applicazioni da un dominio a un altro. Ad esempio, da login.microsoftonline.com a b2clogin.com o a un dominio personalizzato.

Aggiungendo il supporto nell'API per accettare i token rilasciati da b2clogin.com, login.microsoftonline.com o un dominio personalizzato, è possibile eseguire la migrazione delle applicazioni Web in modo a fasi prima di rimuovere il supporto per i token login.microsoftonline.com rilasciati dall'API.

Le sezioni seguenti presentano un esempio di come abilitare più emittenti in un'API Web che usa i componenti middleware Microsoft OWIN (Katana). Anche se gli esempi di codice sono specifici del middleware Microsoft OWIN, la tecnica generale deve essere applicabile ad altre librerie OWIN.

Prerequisiti

Sono necessarie le risorse B2C di Azure AD seguenti prima di continuare con i passaggi descritti in questo articolo:

Flussi utente o criteri personalizzati creati nel tenant

Ottenere gli endpoint dell'autorità di certificazione del token

Per prima cosa è necessario ottenere gli URI dell'endpoint dell'autorità di certificazione token per ogni autorità di certificazione che si vuole supportare nell'API. Per ottenere gli endpoint di b2clogin.com e login.microsoftonline.com supportati dal tenant di Azure AD B2C, usare la procedura seguente nella portale di Azure.

Iniziare selezionando uno dei flussi utente esistenti:

Passare al tenant di Azure AD B2C nel portale di Azure
In Criteri selezionare Flussi utente (criteri)
Selezionare un criterio esistente, ad esempio B2C_1_signupsignin1, quindi selezionare Esegui flusso utente
Nell'intestazione Esegui flusso utente nella parte superiore della pagina selezionare il collegamento ipertestuale per passare all'endpoint di individuazione OpenID Connect per tale flusso utente.
Nella pagina visualizzata nel browser registrare il valore di issuer, ad esempio:

https://your-b2c-tenant.b2clogin.com/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/v2.0/
Usare l'elenco a discesa Seleziona dominio per selezionare l'altro dominio, quindi eseguire nuovamente i due passaggi precedenti e registrarne il issuer valore.

È ora necessario registrare due URI simili a:

https://login.microsoftonline.com/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/v2.0/
https://your-b2c-tenant.b2clogin.com/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/v2.0/

Criteri personalizzati

Se sono presenti criteri personalizzati anziché flussi utente, è possibile usare un processo simile per ottenere gli URI dell'autorità di certificazione.

Passare al tenant di Azure AD B2C
Selezionare Identity Experience Framework
Selezionare uno dei criteri di relying party, ad esempio B2C_1A_signup_signin
Usare l'elenco a discesa Seleziona dominio per selezionare un dominio, ad esempio yourtenant.b2clogin.com
Selezionare il collegamento ipertestuale visualizzato in OpenID Connect discovery endpoint
Registrare il issuer valore
Eseguire i passaggi 4-6 per l'altro dominio, ad esempio login.microsoftonline.com

Scaricare il codice di esempio

Dopo aver ottenuto entrambi gli URI dell'endpoint token, è necessario aggiornare il codice per specificare che entrambi gli endpoint sono autorità di certificazione valide. Per esaminare un esempio, scaricare o clonare l'applicazione di esempio, aggiornare l'esempio per supportare entrambi gli endpoint come autorità di certificazione valide.

Scaricare l'archivio: active-directory-b2c-dotnet-webapp-and-webapi-master.zip

git clone https://github.com/Azure-Samples/active-directory-b2c-dotnet-webapp-and-webapi.git

Abilitare più emittenti nell'API Web

In questa sezione viene aggiornato il codice per specificare che entrambi gli endpoint dell'autorità di certificazione token sono validi.

Aprire la soluzione B2C-WebAPI-DotNet.sln in Visual Studio
Nel progetto TaskService aprire il file TaskService\App_Start\Startup.Auth.cs nell'editor
Aggiungere la direttiva seguente using alla parte superiore del file:

using System.Collections.Generic;

Aggiungere la ValidIssuers proprietà alla TokenValidationParameters definizione e specificare entrambi gli URI registrati nella sezione precedente:

TokenValidationParameters tvps = new TokenValidationParameters
{
    // Accept only those tokens where the audience of the token is equal to the client ID of this app
    ValidAudience = ClientId,
    AuthenticationType = Startup.DefaultPolicy,
    ValidIssuers = new List<string> {
        "https://login.microsoftonline.com/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/v2.0/",
        "https://{your-b2c-tenant}.b2clogin.com/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/v2.0/"//,
        //"https://your-custom-domain/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/v2.0/"
    }
};

TokenValidationParameters viene fornito da MSAL.NET e viene utilizzato dal middleware OWIN nella sezione successiva del codice in Startup.Auth.cs. Con più autorità emittenti valide specificate, la pipeline dell'applicazione OWIN viene resa consapevole che entrambi gli endpoint token sono emittenti valide.

app.UseOAuthBearerAuthentication(new OAuthBearerAuthenticationOptions
{
    // This SecurityTokenProvider fetches the Azure AD B2C metadata &  from the OpenID Connect metadata endpoint
    AccessTokenFormat = new JwtFormat(tvps, new tCachingSecurityTokenProvider(String.Format(AadInstance, ultPolicy)))
});

Come accennato in precedenza, altre librerie OWIN offrono in genere una struttura simile per supportare più emittenti. Anche se fornisce esempi per ogni libreria non rientra nell'ambito di questo articolo, è possibile usare una tecnica simile per la maggior parte delle librerie.

Cambiare endpoint nell'app Web

Con entrambi gli URI ora supportati dall'API Web, è ora necessario aggiornare l'applicazione Web in modo che recupera i token dall'endpoint di b2clogin.com.

Ad esempio, è possibile configurare l'applicazione Web di esempio per usare il nuovo endpoint modificando il ida:AadInstance valore nel file TaskWebApp\Web.configdel progetto TaskWebApp.

Modificare il ida:AadInstance valore nella Web.config di TaskWebApp in modo che faccia riferimento {your-b2c-tenant-name}.b2clogin.com anziché login.microsoftonline.com.

Prima di:

<!-- Old value -->
<add key="ida:AadInstance" value="https://login.microsoftonline.com/tfp/{0}/{1}" />

Dopo (sostituire {your-b2c-tenant} con il nome del tenant B2C):

<!-- New value -->
<add key="ida:AadInstance" value="https://{your-b2c-tenant}.b2clogin.com/tfp/{0}/{1}" />

Quando le stringhe endpoint vengono create durante l'esecuzione dell'app Web, gli endpoint basati su b2clogin.com vengono usati quando richiede token.

Quando si usa un dominio personalizzato:

<!-- Custom domain -->
<add key="ida:AadInstance" value="https://custom-domain/{0}/{1}" />

Passaggi successivi

Questo articolo ha presentato un metodo di configurazione di un'API Web che implementa il middleware Microsoft OWIN (Katana) per accettare token da più endpoint emittente. Come si può notare, esistono diverse altre stringhe nei file Web.Config dei progetti TaskService e TaskWebApp che devono essere modificati se si desidera compilare ed eseguire questi progetti nel proprio tenant. È consigliabile modificare i progetti in modo appropriato se si desidera visualizzarli in azione, tuttavia, una procedura dettagliata completa dell'operazione è esterna all'ambito di questo articolo.

Per altre informazioni sui diversi tipi di token di sicurezza generati da Azure AD B2C, vedere Panoramica dei token in Azure Active Directory B2C.

Condividi tramite