Configurare le opzioni del provider di identità SAML con Azure Active Directory B2C

2025-05-03

Importante

A partire dal 1° maggio 2025, Azure AD B2C non sarà più disponibile per l'acquisto per i nuovi clienti. Altre informazioni sono disponibili nelle domande frequenti.

Azure Active Directory B2C (Azure AD B2C) supporta la federazione con i provider di identità SAML 2.0. Questo articolo descrive come analizzare le asserzioni di sicurezza e le opzioni di configurazione disponibili quando si abilita l'accesso con un provider di identità SAML.

Prima di iniziare, utilizza il selettore Scegli un tipo di criterio nella parte superiore di questa pagina 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.

Mapping delle attestazioni

L'elemento OutputClaims contiene un elenco di attestazioni restituite dal provider di identità SAML. È necessario eseguire il mapping del nome dell'attestazione definita nei criteri al nome definito nel provider di identità. Controllare il provider di identità per l'elenco delle attestazioni (asserzioni). Puoi anche controllare il contenuto della risposta SAML restituita dal tuo provider di identità. Per ulteriori informazioni, consulta Eseguire il debug dei messaggi SAML. Per aggiungere un'attestazione, definire prima un'attestazione, quindi aggiungere l'attestazione alla raccolta di attestazioni di output.

È inoltre possibile includere attestazioni che non vengono restituite dal provider di identità, purché sia stato impostato l'attributo DefaultValue . Il valore predefinito può essere statico o dinamico, utilizzando attestazioni di contesto.

L'elemento claim di output contiene gli attributi seguenti:

ClaimTypeReferenceId è il riferimento a un tipo di attestazione.
PartnerClaimType è il nome della proprietà che viene visualizzata nell'asserzione SAML.
DefaultValue è un valore predefinito predefinito. Se l'attestazione è vuota, viene utilizzato il valore predefinito. È anche possibile usare un resolver di attestazioni con un valore contestuale, ad esempio l'ID di correlazione o l'indirizzo IP dell'utente.

Nome oggetto

Per leggere l'asserzione SAML NameIdnell'oggetto come attestazione normalizzata, impostare l'attestazione PartnerClaimType sul valore dell'attributo SPNameQualifier . Se l'attributo SPNameQualifier non viene presentato, impostare l'attestazione PartnerClaimType sul valore dell'attributo NameQualifier.

Asserzione SAML:

<saml:Subject>
  <saml:NameID SPNameQualifier="http://your-idp.com/unique-identifier" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">david@contoso.com</saml:NameID>
  <SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
    <SubjectConfirmationData InResponseTo="_cd37c3f2-6875-4308-a9db-ce2cf187f4d1" NotOnOrAfter="2020-02-15T16:23:23.137Z" Recipient="https://<your-tenant>.b2clogin.com/<your-tenant>.onmicrosoft.com/B2C_1A_TrustFrameworkBase/samlp/sso/assertionconsumer" />
    </SubjectConfirmation>
  </saml:SubjectConfirmation>
</saml:Subject>

Attestazione di output:

<OutputClaim ClaimTypeReferenceId="issuerUserId" PartnerClaimType="http://your-idp.com/unique-identifier" />

Se sia SPNameQualifier che NameQualifier non sono presentati nell'asserzione SAML, impostare l'attestazione PartnerClaimType su assertionSubjectName. Assicurarsi che NameId sia il primo valore nell'asserzione XML. Quando si definiscono più di un'asserzione, Azure AD B2C seleziona il valore dell'oggetto dall'ultima asserzione.

Configurare le associazioni del protocollo SAML

Le richieste SAML vengono inviate al provider di identità come specificato nell'elemento di metadati SingleSignOnService del provider di identità. La maggior parte delle richieste di autorizzazione dei provider di identità viene trasportata direttamente nella stringa di query URL di una richiesta HTTP GET (poiché i messaggi sono relativamente brevi). Consulta la documentazione del provider di identità per informazioni su come configurare i binding per entrambe le richieste SAML.

