Registrare un'applicazione SAML in Azure AD B2C

  • Articolo

Questo articolo descrive come connettere le applicazioni SAML (Security Assertion Markup Language) ad Azure Active Directory B2C (Azure AD B2C) per l'autenticazione.

Prima di iniziare, usare il selettore Scegli un tipo di criterio per scegliere il tipo di criterio che si sta configurando. Azure Active Directory B2C offre due metodi per definire il modo in cui gli utenti interagiscono con le applicazioni: tramite flussi utente predefiniti o tramite criteri personalizzati completamente configurabili. I passaggi necessari in questo articolo sono diversi per ogni metodo.

Questa funzionalità è disponibile solo per i criteri personalizzati. Per i passaggi di installazione, selezionare Criteri personalizzati nel selettore precedente.

Panoramica

Le organizzazioni che usano Azure AD B2C come soluzione di gestione delle identità e degli accessi dei clienti potrebbero richiedere l'integrazione con le applicazioni che eseguono l'autenticazione usando il protocollo SAML. Il diagramma seguente illustra come Azure AD B2C funge da provider di identità (IdP) per ottenere l'accesso Single Sign-On (SSO) con applicazioni basate su SAML.

Diagram with Azure Active Directory B2C as an identity provider on the left and as a service provider on the right.

  1. L'applicazione crea una richiesta di autenticazione SAML inviata all'endpoint di accesso SAML per Azure AD B2C.
  2. L'utente può usare un account locale di Azure AD B2C o qualsiasi altro provider di identità federato (se configurato) per l'autenticazione.
  3. Se l'utente accede usando un provider di identità federato, viene inviata una risposta del token ad Azure AD B2C.
  4. Azure AD B2C genera un'asserzione SAML e la invia all'applicazione.

Guardare questo video per informazioni su come integrare le applicazioni SAML con Azure AD B2C.

Prerequisiti

Per lo scenario in questo articolo, è necessario:

  • Criteri personalizzati SocialAndLocalAccounts di un pacchetto di avvio dei criteri personalizzato. Completare la procedura descritta in Introduzione ai criteri personalizzati in Azure AD B2C.
  • Conoscenza di base del protocollo SAML e familiarità con l'implementazione SAML dell'applicazione.
  • Un'applicazione Web configurata come applicazione SAML. Deve avere la possibilità di inviare richieste SAML AuthN e di ricevere, decodificare e verificare le risposte SAML da Azure AD B2C. L'applicazione SAML è nota anche come applicazione relying party o provider di servizi.
  • L'endpoint dei metadati SAML o il documento XML dell'applicazione SAML disponibile pubblicamente.
  • Un tenant di Azure AD B2C.

Se non si dispone ancora di un'applicazione SAML e di un endpoint di metadati associato, è possibile usare l'applicazione di test SAML resa disponibile per il test.

Importante

Gli endpoint devono essere conformi ai requisiti di sicurezza di Azure AD B2C. Le versioni precedenti di TLS e le crittografie sono deprecate. Per altre informazioni, vedere Requisiti di Azure AD B2C TLS e della suite di crittografia.

Configurare i certificati

Per creare una relazione di trust tra l'applicazione e Azure AD B2C, entrambi i servizi devono essere in grado di creare e convalidare le firme. Configurare i certificati X509 nell'applicazione e in Azure AD B2C.

Certificati dell'applicazione

Utilizzo Richiesto Descrizione
Firma della richiesta SAML No Un certificato con una chiave privata archiviata nell'app Web. L'applicazione usa il certificato per firmare le richieste SAML inviate ad Azure AD B2C. L'app Web deve esporre la chiave pubblica tramite l'endpoint dei metadati SAML. Azure AD B2C convalida la firma della richiesta SAML usando la chiave pubblica dai metadati dell'applicazione.
Crittografia asserzione SAML No Un certificato con una chiave privata archiviata nell'app Web. L'app Web deve esporre la chiave pubblica tramite l'endpoint dei metadati SAML. Azure AD B2C può crittografare le asserzioni nell'applicazione usando la chiave pubblica. L'applicazione usa la chiave privata per decrittografare l'asserzione.

