Proteggere un'API di Gestione API di Azure con Azure AD B2C

  • Articolo

Informazioni su come limitare l'accesso all'API di Azure Gestione API ai client che hanno eseguito l'autenticazione con Azure Active Directory B2C (Azure AD B2C). Seguire le istruzioni riportate in questo articolo per creare e testare criteri in ingresso in Azure Gestione API che limitano l'accesso solo alle richieste che includono un token di accesso rilasciato da Azure AD B2C valido.

Prerequisiti

Prima di iniziare, assicurarsi di disporre delle risorse seguenti:

Ottenere l'ID applicazione di Azure AD B2C

Quando si protegge un'API in Azure Gestione API con Azure AD B2C, sono necessari diversi valori per i criteri in ingresso creati in Azure Gestione API. Registrare prima l'ID di un'applicazione creata in precedenza nel tenant di Azure AD B2C. Se si usa l'applicazione creata per soddisfare i prerequisiti, usare l'ID applicazione per webapp1.

Per registrare un'applicazione nel tenant di Azure AD B2C, è possibile usare la nuova esperienza Registrazioni app unificata o l'esperienza delle applicazioni legacy. Altre informazioni sulla nuova esperienza di registrazione.

  1. Accedi al portale di Azure.
  2. Se si ha accesso a più tenant, selezionare l'icona Impostazioni nel menu in alto per passare al tenant di Azure AD B2C dal menu Directory e sottoscrizioni.
  3. Nel riquadro sinistro selezionare Azure AD B2C. In alternativa, è possibile selezionare Tutti i servizi e quindi cercare e selezionare Azure AD B2C.
  4. Selezionare Registrazioni app e quindi selezionare la scheda Applicazioni di proprietà.
  5. Registrare il valore nella colonna ID applicazione (client) per webapp1 o per un'altra applicazione creata in precedenza.

Ottenere un endpoint dell'autorità di certificazione del token

Successivamente, ottenere l'URL di configurazione well-known di uno dei flussi utente di Azure AD B2C. È necessario anche l'URI dell'endpoint dell'autorità di certificazione del token che si vuole supportare in Azure Gestione API.

  1. Nel portale di Azure passare al tenant di Azure AD B2C.

  2. In Criteri selezionare Flussi utente.

  3. Selezionare un criterio esistente (ad esempio, B2C_1_signupsignin1) e quindi selezionare Esegui flusso utente.

  4. Registrare l'URL nel collegamento ipertestuale visualizzato sotto l'intestazione Esegui flusso utente nella parte superiore della pagina. Questo URL è openID Connessione endpoint di individuazione noto per il flusso utente e verrà usato nella sezione successiva quando si configurano i criteri in ingresso in Azure Gestione API.

    Screenshot of the well-known URI hyperlink on the

  5. Selezionare il collegamento ipertestuale per passare alla pagina di configurazione Connessione nota.

  6. Nella pagina visualizzata nel browser registrare il issuer valore. Ad esempio:

    https://<tenant-name>.b2clogin.com/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/v2.0/

    Questo valore verrà usato nella sezione successiva quando si configura l'API in Azure Gestione API.

A questo punto sono disponibili due URL registrati da usare nella prossima sezione: l'URL dell'endpoint di configurazione well-known di OpenID Connect e l'URI dell'autorità emittente. Ad esempio:

https://<tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/B2C_1_signupsignin1/v2.0/.well-known/openid-configuration
https://<tenant-name>.b2clogin.com/99999999-0000-0000-0000-999999999999/v2.0/

Configurare i criteri in ingresso in Azure Gestione API

A questo punto è possibile aggiungere il criterio in ingresso in Gestione API di Azure per la convalida delle chiamate API. Aggiungendo un criterio di convalida del token Web JSON (JWT) che verifica il gruppo di destinatari e l'autorità emittente in un token di accesso, è possibile assicurarsi che vengano accettate solo le chiamate API con un token valido.

  1. Nella portale di Azure passare all'istanza di Azure Gestione API.

  2. Selezionare API.

  3. Selezionare l'API che si vuole proteggere con Azure AD B2C.

  4. Selezionare la scheda Progettazione.

  5. In Elaborazione in ingresso selezionare </> per aprire l'editor del codice dei criteri.

  6. Inserire il tag seguente <validate-jwt> all'interno dei <inbound> criteri e quindi eseguire le operazioni seguenti:

    a. Aggiornare il valore url nell'elemento <openid-config> con l'URL di configurazione well-known del criterio.
    b. Aggiornare l'elemento <audience> con l'ID applicazione dell'applicazione creata in precedenza nel tenant B2C, ad esempio webapp1.
    c. Aggiornare l'elemento <issuer> con l'endpoint dell'autorità emittente di token registrato in precedenza.

    <policies>
    <inbound>
        <validate-jwt header-name="Authorization" failed-validation-httpcode="401" failed-validation-error-message="Unauthorized. Access token is missing or invalid.">
            <openid-config url="https://<tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/B2C_1_signupsignin1/v2.0/.well-known/openid-configuration" />
            <audiences>
                <audience>44444444-0000-0000-0000-444444444444</audience>
            </audiences>
            <issuers>
                <issuer>https://<tenant-name>.b2clogin.com/99999999-0000-0000-0000-999999999999/v2.0/</issuer>
            </issuers>
        </validate-jwt>
        <base />
    </inbound>
    <backend> <base /> </backend>
    <outbound> <base /> </outbound>
    <on-error> <base /> </on-error>