Il codice XML seguente è un esempio di servizio Single Sign-On dei metadati di Microsoft Entra con due associazioni. Ha HTTP-Redirect la precedenza su perché HTTP-POST viene visualizzato per primo nei metadati del provider di identità SAML.

<IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
  ...
  <SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://login.microsoftonline.com/00000000-0000-0000-0000-000000000000/saml2"/>
  <SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://login.microsoftonline.com/00000000-0000-0000-0000-000000000000/saml2"/>
</IDPSSODescriptor>

Servizio di convalida per il cliente

Il servizio consumer di asserzione (o ACS) è il punto in cui le risposte SAML del provider di identità vengono inviate e ricevute da Azure AD B2C. Le risposte SAML vengono trasmesse ad Azure AD B2C tramite l'associazione HTTP POST. La posizione ACS punta alla politica di base della parte fidata. Ad esempio, se il criterio di base è B2C_1A_signup_signin, ACS è il criterio di base del B2C_1A_signup_signin, ad esempio B2C_1A_TrustFrameworkBase.

Il codice XML seguente è un esempio di un elemento del servizio di consumatore per l'asserzione dei metadati della policy di Azure AD B2C.

<SPSSODescriptor AuthnRequestsSigned="true" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
  ...
  <AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://your-tenant.b2clogin.com/your-tenant/B2C_1A_TrustFrameworkBase/samlp/sso/assertionconsumer" index="0" isDefault="true"/>
</SPSSODescriptor>

Configurare la firma della richiesta SAML

Azure AD B2C firma tutte le richieste di autenticazione in uscita usando la chiave crittografica SamlMessageSigning . Per disabilitare la firma della richiesta SAML, impostare WantsSignedRequests su false. Se i metadati sono impostati su false, i parametri SigAlg e Signature (stringa di query o parametro post) vengono omessi dalla richiesta.

Questi metadati controllano anche l'attributo AuthnRequestsSigned , incluso nei metadati del profilo tecnico di Azure AD B2C condiviso con il provider di identità. Azure AD B2C non firma la richiesta se il valore di WantsSignedRequests nei metadati del profilo tecnico è impostato su false e i metadati del provider di identità WantAuthnRequestsSigned sono impostati o false non specificati.

Nell'esempio seguente viene rimossa la firma dalla richiesta SAML.

<Metadata>
  ...
  <Item Key="WantsSignedRequests">false</Item>
</Metadata>

Algoritmo di firma

Azure AD B2C viene utilizzato Sha1 per firmare la richiesta SAML. Utilizzare i metadati XmlSignatureAlgorithm per configurare l'algoritmo da utilizzare. I valori possibili sono Sha256, Sha384, Sha512, o Sha1 (impostazione predefinita). Questi metadati controllano il valore del parametro SigAlg (stringa di query o parametro post) nella richiesta SAML. Verificare di configurare l'algoritmo di firma per entrambe le parti con lo stesso valore. Usare solo l'algoritmo supportato dal certificato.

Includi le informazioni chiave

Quando il provider di identità indica che l'associazione di Azure AD B2C è impostata su HTTP-POST, Azure AD B2C include la firma e l'algoritmo nel corpo della richiesta SAML. È inoltre possibile configurare l'ID Microsoft Entra in modo da includere la chiave pubblica del certificato quando l'associazione è impostata su HTTP-POST. Utilizzare i metadati IncludeKeyInfo per true, o false. Nell'esempio seguente, l'ID Microsoft Entra non include la chiave pubblica del certificato.

<Metadata>
  ...
  <Item Key="IncludeKeyInfo">false</Item>
</Metadata>

Configurare l'ID nome della richiesta SAML

L'elemento di richiesta <NameID> di autorizzazione SAML indica il formato dell'identificatore del nome SAML. In questa sezione viene descritta la configurazione predefinita e viene descritto come personalizzare l'elemento ID nome.