Certificati di Azure AD B2C

Utilizzo Richiesto Descrizione
Firma della risposta SAML Sì Un certificato con una chiave privata archiviata in Azure AD B2C. Azure AD B2C usa questo certificato per firmare la risposta SAML inviata all'applicazione. L'applicazione legge la chiave pubblica dei metadati in Azure AD B2C per convalidare la firma della risposta SAML.
Firma dell'asserzione SAML Sì Un certificato con una chiave privata archiviata in Azure AD B2C. Azure AD B2C usa questo certificato per firmare la <saml:Assertion> parte della risposta SAML.

In un ambiente di produzione è consigliabile usare i certificati rilasciati da un'autorità di certificazione pubblica. Tuttavia, è anche possibile completare questa procedura con certificati autofirmato.

Creare una chiave dei criteri

Per avere una relazione di trust tra l'applicazione e Azure AD B2C, creare un certificato di firma per la risposta SAML. Azure AD B2C usa questo certificato per firmare la risposta SAML inviata all'applicazione. L'applicazione legge la chiave pubblica dei metadati per Azure AD B2C per convalidare la firma della risposta SAML.

Suggerimento

È possibile usare questa chiave di criteri per altri scopi, ad esempio firmare l'asserzione SAML.

Ottenere un certificato

Se non si ha già un certificato, è possibile usare un certificato autofirmato. Un certificato autofirmato è un certificato di sicurezza non firmato da un'autorità di certificazione (CA) e non fornisce le garanzie di sicurezza di un certificato firmato da una CA.

