Esercitazione: Configurare l'identità ping con Azure Active Directory B2C per l'accesso ibrido sicuro

Questa esercitazione descrive come estendere le funzionalità di Azure Active Directory B2C (Azure AD B2C) con PingAccess e PingFederate. PingAccess fornisce l'accesso alle applicazioni e alle API e un motore di criteri per l'accesso utente autorizzato. PingFederate è un server federativo aziendale per l'autenticazione utente e l'accesso Single Sign-On, un'autorità che consente a clienti, dipendenti e partner di accedere alle applicazioni dai dispositivi. Usarli insieme per abilitare l'accesso ibrido sicuro (SHA).

Molti siti di e-commerce e applicazioni Web esposti a Internet vengono distribuiti dietro i sistemi proxy o un sistema proxy inverso. Questi sistemi proxy pre-autenticano, applicano i criteri e instradano il traffico. Gli scenari tipici includono la protezione delle applicazioni Web dal traffico Web in ingresso e la gestione uniforme delle sessioni tra distribuzioni di server distribuiti.

In genere, le configurazioni includono un livello di conversione dell'autenticazione che esternalizza l'autenticazione dall'applicazione Web. I proxy inversi forniscono il contesto utente autenticato alle applicazioni Web, ad esempio un valore di intestazione in formato non crittografato o digest. Le applicazioni non usano token standard del settore, ad esempio SAML (Security Assertion Markup Language), OAuth o OpenID Connect (OIDC). Il proxy fornisce invece il contesto di autenticazione e gestisce la sessione con l'agente dell'utente finale, ad esempio browser o applicazione nativa. I proxy man-in-the-middle in esecuzione come servizio forniscono un controllo sessione significativo. Il servizio proxy è efficiente e scalabile, non un collo di bottiglia per le applicazioni dietro il servizio proxy. Il diagramma è un flusso di comunicazione e implementazione del proxy inverso.

Modernizzazione

Se si vuole modernizzare una piattaforma di gestione delle identità in tali configurazioni, potrebbero verificarsi problemi dei clienti:

• Separare lo sforzo necessario per modernizzare le applicazioni dalla modernizzazione di una piattaforma di gestione delle identità
• Ambienti con autenticazione moderna e legacy, che utilizzano dal provider di servizi di gestione delle identità modernizzato
  • Favorire la coerenza dell'esperienza dell'utente finale
  • Offrire un'esperienza di accesso Single Sign-On tra le applicazioni

In risposta a questi problemi, l'approccio in questa esercitazione è un'integrazione di Azure AD B2C, PingAccess e PingFederate .

Ambiente condiviso

Una soluzione tecnicamente valida e conveniente consiste nel configurare il sistema proxy inverso in modo da usare il sistema di identità modernizzato, delegando l'autenticazione.
I proxy supportano i protocolli di autenticazione moderni e usano l'autenticazione basata sul reindirizzamento (passiva) che invia gli utenti al nuovo provider di identità (IdP).

Azure AD B2C come provider di identità

In Azure AD B2C si definiscono criteri che determinano esperienze utente e comportamenti, detti anche percorsi utente. Ogni criterio espone un endpoint del protocollo che può eseguire l'autenticazione come IdP. Sul lato applicazione non è necessaria alcuna gestione speciale per determinati criteri. Un'applicazione effettua una richiesta di autenticazione standard all'endpoint di autenticazione specifico del protocollo esposto da un criterio.
È possibile configurare Azure AD B2C per condividere la stessa autorità emittente tra criteri o autorità di certificazione univoca per ogni criterio. Ogni applicazione può puntare ai criteri effettuando una richiesta di autenticazione nativa del protocollo, che determina comportamenti utente come l'accesso, l'iscrizione e le modifiche del profilo. Il diagramma mostra i flussi di lavoro delle applicazioni OIDC e SAML.

Lo scenario può essere difficile per le applicazioni legacy per reindirizzare l'utente in modo accurato. La richiesta di accesso alle applicazioni potrebbe non includere il contesto dell'esperienza utente. Nella maggior parte dei casi, il livello proxy o un agente integrato nell'applicazione Web intercetta la richiesta di accesso.

Proxy inverso PingAccess

È possibile distribuire PingAccess come proxy inverso. PingAccess intercetta una richiesta diretta essendo il man-in-the-middle o come reindirizzamento da un agente in esecuzione nel server applicazioni Web.