Nome utente preferito

Durante un percorso utente di accesso, un'applicazione relying party può essere destinata a un utente specifico. Azure AD B2C consente di inviare un nome utente preferito al provider di identità SAML. L'elemento InputClaims viene utilizzato per inviare un NameId all'interno dell'oggetto della richiesta di autorizzazione SAML.

Per includere l'ID del nome del soggetto all'interno della richiesta di autorizzazione, aggiungere l'elemento seguente <InputClaims> subito dopo .<CryptographicKeys> PartnerClaimType deve essere impostato su subject.

<InputClaims>
  <InputClaim ClaimTypeReferenceId="signInName" PartnerClaimType="subject" />
</InputClaims>

In questo esempio, Azure AD B2C invia il valore dell'attestazione signInName con NameId all'interno dell'oggetto della richiesta di autorizzazione SAML.

<samlp:AuthnRequest ... >
  ...
  <saml:Subject>
    <saml:NameID>sam@contoso.com</saml:NameID>
  </saml:Subject>
</samlp:AuthnRequest>

È possibile utilizzare attestazioni di contesto, ad esempio {OIDC:LoginHint} per popolare il valore dell'attestazione.

<Metadata>
  ...
  <Item Key="IncludeClaimResolvingInClaimsHandling">true</Item>
</Metadata>
  ...
<InputClaims>
  <InputClaim ClaimTypeReferenceId="signInName" PartnerClaimType="subject" DefaultValue="{OIDC:LoginHint}" AlwaysUseDefaultValue="true" />
</InputClaims>

Formato della policy Name ID

Per impostazione predefinita, la richiesta di autorizzazione SAML specifica il urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified criterio. Questo ID di nome indica che è possibile utilizzare qualsiasi tipo di identificatore supportato dal provider di identità relativo al soggetto richiesto.

Per modificare questo comportamento, fare riferimento alla documentazione del provider di identità per indicazioni sulle politiche di ID nome supportate. Aggiungere quindi i NameIdPolicyFormat metadati nel formato dei criteri corrispondente. Per esempio:

<Metadata>
  ...
  <Item Key="NameIdPolicyFormat">urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</Item>
</Metadata>

La seguente richiesta di autorizzazione SAML contiene la politica di identificazione del nome.

<samlp:AuthnRequest ... >
  ...
  <samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" />
</samlp:AuthnRequest>

Consenti la creazione di nuovi account

Se si specifica il formato della politica di ID nome, è anche possibile specificare la proprietà AllowCreate di NameIDPolicy per indicare se il provider di identità è autorizzato a creare un nuovo account durante la procedura di accesso. Consulta la documentazione del tuo fornitore di identità per ulteriori indicazioni.

Azure AD B2C omette la AllowCreate proprietà per impostazione predefinita. È possibile modificare questo comportamento utilizzando i NameIdPolicyAllowCreate metadati. Il valore di questi metadati è true o false.

Nell'esempio seguente viene illustrato come impostare AllowCreate la proprietà di NameIDPolicy su true.

<Metadata>
  ...
  <Item Key="NameIdPolicyFormat">urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</Item>
  <Item Key="NameIdPolicyAllowCreate">true</Item>
</Metadata>

Nell'esempio seguente viene illustrata una richiesta di autorizzazione con AllowCreate dell'elemento NameIDPolicy nella richiesta di autorizzazione.

<samlp:AuthnRequest ... >
  ...
  <samlp:NameIDPolicy 
      Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" 
      AllowCreate="true" />
</samlp:AuthnRequest>

Forza l'autenticazione

È possibile forzare l'IDP SAML esterno a richiedere l'autenticazione all'utente passando la ForceAuthN proprietà nella richiesta di autenticazione SAML. Il tuo provider di identità deve supportare anche questa proprietà.