In Windows usare il cmdlet New-SelfSignedCertificate in PowerShell per generare un certificato.

  1. Eseguire il comando di PowerShell seguente per generare un certificato autofirmato. Modificare l'argomento -Subject in base alle esigenze dell'applicazione e del nome del tenant di Azure AD B2C, contosowebapp.contoso.onmicrosoft.comad esempio . Si può anche modificare la data -NotAfter per specificare una scadenza diversa per il certificato.

    New-SelfSignedCertificate `
    -KeyExportPolicy Exportable `
    -Subject "CN=yourappname.yourtenant.onmicrosoft.com" `
    -KeyAlgorithm RSA `
    -KeyLength 2048 `
    -KeyUsage DigitalSignature `
    -NotAfter (Get-Date).AddMonths(12) `
    -CertStoreLocation "Cert:\CurrentUser\My"

  2. Nel computer Windows cercare e selezionare Gestisci certificati utente

  3. In Certificati - Utente corrente selezionare Certificati>personali>yourappname.yourtenant.onmicrosoft.com.

  4. Selezionare il certificato e quindi selezionare Azione>Tutte le attività>esportate.

  5. Selezionare Avanti>Sì, esportare la chiave>privata Avanti.

  6. Accettare le impostazioni predefinite per Formato file di esportazione e quindi selezionare Avanti.

  7. Abilitare l'opzione Password , immettere una password per il certificato e quindi selezionare Avanti.

  8. Per specificare un percorso per salvare il certificato, selezionare Sfoglia e passare a una directory di propria scelta.

  9. Nella finestra Salva con nome immettere un nome file e quindi selezionare Salva.

  10. Selezionare Next>Finish (Avanti > Fine).

Per consentire ad Azure AD B2C di accettare la password del file pfx, la password deve essere crittografata con l'opzione TripleDES-SHA1 nell'utilità di esportazione dell'archivio certificati di Windows, anziché AES256-SHA256.

Caricare il certificato

È necessario archiviare il certificato nel tenant di Azure AD B2C.

  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. Selezionare Tutti i servizi nell'angolo superiore sinistro del portale di Azure e quindi cercare e selezionare Azure AD B2C.
  4. Nella pagina Panoramica selezionare Identity Experience Framework.
  5. Selezionare Chiavi dei criteri e quindi selezionare Aggiungi.
  6. Per Opzioni selezionare Carica.
  7. In Nome immettere un nome per la chiave del criterio. Ad esempio, immettere SamlIdpCert. Il prefisso B2C_1A_ viene aggiunto automaticamente al nome della chiave.
  8. Individuare e selezionare il file di certificato con estensione pfx con la chiave privata.
  9. Seleziona Crea.

Abilitare i criteri per connettersi a un'applicazione SAML

Per connettersi all'applicazione SAML, Azure AD B2C deve essere in grado di creare risposte SAML.

Aprire SocialAndLocalAccounts\TrustFrameworkExtensions.xml nel pacchetto di avvio dei criteri personalizzato.

Trovare la <ClaimsProviders> sezione e aggiungere il frammento XML seguente per implementare il generatore di risposte SAML:

<ClaimsProvider>
  <DisplayName>Token Issuer</DisplayName>
  <TechnicalProfiles>

    <!-- SAML Token Issuer technical profile -->
    <TechnicalProfile Id="Saml2AssertionIssuer">
      <DisplayName>Token Issuer</DisplayName>
      <Protocol Name="SAML2"/>
      <OutputTokenFormat>SAML2</OutputTokenFormat>
      <Metadata>
        <Item Key="IssuerUri">https://issuerUriMyAppExpects</Item>
      </Metadata>
      <CryptographicKeys>
        <Key Id="SamlAssertionSigning" StorageReferenceId="B2C_1A_SamlIdpCert"/>
        <Key Id="SamlMessageSigning" StorageReferenceId="B2C_1A_SamlIdpCert"/>
      </CryptographicKeys>
      <InputClaims/>
      <OutputClaims/>
      <UseTechnicalProfileForSessionManagement ReferenceId="SM-Saml-issuer"/>
    </TechnicalProfile>

    <!-- Session management technical profile for SAML-based tokens -->
    <TechnicalProfile Id="SM-Saml-issuer">
      <DisplayName>Session Management Provider</DisplayName>
      <Protocol Name="Proprietary" Handler="Web.TPEngine.SSO.SamlSSOSessionProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"/>
    </TechnicalProfile>

  </TechnicalProfiles>
</ClaimsProvider>

Configurare l'URI dell'autorità di certificazione della risposta SAML

È possibile modificare il valore dell'elemento di metadati nel profilo tecnico dell'autorità IssuerUri di certificazione del token SAML. Questa modifica verrà riflessa nell'attributo issuerUri restituito nella risposta SAML da Azure AD B2C. Configurare l'applicazione per accettare lo stesso IssuerUri valore durante la convalida della risposta SAML.

<ClaimsProvider>
  <DisplayName>Token Issuer</DisplayName>
  <TechnicalProfiles>
    <!-- SAML Token Issuer technical profile -->
    <TechnicalProfile Id="Saml2AssertionIssuer">
      <DisplayName>Token Issuer</DisplayName>
      <Protocol Name="SAML2"/>
      <OutputTokenFormat>SAML2</OutputTokenFormat>
      <Metadata>
        <Item Key="IssuerUri">https://issuerUriMyAppExpects</Item>
      </Metadata>
      ...
    </TechnicalProfile>

Configurare i criteri per emettere una risposta SAML

Ora che i criteri possono creare risposte SAML, è necessario configurare i criteri per inviare una risposta SAML anziché la risposta JWT predefinita all'applicazione.

Creare un criterio di iscrizione o di accesso configurato per SAML

  1. Creare una copia del file SignUpOrSignin.xml nella directory di lavoro del starter pack e salvarla con un nuovo nome. Questo articolo usa SignUpOrSigninSAML.xml come esempio. Questo file è il file dei criteri per la relying party. È configurato per emettere una risposta JWT per impostazione predefinita.

  2. Aprire il file SignUpOrSigninSAML.xml in un editor a scelta.

  3. Modificare il valore di:

    1. PolicyId a B2C_1A_signup_signin_saml

    2. Da PublicPolicyUri a http://<tenant-name>.onmicrosoft.com/B2C_1A_signup_signin_saml. Sostituire <tenant-name> il segnaposto con il sottodominio del nome di dominio del tenant di Azure AD B2C. Ad esempio, se il dominio primario del tenant è contoso.onmicrosoft.com, usare contoso. Se non si ha il nome del tenant, vedere come leggere i dettagli del tenant.

    <TrustFrameworkPolicy
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="http://schemas.microsoft.com/online/cpim/schemas/2013/06"
PolicySchemaVersion="0.3.0.0"
TenantId="<tenant-name>.onmicrosoft.com"
PolicyId="B2C_1A_signup_signin_saml"
PublicPolicyUri="http://<tenant-name>.onmicrosoft.com/B2C_1A_signup_signin_saml">

  4. Al termine del percorso utente, Azure AD B2C contiene un SendClaims passaggio. Questo passaggio fa riferimento al profilo tecnico dell'autorità di certificazione token. Per emettere una risposta SAML anziché la risposta JWT predefinita, modificare il SendClaims passaggio per fare riferimento al nuovo profilo tecnico dell'autorità di certificazione token SAML, Saml2AssertionIssuer.

Aggiungere il frammento XML seguente subito prima dell'elemento <RelyingParty> . Questo codice XML sovrascrive il passaggio 7 dell'orchestrazione nel percorso utente SignUpOrSignIn .

Se si è iniziato da una cartella diversa nel pacchetto starter o è stato personalizzato il percorso utente aggiungendo o rimuovendo i passaggi di orchestrazione, assicurarsi che il numero nell'elemento order corrisponda al numero specificato nel percorso utente per il passaggio dell'autorità di certificazione del token. Ad esempio, nelle altre cartelle starter pack, il numero di passaggio corrispondente è 4 per LocalAccounts, 6 per SocialAccountse 9 per SocialAndLocalAccountsWithMfa.

<UserJourneys>
  <UserJourney Id="SignUpOrSignIn">
    <OrchestrationSteps>
      <OrchestrationStep Order="7" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="Saml2AssertionIssuer"/>
    </OrchestrationSteps>
  </UserJourney>
</UserJourneys>

L'elemento relying party determina il protocollo usato dall'applicazione. Il valore predefinito è OpenId. L'elemento Protocol deve essere modificato in SAML. Le attestazioni di output creeranno il mapping delle attestazioni all'asserzione SAML.

Sostituire l'intero elemento <TechnicalProfile> nell'elemento <RelyingParty> con il seguente codice XML del profilo tecnico.

    <TechnicalProfile Id="PolicyProfile">
      <DisplayName>PolicyProfile</DisplayName>
      <Protocol Name="SAML2"/>
      <OutputClaims>
        <OutputClaim ClaimTypeReferenceId="displayName" />
        <OutputClaim ClaimTypeReferenceId="givenName" />
        <OutputClaim ClaimTypeReferenceId="surname" />
        <OutputClaim ClaimTypeReferenceId="email" DefaultValue="" />
        <OutputClaim ClaimTypeReferenceId="identityProvider" DefaultValue="" />
        <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="objectId"/>
      </OutputClaims>
      <SubjectNamingInfo ClaimType="objectId" ExcludeAsClaim="true"/>
    </TechnicalProfile>

Il file di criteri finale per la relying party dovrebbe essere simile al codice XML seguente:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<TrustFrameworkPolicy
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:xsd="http://www.w3.org/2001/XMLSchema"
  xmlns="http://schemas.microsoft.com/online/cpim/schemas/2013/06"
  PolicySchemaVersion="0.3.0.0"
  TenantId="contoso.onmicrosoft.com"
  PolicyId="B2C_1A_signup_signin_saml"
  PublicPolicyUri="http://contoso.onmicrosoft.com/B2C_1A_signup_signin_saml">

  <BasePolicy>
    <TenantId>contoso.onmicrosoft.com</TenantId>
    <PolicyId>B2C_1A_TrustFrameworkExtensions</PolicyId>
  </BasePolicy>

  <UserJourneys>
    <UserJourney Id="SignUpOrSignIn">
      <OrchestrationSteps>
        <OrchestrationStep Order="7" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="Saml2AssertionIssuer"/>
      </OrchestrationSteps>
    </UserJourney>
  </UserJourneys>

  <RelyingParty>
    <DefaultUserJourney ReferenceId="SignUpOrSignIn" />
    <TechnicalProfile Id="PolicyProfile">
      <DisplayName>PolicyProfile</DisplayName>
      <Protocol Name="SAML2"/>
      <OutputClaims>
        <OutputClaim ClaimTypeReferenceId="displayName" />
        <OutputClaim ClaimTypeReferenceId="givenName" />
        <OutputClaim ClaimTypeReferenceId="surname" />
        <OutputClaim ClaimTypeReferenceId="email" DefaultValue="" />
        <OutputClaim ClaimTypeReferenceId="identityProvider" DefaultValue="" />
        <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="objectId"/>
      </OutputClaims>
      <SubjectNamingInfo ClaimType="objectId" ExcludeAsClaim="true"/>
    </TechnicalProfile>
  </RelyingParty>
</TrustFrameworkPolicy>

Nota

È possibile seguire questo stesso processo per implementare altri tipi di flussi utente( ad esempio, flussi di accesso, reimpostazione della password o modifica del profilo).

Caricare i criteri

Salvare le modifiche e caricare i nuovi file di criteri TrustFrameworkExtensions.xml e SignUpOrSigninSAML.xml nel portale di Azure.

Testare i metadati SAML idP di Azure AD B2C

Dopo aver caricato i file dei criteri, Azure AD B2C usa le informazioni di configurazione per generare il documento di metadati SAML del provider di identità che verrà usato dall'applicazione. Il documento di metadati SAML contiene i percorsi dei servizi, ad esempio i metodi di accesso, i metodi di disconnessione e i certificati.

I metadati dei criteri di Azure AD B2C sono disponibili nell'URL seguente:

https://<tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/<policy-name>/samlp/metadata

Sostituire <tenant-name> con il nome del tenant di Azure AD B2C. Sostituire <policy-name> con il nome (ID) del criterio. Ecco un esempio:

https://contoso.b2clogin.com/contoso.onmicrosoft.com/B2C_1A_signup_signin_saml/samlp/metadata

Registrare l'applicazione SAML in Azure AD B2C

Affinché Azure AD B2C consideri attendibile l'applicazione, si crea una registrazione dell'applicazione Azure AD B2C. La registrazione contiene informazioni di configurazione, ad esempio l'endpoint dei metadati dell'applicazione.

  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 menu a sinistra selezionare Azure AD B2C. In alternativa, selezionare Tutti i servizi e quindi cercare e selezionare Azure AD B2C.
  4. Selezionare Registrazioni app e quindi Nuova registrazione.
  5. Immettere un nome per l'applicazione. Ad esempio, immettere SAMLApp1.
  6. In Tipi di account supportati selezionare Account solo in questa directory organizzativa.
  7. In URI di reindirizzamento selezionare Web e quindi immettere https://localhost. Questo valore verrà modificato più avanti nel manifesto della registrazione dell'applicazione.
  8. Selezionare Registra.

Configurare l'applicazione in Azure AD B2C

Per le app SAML, è necessario configurare diverse proprietà nel manifesto della registrazione dell'applicazione.

  1. Nella portale di Azure passare alla registrazione dell'applicazione creata nella sezione precedente.
  2. In Gestisci selezionare Manifesto per aprire l'editor manifesto. Modificare quindi le proprietà descritte nelle sezioni seguenti.

Aggiungere l'identificatore

Quando l'applicazione SAML effettua una richiesta ad Azure AD B2C, la richiesta di autenticazione SAML include un Issuer attributo. Il valore di questo attributo è in genere uguale al valore dei metadati entityID dell'applicazione. Azure AD B2C usa questo valore per cercare la registrazione dell'applicazione nella directory e leggere la configurazione. Affinché questa ricerca abbia esito positivo, identifierUri nella registrazione dell'applicazione deve essere popolato con un valore corrispondente all'attributo Issuer .

Nel manifesto di registrazione trovare il identifierURIs parametro e aggiungere il valore appropriato. Questo valore sarà lo stesso valore configurato nelle richieste SAML AuthN per EntityId all'applicazione e il entityID valore nei metadati dell'applicazione. Sarà anche necessario trovare il accessTokenAcceptedVersion parametro e impostare il valore su 2.

Importante

Se non si aggiorna l'oggetto accessTokenAcceptedVersion a 2 verrà visualizzato un messaggio di errore che richiede un dominio verificato.

L'esempio seguente mostra il entityID valore nei metadati SAML:

<EntityDescriptor ID="id123456789" entityID="https://samltestapp2.azurewebsites.net" validUntil="2099-12-31T23:59:59Z" xmlns="urn:oasis:names:tc:SAML:2.0:metadata">

La identifierUris proprietà accetterà gli URL solo nel dominio tenant-name.onmicrosoft.com.

"identifierUris":"https://tenant-name.onmicrosoft.com/app-name",

Condividere i metadati dell'applicazione con Azure AD B2C

Dopo che la registrazione dell'applicazione è stata caricata dal relativo identifierUri valore, Azure AD B2C usa i metadati dell'applicazione per convalidare la richiesta di autenticazione SAML e determinare come rispondere.

È consigliabile che l'applicazione esponga un endpoint di metadati accessibile pubblicamente.

Se sono presenti proprietà specificate sia nell'URL dei metadati SAML che nel manifesto della registrazione dell'applicazione, vengono unite. Le proprietà specificate nell'URL dei metadati vengono elaborate per prime e hanno la precedenza.

Usando l'applicazione di test SAML come esempio, si userà il valore seguente per samlMetadataUrl nel manifesto dell'applicazione:

"samlMetadataUrl":"https://samltestapp2.azurewebsites.net/Metadata",

Eseguire l'override o impostare l'URL del consumer di asserzione (facoltativo)

È possibile configurare l'URL di risposta a cui Azure AD B2C invia risposte SAML. Gli URL di risposta possono essere configurati nel manifesto dell'applicazione. Questa configurazione è utile quando l'applicazione non espone un endpoint di metadati accessibile pubblicamente.

L'URL di risposta per un'applicazione SAML è l'endpoint in cui l'applicazione prevede di ricevere risposte SAML. L'applicazione fornisce in genere questo URL nel documento di metadati come Location attributo dell'elemento AssertionConsumerService , come illustrato in questo esempio:

<SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
    ...
    <AssertionConsumerService index="0" isDefault="true" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://samltestapp2.azurewebsites.net/SP/AssertionConsumer" />        
</SPSSODescriptor>

Se l'elemento di metadati AssertionConsumerService dell'applicazione è mancante o si vuole eseguirne l'override, configurare la proprietà del manifesto replyUrlsWithType di registrazione dell'applicazione. Azure AD B2C usa per replyUrlsWithType reindirizzare gli utenti dopo l'accesso usando il HTTP-POST tipo di associazione.

Usando l'applicazione di test SAML come esempio, è necessario impostare la url proprietà di replyUrlsWithType sul valore illustrato nel frammento JSON seguente:

"replyUrlsWithType":[
  {
    "url":"https://samltestapp2.azurewebsites.net/SP/AssertionConsumer",
    "type":"Web"
  }
],

Eseguire l'override o impostare l'URL di disconnessione (facoltativo)

L'URL di disconnessione definisce dove reindirizzare l'utente dopo una richiesta di disconnessione. L'applicazione fornisce in genere questo URL nel documento di metadati come Location attributo dell'elemento SingleLogoutService , come illustrato nell'esempio seguente:

<SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
    <SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://samltestapp2.azurewebsites.net/logout" ResponseLocation="https://samltestapp2.azurewebsites.net/logout" />

</SPSSODescriptor>

Se l'elemento di metadati SingleLogoutService dell'applicazione non è presente, configurare la proprietà del manifesto logoutUrl di registrazione dell'applicazione. Azure AD B2C usa per logoutURL reindirizzare gli utenti dopo la disconnessione usando il HTTP-Redirect tipo di associazione.

Usando l'applicazione di test SAML come esempio, è necessario impostare la logoutUrl proprietà su https://samltestapp2.azurewebsites.net/logout:

"logoutUrl": "https://samltestapp2.azurewebsites.net/logout",

Nota

Se si sceglie di configurare l'URL di risposta e l'URL di disconnessione nel manifesto dell'applicazione senza popolare l'endpoint dei metadati dell'applicazione tramite la samlMetadataUrl proprietà , Azure AD B2C non convaliderà la firma della richiesta SAML. Non crittograferà nemmeno la risposta SAML.

Configurare Azure AD B2C come IDP SAML nell'applicazione SAML

L'ultimo passaggio consiste nell'abilitare Azure AD B2C come IDP SAML nell'applicazione SAML. Ogni applicazione è diversa e i passaggi variano. Per informazioni dettagliate, vedere la documentazione dell'app.

I metadati possono essere configurati nell'applicazione come metadati statici o metadati dinamici. In modalità statica copiare tutti o parte dei metadati dai metadati dei criteri di Azure AD B2C. In modalità dinamica specificare l'URL dei metadati e consentire all'applicazione di leggere i metadati in modo dinamico.

Di solito sono necessari alcuni o tutti gli elementi seguenti:

  • Metadati: usare il formato https://<tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/<policy-name>/Samlp/metadata.

  • Autorità di certificazione: il valore della issuer richiesta SAML deve corrispondere a uno degli URI configurati nell'elemento identifierUris del manifesto di registrazione dell'applicazione. Se il nome della issuer richiesta SAML non esiste nell'elemento identifierUris , aggiungerlo al manifesto della registrazione dell'applicazione. Ad esempio: https://contoso.onmicrosoft.com/app-name.

  • URL di accesso, endpoint SAML, URL SAML: controllare il valore nel file di metadati dei criteri SAML di Azure AD B2C per l'elemento <SingleSignOnService> XML.

  • Certificato: questo certificato è B2C_1A_SamlIdpCert, ma senza la chiave privata. Per ottenere la chiave pubblica del certificato:

    1. Passare all'URL dei metadati specificato in precedenza.
    2. Copiare il valore nell'elemento <X509Certificate>.
    3. Incollarlo in un file di testo.
    4. Salvare il file di testo come file con estensione cer.

Testare con l'app di test SAML

È possibile usare l'applicazione di test SAML per testare la configurazione:

  • Aggiornare il nome del tenant.
  • Aggiornare il nome del criterio. Ad esempio, usare B2C_1A_signup_signin_saml.
  • Specificare l'URI dell'autorità di certificazione. Usare uno degli URI trovati nell'elemento identifierUris nel manifesto di registrazione dell'applicazione. Ad esempio, usare https://contoso.onmicrosoft.com/app-name.

Selezionare Account di accesso e verrà visualizzata una schermata di accesso utente. Dopo l'accesso, viene restituita una risposta SAML all'applicazione di esempio.

Modalità SAML supportate e non

Gli scenari di applicazione SAML seguenti sono supportati tramite il proprio endpoint di metadati:

  • Specificare più URL di disconnessione o binding POST per l'URL di disconnessione nell'applicazione o nell'oggetto entità servizio.
  • Specificare una chiave di firma per verificare le richieste della relying party nell'oggetto applicazione o entità servizio.
  • Specificare una chiave di crittografia del token nell'applicazione o nell'oggetto entità servizio.
  • Specificare l'accesso avviato da IdP, in cui il provider di identità è Azure AD B2C.

Passaggi successivi