</policies>

Convalidare l'accesso API sicuro

Per assicurarsi che solo i chiamanti autenticati possano accedere all'API, è possibile convalidare la configurazione di Azure Gestione API chiamando l'API con Postman.

Per chiamare l'API, è necessario un token di accesso rilasciato da Azure AD B2C e una chiave di sottoscrizione di Azure Gestione API.

Ottenere un token di accesso

Per prima cosa è necessario un token rilasciato da Azure AD B2C da usare nell'intestazione Authorization in Postman. È possibile ottenerlo usando la funzionalità Esegui ora del flusso utente di iscrizione/accesso creato come uno dei prerequisiti.

  1. Nel portale di Azure passare al tenant di Azure AD B2C.

  2. In Criteri selezionare Flussi utente.

  3. Selezionare un flusso utente di iscrizione/accesso esistente, ad esempio B2C_1_signupsignin1.

  4. Per Applicazione selezionare webapp1.

  5. Per URL di risposta selezionare https://jwt.ms.

  6. Seleziona Esegui il flusso utente.

    Screenshot of the

  7. Completare il processo di accesso. Verrà eseguito il reindirizzamento a https://jwt.ms.

  8. Registrare il valore del token codificato visualizzato nel browser. Questo valore del token viene usato per l'intestazione Authorization in Postman.

    Screenshot of the encoded token value displayed on jwt.ms.

Ottenere una chiave di sottoscrizione API

Un'applicazione client (in questo caso, Postman) che chiama un'API pubblicata deve includere nelle richieste HTTP all'API una chiave di sottoscrizione di Gestione API valida. Per ottenere una chiave di sottoscrizione da includere nella richiesta HTTP di Postman:

  1. Nella portale di Azure passare all'istanza del servizio Azure Gestione API.
  2. Selezionare Sottoscrizioni.
  3. Selezionare i puntini di sospensione (...) accanto a Prodotto: Illimitato e quindi selezionare Mostra/Nascondi chiavi.
  4. Registrare la chiave primaria per il prodotto. Questa chiave viene usata per l'intestazione Ocp-Apim-Subscription-Key nella richiesta HTTP di Postman.

Screenshot of the

Testare una chiamata API sicura