Configurare PingAccess con OIDC, OAuth2 o SAML per l'autenticazione con un provider di autenticazione upstream. È possibile configurare un IdP upstream a questo scopo nel server PingAccess. Vedere il diagramma seguente.

In una tipica distribuzione di Azure AD B2C con criteri che espongono gli IDP, esiste una sfida. PingAccess è configurato con un IdP upstream.

Proxy federativo PingFederate

È possibile configurare PingFederate come provider di autenticazione o un proxy per gli idp upstream. Vedere il diagramma seguente.

Usare questa funzione per passare in modo contestuale, dinamico o dichiarativo a una richiesta in ingresso a un criterio di Azure AD B2C. Vedere il diagramma seguente del flusso di sequenza del protocollo.

Prerequisiti

Per iniziare, è necessario:

• Una sottoscrizione di Azure
  • Se non è disponibile, ottenere un account Gratuito di Azure
• Un tenant di Azure AD B2C collegato alla sottoscrizione di Azure
• PingAccess e PingFederate distribuiti in contenitori Docker o in macchine virtuali di Azure

Connettività e comunicazione

Verificare la connettività e la comunicazione seguenti.

• Server PingAccess : comunica con il server PingFederate, il browser client, OIDC, l'individuazione di chiavi note e note OAuth pubblicate dal servizio Azure AD B2C e dal server PingFederate
• Server PingFederate : comunica con il server PingAccess, il browser client, OIDC, l'individuazione delle chiavi note e note OAuth pubblicate dal servizio Azure AD B2C
• Applicazione AuthN legacy o basata su intestazione : comunica con e verso il server PingAccess
• Applicazione relying party SAML : raggiunge il traffico del browser dal client. Accede ai metadati della federazione SAML pubblicati dal servizio Azure AD B2C.
• Applicazione moderna : raggiunge il traffico del browser dal client. Accede all'individuazione delle chiavi OIDC, OAuth nota e pubblicata dal servizio Azure AD B2C.
• API REST : raggiunge il traffico da un client nativo o Web. Accede all'individuazione delle chiavi OIDC, OAuth note e pubblicate dal servizio Azure AD B2C

Configurare Azure AD B2C

È possibile usare flussi utente di base o criteri IEF (Identity Enterprise Framework) avanzati. PingAccess genera l'endpoint dei metadati, in base al valore dell'autorità emittente, usando il protocollo WebFinger per la convenzione di individuazione. Per seguire questa convenzione, aggiornare l'autorità emittente di Azure AD B2C usando le proprietà dei criteri del flusso utente.

Nei criteri avanzati, la configurazione include l'elemento di metadati IssuanceClaimPattern al valore AuthorityWithTfp nel profilo tecnico dell'autorità emittente del token JWT.

Configurare PingAccess e PingFederate

Usare le istruzioni nelle sezioni seguenti per configurare PingAccess e PingFederate. Vedere il diagramma seguente del flusso utente di integrazione complessivo.

Configurare PingFederate come provider di token

Per configurare PingFederate come provider di token per PingAccess, verificare la connettività da PingFederate a PingAccess. Verificare la connettività da PingAccess a PingFederate.

Per altre informazioni, vedere Configurare PingFederate come provider di token per PingAccess nella documentazione di Ping Identity.

Configurare un'applicazione PingAccess per l'autenticazione basata su intestazione

Usare le istruzioni seguenti per creare un'applicazione PingAccess per l'applicazione Web di destinazione, per l'autenticazione basata su intestazione.

Creare un host virtuale

Importante

Creare un host virtuale per ogni applicazione. Per altre informazioni, vedere Cosa è possibile configurare con PingAccess? nella documentazione di Ping Identity.

Per creare un host virtuale:

1. Passare a Impostazioni>Accedere agli>host virtuali.
2. Selezionare Aggiungi host virtuale.
3. Per Host immettere la parte FQDN dell'URL dell'applicazione.
4. Per Porta immettere 443.
5. Selezionare Salva.

Creare una sessione Web

Per creare una sessione Web:

1. Passare a Impostazioni>Accedere> allesessioni Web.
2. Selezionare Aggiungi sessione Web.
3. Immettere un nome per la sessione Web.
4. Selezionare il tipo di cookie: JWT firmato o JWT crittografato.
5. Immettere un valore univoco per Destinatari.
6. Per ID client immettere l'ID applicazione Microsoft Entra.
7. Per Segreto client immettere la chiave generata per l'applicazione in Microsoft Entra ID.
8. (Facoltativo) Creare e usare attestazioni personalizzate con Microsoft API Graph: selezionare Avanzate. Deselezionare Il profilo richiesta e aggiornare gli attributi utente. Altre informazioni sulle attestazioni personalizzate: Single Sign-On basato su intestazione per le app locali con Microsoft Entra proxy di applicazione.
9. Selezionare Salva