La proprietà ForceAuthN è un valore Booleano true o false. Per impostazione predefinita, Azure AD B2C imposta il valore ForceAuthN su false. Se la sessione viene quindi reimpostata (ad esempio utilizzando in prompt=login OIDC), il ForceAuthN valore viene impostato su true. L'impostazione dei ForceAuthN metadati su true forza il valore per tutte le richieste all'IDP esterno.

Nell'esempio seguente viene illustrata la ForceAuthN proprietà impostata su true:

<Metadata>
  ...
  <Item Key="ForceAuthN">true</Item>
  ...
</Metadata>

Nell'esempio seguente viene illustrata la ForceAuthN proprietà in una richiesta di autorizzazione:

<samlp:AuthnRequest AssertionConsumerServiceURL="https://..."  ...
                    ForceAuthN="true">
  ...
</samlp:AuthnRequest>

Nome del fornitore

Facoltativamente, è possibile includere l'attributo ProviderName nella richiesta di autorizzazione SAML. Imposta i ProviderName metadati in modo che includano il nome del provider per tutte le richieste all'IDP SAML esterno. Nell'esempio seguente viene illustrata la ProviderName proprietà impostata su Contoso app:

<Metadata>
  ...
  <Item Key="ProviderName">Contoso app</Item>
  ...
</Metadata>

Nell'esempio seguente viene illustrata la ProviderName proprietà in una richiesta di autorizzazione:

<samlp:AuthnRequest AssertionConsumerServiceURL="https://..."  ...
                    ProviderName="Contoso app">
  ...
</samlp:AuthnRequest>

Includi riferimenti alla classe del contesto di autenticazione

Una richiesta di autorizzazione SAML può contenere un elemento AuthnContext , che specifica il contesto di una richiesta di autorizzazione. L'elemento può contenere un riferimento alla classe del contesto di autenticazione, che indica al provider di identità SAML quale meccanismo di autenticazione presentare all'utente.

Per configurare i riferimenti alla classe del contesto di autenticazione, aggiungere i metadati IncludeAuthnContextClassReferences . Nel valore specificare uno o più riferimenti URI che identificano le classi del contesto di autenticazione. Specificare più URI come elenco delimitato da virgole. Fare riferimento alla documentazione del provider di identità per indicazioni sugli URI AuthnContextClassRef supportati.

L'esempio seguente consente agli utenti di accedere con nome utente e password e di accedere con nome utente e password in una sessione protetta (SSL/TLS).

<Metadata>
  ...
  <Item Key="IncludeAuthnContextClassReferences">urn:oasis:names:tc:SAML:2.0:ac:classes:Password,urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</Item>
</Metadata>

La seguente richiesta di autorizzazione SAML contiene i riferimenti alla classe del contesto di autenticazione.

<samlp:AuthnRequest ... >
  ...
  <samlp:RequestedAuthnContext>
    <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</saml:AuthnContextClassRef>
    <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef>
  </samlp:RequestedAuthnContext>
</samlp:AuthnRequest>

Includi i dati personalizzati nella richiesta di autorizzazione

Facoltativamente, è possibile includere gli elementi dell'estensione del messaggio di protocollo accettati sia da Azure AD B2C che dal provider di identità. L'estensione è presentata in formato XML. Per includere gli elementi di estensione, aggiungere dati XML all'interno dell'elemento <![CDATA[Your Custom XML]]>CDATA. Consulta la documentazione del tuo fornitore di identità per verificare se l'elemento delle estensioni è supportato.

Nell'esempio seguente viene illustrato l'utilizzo dei dati di estensione:

<Metadata>
  ...
  <Item Key="AuthenticationRequestExtensions"><![CDATA[
            <ext:MyCustom xmlns:ext="urn:ext:custom">
              <ext:AssuranceLevel>1</ext:AssuranceLevel>
              <ext:AssuranceDescription>Identity verified to level 1.</ext:AssuranceDescription>
            </ext:MyCustom>]]></Item>
</Metadata>

Annotazioni