Con il token di accesso e la chiave di sottoscrizione di Azure Gestione API registrata, è ora possibile verificare se l'accesso sicuro all'API è stato configurato correttamente.

  1. Creare una nuova richiesta GET in Postman. Per l'URL della richiesta, specificare l'endpoint dell'elenco dei relatori dell'API pubblicata come prerequisito. Ad esempio:

    https://contosoapim.azure-api.net/conference/speakers

  2. Aggiungere quindi le intestazioni seguenti:

    Chiave Valore
    Authorization Valore del token codificato registrato in precedenza, preceduto da Bearer (includere lo spazio dopo "Bearer")
    Ocp-Apim-Subscription-Key La chiave di sottoscrizione di Azure Gestione API registrata in precedenza.

    L'URL della richiesta GET e le intestazioni dovrebbero essere simili a quelli mostrati nell'immagine seguente:

    Screenshot of the Postman UI showing the GET request URL and headers.

  3. In Postman selezionare il pulsante Invia per eseguire la richiesta. Se tutto è stato configurato correttamente, si dovrebbe avere una risposta JSON con una raccolta di relatori della conferenza (mostrati qui, troncati):

    {
  "collection": {
    "version": "1.0",
    "href": "https://conferenceapi.azurewebsites.net:443/speakers",
    "links": [],
    "items": [
      {
        "href": "https://conferenceapi.azurewebsites.net/speaker/1",
        "data": [
          {
            "name": "Name",
            "value": "Scott Guthrie"
          }
        ],
        "links": [
          {
            "rel": "http://tavis.net/rels/sessions",
            "href": "https://conferenceapi.azurewebsites.net/speaker/1/sessions"
          }
        ]
      },
[...]

Testare una chiamata API non sicura

Dopo che è stata eseguita una richiesta con esito positivo, testare il caso di errore per verificare che le chiamate all'API con un token non valido vengano rifiutate come previsto. Un modo per eseguire il test consiste nell'aggiungere o modificare alcuni caratteri nel valore del token e quindi eseguire la stessa GET richiesta di prima.

  1. Aggiungere alcuni caratteri al valore del token per simulare un token non valido. Ad esempio, è possibile aggiungere "INVALID" al valore del token, come illustrato di seguito:

    Screenshot of the Headers section of Postman UI showing the string INVALID added to token.

  2. Selezionare il pulsante Send (Invia) per eseguire la richiesta. Con un token non valido, il risultato previsto è un codice di stato non autorizzato 401:

    {
    "statusCode": 401,
    "message": "Unauthorized. Access token is missing or invalid."
}

Se viene visualizzato un 401 codice di stato, è stato verificato che solo i chiamanti con un token di accesso valido rilasciato da Azure AD B2C possono effettuare richieste riuscite all'API di Gestione API di Azure.

Supportare più applicazioni e autorità emittenti

Diverse applicazioni interagiscono in genere con una sola API REST. Per consentire all'API di accettare i token destinati a più applicazioni, aggiungere gli ID applicazione all'elemento <audiences> nei criteri in ingresso di Azure Gestione API.

<!-- Accept tokens intended for these recipient applications -->
<audiences>
    <audience>44444444-0000-0000-0000-444444444444</audience>
    <audience>66666666-0000-0000-0000-666666666666</audience>
</audiences>

Analogamente, per supportare più autorità emittenti di token, aggiungere gli URI dell'endpoint all'elemento <issuers> nei criteri di azure Gestione API in ingresso.

<!-- Accept tokens from multiple issuers -->
<issuers>
    <issuer>https://<tenant-name>.b2clogin.com/99999999-0000-0000-0000-999999999999/v2.0/</issuer>
    <issuer>https://login.microsoftonline.com/99999999-0000-0000-0000-999999999999/v2.0/</issuer>
</issuers>

Eseguire la migrazione a b2clogin.com

Se si dispone di un'API di Azure Gestione API M che convalida i token rilasciati dall'endpoint legacylogin.microsoftonline.com, è necessario eseguire la migrazione dell'API e delle applicazioni che lo chiamano per usare i token rilasciati da b2clogin.com.

Per eseguire una migrazione a fasi, è possibile seguire questa procedura generale:

  1. Aggiungere il supporto nei criteri in ingresso di Azure Gestione API per i token rilasciati sia da b2clogin.com che da login.microsoftonline.com.
  2. Aggiornare le applicazioni una alla volta per ottenere i token dall'endpoint b2clogin.com.
  3. Dopo che tutte le applicazioni ottengono correttamente i token da b2clogin.com, rimuovere il supporto per i token rilasciati da login.microsoftonline.com dall'API.

L'esempio seguente Gestione API criteri in ingresso di Azure illustra come accettare i token rilasciati sia da b2clogin.com che da login.microsoftonline.com. Inoltre, i criteri supportano le richieste API da due applicazioni.

<policies>
    <inbound>
        <validate-jwt header-name="Authorization" failed-validation-httpcode="401" failed-validation-error-message="Unauthorized. Access token is missing or invalid.">
            <openid-config url="https://<tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/B2C_1_signupsignin1/v2.0/.well-known/openid-configuration" />
            <audiences>
                <audience>44444444-0000-0000-0000-444444444444</audience>
                <audience>66666666-0000-0000-0000-666666666666</audience>
            </audiences>
            <issuers>
                <issuer>https://login.microsoftonline.com/99999999-0000-0000-0000-999999999999/v2.0/</issuer>
                <issuer>https://<tenant-name>.b2clogin.com/99999999-0000-0000-0000-999999999999/v2.0/</issuer>
            </issuers>
        </validate-jwt>
        <base />
    </inbound>
    <backend> <base /> </backend>
    <outbound> <base /> </outbound>
    <on-error> <base /> </on-error>
</policies>

Passaggi successivi

Per altre informazioni sui criteri di Azure Gestione API, vedere l'indice di riferimento dei criteri di Azure Gestione API.

Per informazioni sulla migrazione delle API Web basate su OWIN e delle relative applicazioni a b2clogin.com, vedere Eseguire la migrazione di un'API Web basata su OWIN a b2clogin.com.