Creare il mapping delle identità

Nota

È possibile usare il mapping delle identità con più di un'applicazione, se prevedono gli stessi dati nell'intestazione.

Per creare il mapping delle identità:

1. Passare a Impostazioni> Mappingidentità diaccesso>.
2. Selezionare Aggiungi mapping identità.
3. Specificare un *Nome.
4. Selezionare il tipo di mapping di identità del mapping di intestazione.
5. Nella tabella Mapping attributi specificare i mapping necessari. Ad esempio,

Nome attributo	Nome intestazione
'upn'	x-userprincipalname
'email'	x-email
'oid'	x-oid
'scp'	Ambito x
'amr'	x-amr

6. Selezionare Salva

Creare un sito

Nota

In alcune configurazioni, un sito può contenere più applicazioni. È possibile usare un sito con più di un'applicazione, se appropriato.

Per creare un sito:

1. Passare aSitiprincipali>.
2. Selezionare Aggiungi sito.
3. Immettere il nome del sito.
4. Immettere il sito Destinazione. La destinazione è la coppia nome host:porta per il server che ospita l'applicazione. Non immettere il percorso dell'applicazione in questo campo. Ad esempio, un'applicazione in https://mysite:9999/AppName ha un valore di destinazione mysite:9999.
5. Indicare se la destinazione prevede connessioni sicure.
6. Se la destinazione prevede connessioni sicure, impostare Il gruppo di certificati attendibili su Considera attendibile qualsiasi.
7. Selezionare Salva.

Creare un'applicazione

Per creare un'applicazione in PingAccess per ogni applicazione in Azure da proteggere.

1. Passare alleapplicazioniprincipali>

2. Selezionare Aggiungi applicazione

3. Specificare un nome per l'applicazione

4. Facoltativamente, immettere una descrizione per l'applicazione

5. Specificare la radice del contesto per l'applicazione. Ad esempio, un'applicazione in https://mysite:9999/AppName avrà una radice di contesto /AppName. La radice del contesto deve iniziare con una barra (/), non deve terminare con una barra (/) e può essere più di un livello profondo, ad esempio /Apps/MyApp.

6. Selezionare l'host virtuale creato

   Nota

   La combinazione di host virtuale e radice del contesto deve essere univoca in PingAccess.

7. Selezionare la sessione Web creata

8. Selezionare il sito creato che contiene l'applicazione

9. Selezionare il mapping delle identità creato

10. Selezionare Abilitato per abilitare il sito quando si salva

11. Selezionare Salva

Configurare i criteri di autenticazione PingFederate

Configurare i criteri di autenticazione PingFederate per la federazione con più provider di identità forniti dai tenant di Azure AD B2C

1. Creare un contratto per collegare gli attributi tra gli idp e il provider di servizi. È necessario un solo contratto, a meno che il provider di servizi non richieda un set di attributi diverso da ogni Provider di identità. Per altre informazioni, vedere Contratti dell'hub federativo e dei criteri di autenticazione nella documentazione di Ping Identity.

2. Per ogni Provider di identità creare una connessione IdP tra IdP e PingFederate, l'hub federativo come SP.

3. Nella finestra Mapping sessione di destinazione aggiungere i contratti dei criteri di autenticazione applicabili alla connessione IdP.

4. Nella finestra Selettori configurare un selettore di autenticazione. Ad esempio, vedere un'istanza dell'adapter Identifier First per eseguire il mapping di ogni IdP alla connessione IdP corrispondente in un criterio di autenticazione.

5. Creare una connessione SP tra PingFederate, l'hub federativo come IdP e SP.

6. Aggiungere il contratto dei criteri di autenticazione corrispondente alla connessione SP nella finestra Mapping origine autenticazione.

7. Usare ogni Provider di identità per connettersi a PingFederate, ovvero l'hub federativo come SP.

8. Usare il provider di servizi per connettersi a PingFederate, ovvero l'hub federativo come IdP.

Passaggi successivi

Per altre informazioni, vedere gli articoli seguenti

• Criteri personalizzati in AAD B2C

• Introduzione ai criteri personalizzati in Azure AD B2C