In base alla specifica SAML, i dati dell'estensione devono essere XML qualificati per namespace (ad esempio, 'urn:ext:custom' mostrato nell'esempio) e non devono essere uno dei namespace specifici di SAML.

Con l'estensione del messaggio del protocollo SAML, la risposta SAML è simile all'esempio seguente:

<samlp:AuthnRequest ... >
  ...
  <samlp:Extensions>
    <ext:MyCustom xmlns:ext="urn:ext:custom">
      <ext:AssuranceLevel>1</ext:AssuranceLevel>
      <ext:AssuranceDescription>Identity verified to level 1.</ext:AssuranceDescription>
    </ext:MyCustom>
  </samlp:Extensions>
</samlp:AuthnRequest>

Richiedi risposte SAML firmate

Azure AD B2C richiede che tutte le asserzioni in ingresso siano firmate. È possibile rimuovere questo requisito impostando WantsSignedAssertions su false. In questo caso, il provider di identità non deve firmare le asserzioni, ma anche se lo fa, Azure AD B2C non convalida la firma.

I metadati WantsSignedAssertions controllano il flag di metadati SAML WantAssertionsSigned, incluso nei metadati del profilo tecnico di Azure AD B2C condiviso con il provider di identità.

<SPSSODescriptor AuthnRequestsSigned="true" WantAssertionsSigned="true" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">

Se si disabilita la convalida delle asserzioni, è possibile disabilitare anche la convalida della firma del messaggio di risposta. Imposta i metadati ResponsesSigned su false. In questo caso, il provider di identità non deve firmare il messaggio di risposta SAML, ma anche se lo fa, Azure AD B2C non convalida la firma.

Nell'esempio seguente vengono rimossi sia il messaggio che la firma dell'asserzione:

<Metadata>
  ...
  <Item Key="WantsSignedAssertions">false</Item>
  <Item Key="ResponsesSigned">false</Item>
</Metadata>

Richiedi risposte SAML crittografate

Per richiedere la crittografia di tutte le asserzioni in ingresso, impostare i metadati WantsEncryptedAssertions . Quando è necessaria la crittografia, il provider di identità usa una chiave pubblica di un certificato di crittografia in un profilo tecnico di Azure AD B2C. Azure AD B2C decrittografa l'asserzione di risposta usando la parte privata del certificato di crittografia.

Se si abilita la crittografia delle asserzioni, potrebbe essere necessario disabilitare anche la convalida della firma di risposta (per ulteriori informazioni, vedere Richiedere risposte SAML firmate).

Quando i metadati WantsEncryptedAssertions sono impostati su true, i metadati del profilo tecnico di Azure AD B2C includono la sezione di crittografia . Il provider di identità legge i metadati e crittografa l'asserzione di risposta SAML con la chiave pubblica fornita nei metadati del profilo tecnico di Azure AD B2C.

L'esempio seguente mostra la sezione Key Descriptor dei metadati SAML utilizzati per la crittografia:

<SPSSODescriptor AuthnRequestsSigned="true"  protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
  <KeyDescriptor use="encryption">
    <KeyInfo xmlns="https://www.w3.org/2000/09/xmldsig#">
      <X509Data>
        <X509Certificate>valid certificate</X509Certificate>
      </X509Data>
    </KeyInfo>
  </KeyDescriptor>
  ...
</SPSSODescriptor>

Per crittografare l'asserzione della risposta SAML:

Creare una chiave dei criteri con un identificatore univoco. Ad esempio: B2C_1A_SAMLEncryptionCert.
Nel tuo profilo tecnico SAML CryptographicKeys collection. Impostare StorageReferenceId sul nome della chiave dei criteri creata nel primo passaggio. L'ID SamlAssertionDecryption indica l'uso della chiave crittografica per crittografare e decrittografare l'asserzione della risposta SAML.
```
<CryptographicKeys>
        ...
  <Key Id="SamlAssertionDecryption" StorageReferenceId="B2C_1A_SAMLEncryptionCert"/>
</CryptographicKeys>
```

Imposta i metadati del profilo tecnico WantsEncryptedAssertions su true.

<Metadata>
  ...
  <Item Key="WantsEncryptedAssertions">true</Item>
</Metadata>

Aggiorna il provider di identità con i nuovi metadati del profilo tecnico di Azure AD B2C. Verrà visualizzato KeyDescriptor con la proprietà use impostata su encryption contenente la chiave pubblica del certificato.

Abilitare l'uso delle attestazioni di contesto

Nella raccolta di attestazioni di input e output, è possibile includere attestazioni che non sono restituite dal provider di identità, a condizione che si imposti l'attributo DefaultValue. È inoltre possibile utilizzare le attestazioni di contesto da includere nel profilo tecnico. Per utilizzare un'attestazione di contesto:

Aggiungere un tipo di attestazione all'elemento ClaimsSchema all'interno di BuildingBlocks.

Aggiungere una dichiarazione di output alla raccolta di input o output. Nell'esempio il seguente, la prima attestazione definisce il valore del provider di identità. La seconda attestazione utilizza le attestazioni di contesto dell'indirizzo IP dell'utente.

<OutputClaims>
  <OutputClaim ClaimTypeReferenceId="identityProvider" DefaultValue="contoso.com" AlwaysUseDefaultValue="true" />
  <OutputClaim ClaimTypeReferenceId="IpAddress" DefaultValue="{Context:IPAddress}" AlwaysUseDefaultValue="true" />
</OutputClaims>

Disabilita disconnessione singola

Dopo una richiesta di disconnessione dell'applicazione, Azure AD B2C tenta di disconnettersi dal provider di identità SAML. Per altre informazioni, vedere Disconnessione della sessione di Azure AD B2C. Per disabilitare il comportamento di disconnessione singola, impostare i metadati SingleLogoutEnabled su false.

<Metadata>
  ...
  <Item Key="SingleLogoutEnabled">false</Item>
</Metadata>

Debug del protocollo SAML

Per configurare ed eseguire il debug della federazione con un provider di identità SAML, è possibile utilizzare un'estensione del browser per il protocollo SAML, ad esempio l'estensione SAML DevTools per Chrome, SAML-tracer per Firefox o gli strumenti di sviluppo di Microsoft Edge o Internet Explorer.

Usando questi strumenti, è possibile verificare l'integrazione tra Azure AD B2C e il provider di identità SAML. Per esempio:

Controlla se la richiesta SAML contiene una firma e determina quale algoritmo viene utilizzato per firmare la richiesta di autorizzazione.
Ottieni le affermazioni (asserzioni) nella sezione AttributeStatement.
Verificare se il provider di identità restituisce un messaggio di errore.
Controllare se la sezione asserzione è crittografata.

Esempi di richieste e risposte SAML

SAML (Security Assertion Markup Language) è uno standard aperto per lo scambio di dati di autenticazione e autorizzazione tra un provider di identità e un provider di servizi. Quando Azure AD B2C esegue la federazione con un provider di identità SAML, funge da provider di servizi avviando una richiesta SAML al provider di identità SAML e attendendo una risposta SAML.

Una risposta SAML riuscita contiene asserzioni di sicurezza, ovvero istruzioni effettuate dai provider di identità SAML esterni. Azure AD B2C analizza ed esegue il mapping delle asserzioni in attestazioni.

Richiesta di autorizzazione

Per richiedere l'autenticazione di un utente, Azure AD B2C invia un AuthnRequest elemento al provider di identità SAML esterno. Un esempio di SAML 2.0 AuthnRequest potrebbe essere simile all'esempio seguente:

<samlp:AuthnRequest 
    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" 
    ID="_11111111-0000-0000-0000-000000000000" 
    Version="2.0" 
    IssueInstant="2023-03-20T07:10:00.0000000Z" 
    Destination="https://fabrikam.com/saml2" 
    ForceAuthn="false" 
    IsPassive="false" 
    ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" 
    AssertionConsumerServiceURL="https://contoso.b2clogin.com/contoso.onmicrosoft.com/B2C_1A_TrustFrameworkBase/samlp/sso/assertionconsumer" 
    ProviderName="https://fabrikam.com" 
    xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <saml:Issuer 
        Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://contoso.b2clogin.com/contoso.onmicrosoft.com/B2C_1A_TrustFrameworkBase
    </saml:Issuer>
</samlp:AuthnRequest>

Risposta

Quando un accesso richiesto viene completato correttamente, il provider di identità SAML esterno invia una risposta all'endpoint del servizio consumer di asserzione di Azure AD B2C. Una risposta a un tentativo di accesso riuscito è simile all'esempio seguente:

<samlp:Response 
    ID="_98765432-0000-0000-0000-000000000000" 
    Version="2.0" 
    IssueInstant="2023-03-20T07:11:30.0000000Z" 
    Destination="https://contoso.b2clogin.com/contoso.onmicrosoft.com/B2C_1A_TrustFrameworkBase/samlp/sso/assertionconsumer" 
    InResponseTo="_11111111-0000-0000-0000-000000000000" 
    xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <Issuer 
        xmlns="urn:oasis:names:tc:SAML:2.0:assertion">https://fabrikam.com/
    </Issuer>
    <samlp:Status>
        <samlp:StatusCode 
            Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </samlp:Status>
    <Assertion 
        ID="_55555555-0000-0000-0000-000000000000" 
        IssueInstant="2023-03-20T07:40:45.505Z" 
        Version="2.0" 
        xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
        <Issuer>https://fabrikam.com/</Issuer>
        <Signature 
            xmlns="http://www.w3.org/2000/09/xmldsig#">
            ...
        </Signature>
        <Subject>
            <NameID 
                Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">ABCDEFG
            </NameID>
            ...
        </Subject>
        <AttributeStatement>
            <Attribute Name="uid">
                <AttributeValue>12345</AttributeValue>
            </Attribute>
            <Attribute Name="displayname">
                <AttributeValue>David</AttributeValue>
            </Attribute>
            <Attribute Name="email">
                <AttributeValue>david@contoso.com</AttributeValue>
            </Attribute>
            ....
        </AttributeStatement>
        <AuthnStatement 
            AuthnInstant="2023-03-20T07:40:45.505Z" 
            SessionIndex="_55555555-0000-0000-0000-000000000000">
            <AuthnContext>
                <AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</AuthnContextClassRef>
            </AuthnContext>
        </AuthnStatement>
    </Assertion>
</samlp:Response>

Richiesta di disconnessione

Dopo una richiesta di disconnessione dell'applicazione, Azure AD B2C tenta di disconnettersi dal provider di identità SAML. Azure AD B2C invia un LogoutRequest messaggio all'IDP esterno per indicare che una sessione è stata terminata. Nell'estratto seguente viene illustrato un elemento di esempio LogoutRequest .

Il valore dell'elemento NameID corrisponde a quello NameID dell'utente che viene disconnesso. L'elemento SessionIndex corrisponde all'attributo SessionIndex di AuthnStatement nella risposta SAML di accesso.

<samlp:LogoutRequest 
    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" 
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
    ID="_22222222-0000-0000-0000-000000000000" 
    Version="2.0" 
    IssueInstant="2023-03-20T08:21:07.3679354Z" 
    Destination="https://fabrikam.com/saml2/logout" 
    xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <saml:Issuer 
        Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://contoso.b2clogin.com/contoso.onmicrosoft.com/B2C_1A_TrustFrameworkBase
    </saml:Issuer>
    <saml:NameID>ABCDEFG</saml:NameID>
    <samlp:SessionIndex>_55555555-0000-0000-0000-000000000000</samlp:SessionIndex>
</samlp:LogoutRequest>

Passaggi successivi

Informazioni su come diagnosticare i problemi relativi ai criteri personalizzati usando Application Insights.