Configurar opções do provedor de identidade SAML com o Azure Ative Directory B2C

2025-05-02

Importante

A partir de 1º de maio de 2025, o Azure AD B2C não estará mais disponível para compra para novos clientes. Saiba mais nas nossas Perguntas Frequentes.

O Azure Ative Directory B2C (Azure AD B2C) dá suporte à federação com provedores de identidade SAML 2.0. Este artigo descreve como analisar as declarações de segurança e as opções de configuração disponíveis ao habilitar a entrada com um provedor de identidade SAML.

Antes de começar, use o seletor Escolha um tipo de política na parte superior desta página para escolher o tipo de política que você está configurando. O Azure Ative Directory B2C oferece dois métodos para definir como os usuários interagem com seus aplicativos: por meio de fluxos de usuário predefinidos ou por meio de políticas personalizadas totalmente configuráveis. As etapas exigidas neste artigo são diferentes para cada método.

Este recurso está disponível apenas para políticas personalizadas. Para as etapas de configuração, selecione Política personalizada no seletor anterior.

Mapeamento de afirmações

O elemento OutputClaims contém uma lista de declarações retornadas pelo provedor de identidade SAML. Você precisa mapear o nome da declaração definida em sua política para o nome definido no provedor de identidade. Verifique o seu provedor de identidade para obter a lista de declarações (asserções). Você também pode verificar o conteúdo da resposta SAML que seu provedor de identidade retorna. Para obter mais informações, consulte Depurar as mensagens SAML. Para adicionar uma declaração, primeiro defina uma declaração e, em seguida, adicione a declaração à coleção de declarações de saída.

Você também pode incluir declarações que não foram devolvidas pelo provedor de identidade, desde que você defina o atributo DefaultValue. O valor padrão pode ser estático ou dinâmico, usando declarações de contexto.

O elemento de declaração de saída contém os seguintes atributos:

ClaimTypeReferenceId é a referência a um tipo de declaração.
PartnerClaimType é o nome da propriedade que aparece na asserção SAML.
DefaultValue é um valor padrão predefinido. Se a declaração estiver vazia, o valor padrão será usado. Você também pode usar resolvedores de declarações com um valor contextual, como a ID de correlação ou o endereço IP do usuário.

Nome do assunto

Para ler a asserção SAML NameId no Subject como uma declaração normalizada, defina a declaração PartnerClaimType como o valor do SPNameQualifier atributo. Se o SPNameQualifieratributo não for apresentado, defina a reivindicação PartnerClaimType para o valor do atributo NameQualifier.

Afirmação 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>

Reivindicação de saída:

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

Se ambos SPNameQualifier e NameQualifier atributos não forem apresentados na asserção SAML, defina PartnerClaimType como assertionSubjectName. Verifique se NameId é o primeiro valor no XML de asserção. Quando você define mais de uma asserção, o Azure AD B2C seleciona o valor do assunto da última asserção.

Configurar ligações de protocolo SAML

As solicitações SAML são enviadas ao provedor de identidade conforme especificado no elemento de metadados SingleSignOnService do provedor de identidade. A maioria das solicitações de autorização dos provedores de identidade são transportadas diretamente na cadeia de caracteres de consulta de URL de uma solicitação HTTP GET (já que as mensagens são relativamente curtas). Consulte a documentação do provedor de identidade para saber como configurar as associações para ambas as solicitações SAML.

O XML a seguir é um exemplo de um serviço de logon único de metadados do Microsoft Entra com duas associações. O HTTP-Redirect tem precedência sobre o HTTP-POST porque aparece primeiro nos metadados do provedor de identidade 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>

Serviço de Comprovação ao Consumidor

O Assertion Consumer Service (ou ACS) é onde as respostas SAML do provedor de identidade são enviadas e recebidas pelo Azure AD B2C. As respostas SAML são transmitidas para o Azure AD B2C por meio da associação HTTP POST. O local do ACS aponta para a política base da parte confiável. Por exemplo, se a política de confiança for B2C_1A_signup_signin, o ACS será a política base do B2C_1A_signup_signin, como B2C_1A_TrustFrameworkBase.

O XML a seguir é um exemplo de um elemento de serviço ao consumidor de asserção de metadados de política do 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>

Configurar a assinatura de solicitação SAML

O Azure AD B2C assina todas as solicitações de autenticação de saída usando a chave criptográfica SamlMessageSigning . Para desabilitar a assinatura de solicitação SAML, defina WantsSignedRequests como false. Se os metadados estiverem definidos como false, os parâmetros SigAlg e Signature (string de consulta ou parâmetro post) serão omitidos da solicitação.

Esses metadados também controlam o atributo AuthnRequestsSigned , que está incluído com os metadados do perfil técnico do Azure AD B2C compartilhado com o provedor de identidade. O Azure AD B2C não assina a solicitação se o valor de WantsSignedRequests nos metadados do perfil técnico estiver definido como false e os metadados do provedor de identidade WantAuthnRequestsSigned estiverem definidos como false ou não especificados.

O exemplo a seguir remove a assinatura da solicitação SAML.

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

Algoritmo de assinatura

O Azure AD B2C usa Sha1 para assinar a solicitação SAML. Use os metadados XmlSignatureAlgorithm para configurar o algoritmo a ser usado. Os valores possíveis são Sha256, Sha384, Sha512, ou Sha1 (padrão). Esses metadados controlam o valor do parâmetro SigAlg (seqüência de caracteres de consulta ou parâmetro post) na solicitação SAML. Certifique-se de configurar o algoritmo de assinatura em ambos os lados com o mesmo valor. Utilize apenas o algoritmo suportado pelo certificado.

Incluir informações importantes

Quando o provedor de identidade indica que a associação do Azure AD B2C está definida como HTTP-POST, o Azure AD B2C inclui a assinatura e o algoritmo no corpo da solicitação SAML. Você também pode configurar o Microsoft Entra ID para incluir a chave pública do certificado quando a associação estiver definida como HTTP-POST. Utiliza os metadados IncludeKeyInfo para true, ou false. No exemplo a seguir, o Microsoft Entra ID não inclui a chave pública do certificado.

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

Configurar ID de nome de solicitação SAML

O elemento de solicitação de <NameID> autorização SAML indica o formato do identificador de nome SAML. Esta seção descreve a configuração padrão e como personalizar o elemento ID do nome.

Nome de utilizador preferido

Durante um processo de início de sessão de um utilizador, uma aplicação parte confiável pode direcionar-se a um utilizador específico. O Azure AD B2C permite que você envie um nome de usuário preferencial para o provedor de identidade SAML. O elemento InputClaims é usado para enviar um NameId dentro do Subject da solicitação de autorização SAML.

Para incluir o ID do nome do assunto na solicitação de autorização, adicione o seguinte <InputClaims> elemento imediatamente após o <CryptographicKeys>. O PartnerClaimType deve ser definido como subject.

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

Neste exemplo, o Azure AD B2C envia o valor da declaração signInName com NameId dentro do Assunto da solicitação de autorização SAML.

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

Você pode usar declarações de contexto, como {OIDC:LoginHint} para preencher o valor da declaração.

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

Formato da política de identificação de nome

Por padrão, a solicitação de autorização SAML especifica a urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified política. Esse ID de nome indica que qualquer tipo de identificador suportado pelo provedor de identidade para o assunto solicitado pode ser usado.

Para alterar esse comportamento, consulte a documentação do seu provedor de identidade para obter orientação sobre quais políticas de ID de nome são suportadas. Em seguida, adicione os NameIdPolicyFormat metadados no formato de política correspondente. Por exemplo:

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

O seguinte pedido de autorização SAML contém a política de identificação de nome.

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

Permitir a criação de novas contas

Se você especificar o formato da política de ID de Nome, também poderá especificar a AllowCreate propriedade de NameIDPolicy para indicar se o provedor de identidade tem permissão para criar uma nova conta durante o fluxo de entrada. Consulte a documentação do seu provedor de identidade para obter orientação.

O Azure AD B2C omite a AllowCreate propriedade por padrão. Você pode alterar esse comportamento usando os NameIdPolicyAllowCreate metadados. O valor desses metadados é true ou false.

O exemplo a seguir demonstra como definir a propriedade AllowCreate de NameIDPolicy para true.

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

O exemplo a seguir demonstra uma solicitação de autorização com AllowCreate do elemento NameIDPolicy na solicitação de autorização.

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

Forçar autenticação

Você pode forçar o IDP SAML externo a solicitar que o usuário se autentique, incluindo a propriedade ForceAuthN no pedido de autenticação SAML. Seu provedor de identidade também deve oferecer suporte a essa propriedade.

A ForceAuthN propriedade é um valor booleano true ou false. Por padrão, o Azure AD B2C define o valor ForceAuthN como false. Se a sessão for redefinida (por exemplo, usando o prompt=login no OIDC), o valor ForceAuthN será configurado para true. Definir os ForceAuthN metadados para true força o valor em todas as solicitações para o IDP externo.

O exemplo a seguir mostra a ForceAuthN propriedade definida como true:

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

O exemplo a seguir mostra a ForceAuthN propriedade em uma solicitação de autorização:

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

Nome do fornecedor

Opcionalmente, você pode incluir o ProviderName atributo na solicitação de autorização SAML. Defina os ProviderName metadados para incluir o nome do provedor de todas as solicitações para o IDP SAML externo. O exemplo a seguir mostra a ProviderName propriedade definida como Contoso app:

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

O exemplo a seguir mostra a ProviderName propriedade em uma solicitação de autorização:

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

Incluir referências de classes de contexto de autenticação

Uma solicitação de autorização SAML pode conter um elemento AuthnContext , que especifica o contexto de uma solicitação de autorização. O elemento pode conter uma referência de classe de contexto de autenticação, que informa ao provedor de identidade SAML qual mecanismo de autenticação apresentar ao usuário.

Para configurar as referências de classe de contexto de autenticação, use o metadado IncludeAuthnContextClassReferences. No valor, especifique uma ou mais referências de URI que identifiquem classes de contexto de autenticação. Especifique vários URIs como uma lista delimitada por vírgula. Consulte a documentação do seu provedor de identidade para obter orientação sobre os URIs AuthnContextClassRef suportados.

O exemplo a seguir permite que os usuários entrem com nome de usuário e senha e entrem com nome de usuário e senha em uma sessão protegida (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>

A seguinte solicitação de autorização SAML contém referências à classe de contexto de autenticação.

<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>

Incluir dados personalizados na solicitação de autorização

Opcionalmente, você pode incluir elementos de extensão de mensagem de protocolo que são acordados pelo Azure AD B2C e seu provedor de identidade. A extensão é apresentada em formato XML. Você inclui elementos de extensão adicionando dados XML dentro do elemento <![CDATA[Your Custom XML]]>CDATA . Verifique a documentação do seu provedor de identidade para ver se o elemento extensions é suportado.

O exemplo a seguir ilustra o uso de dados de extensão:

<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>

Observação

De acordo com a especificação SAML, os dados de extensão devem ser XML qualificados para namespace (por exemplo, 'urn:ext:custom' mostrado no exemplo) e não devem ser um dos namespaces específicos do SAML.

Com a extensão de mensagem do protocolo SAML, a resposta SAML se parece com o exemplo a seguir:

<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>

Exigir respostas SAML assinadas

O Azure AD B2C exige que todas as asserções de entrada sejam assinadas. Você pode remover esse requisito definindo WantsSignedAssertions como false. O provedor de identidade não deve assinar as asserções nesse caso, mas mesmo que assine, o Azure AD B2C não valida a assinatura.

Os metadados WantsSignedAssertions controlam o sinalizador de metadados SAML WantAssertionsSigned, que é incluído nos metadados do perfil técnico do Azure AD B2C compartilhado com o provedor de identidade.

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

Se você desabilitar a validação de asserções, talvez também queira desabilitar a validação de assinatura da mensagem de resposta. Defina os metadados ResponsesSigned como false. O provedor de identidade não deve assinar a mensagem de resposta SAML nesse caso, mas mesmo que isso aconteça, o Azure AD B2C não valida a assinatura.

O exemplo a seguir remove a mensagem e a assinatura de asserção:

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

Exigir respostas SAML criptografadas

Para exigir que todas as asserções recebidas sejam criptografadas, defina os metadados WantsEncryptedAssertions . Quando a criptografia é necessária, o provedor de identidade usa uma chave pública de um certificado de criptografia em um perfil técnico do Azure AD B2C. O Azure AD B2C descriptografa a declaração de resposta usando a parte privada do certificado de criptografia.

Se você habilitar a criptografia de asserções, talvez também seja necessário desabilitar a validação da assinatura de resposta (para obter mais informações, consulte Exigir respostas SAML assinadas.

Quando os metadados WantsEncryptedAssertions são definidos como true, os metadados do perfil técnico do Azure AD B2C incluem a seção de criptografia . O provedor de identidade lê os metadados e criptografa a declaração de resposta SAML com a chave pública fornecida nos metadados do perfil técnico do Azure AD B2C.

O exemplo a seguir mostra a seção Descritor de Chave dos metadados SAML usados para criptografia:

<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>

Para criptografar a asserção de resposta SAML:

Crie uma chave de política com um identificador exclusivo. Por exemplo, B2C_1A_SAMLEncryptionCert.
No perfil técnico SAML na coleção CryptographicKeys. Defina o StorageReferenceId como o nome da chave de política criada na primeira etapa. O SamlAssertionDecryption ID indica o uso da chave criptográfica para criptografar e descriptografar a afirmação da resposta SAML.
```
<CryptographicKeys>
        ...
  <Key Id="SamlAssertionDecryption" StorageReferenceId="B2C_1A_SAMLEncryptionCert"/>
</CryptographicKeys>
```

Defina os metadados do perfil técnico WantsEncryptedAssertions como true.

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

Atualize seu provedor de identidade com os novos metadados de perfil técnico do Azure AD B2C. Você deve ver o KeyDescriptor com a propriedade use definida como encryption contendo a chave pública do seu certificado.

Habilitar o uso de declarações de contexto

Na coleção de declarações de entrada e saída, pode-se incluir declarações que não são retornadas pelo provedor de identidade, desde que se defina o atributo DefaultValue. Você também pode usar declarações de contexto para serem incluídas no perfil técnico. Para usar uma declaração de contexto:

Adicione um tipo de declaração ao elemento ClaimsSchema em BuildingBlocks.

Adicione uma reivindicação de saída à coleção de entrada ou de saída. No seguinte exemplo, a primeira declaração define o valor do provedor de identidade. A segunda declaração usa o endereço IP do usuário nas declarações de contexto.

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

Desativar logout único

Após um pedido de encerramento de sessão da aplicação, o Azure AD B2C tenta encerrar a sessão do seu fornecedor de identidade SAML. Para obter mais informações, consulte Saída de sessão do Azure AD B2C. Para desativar o comportamento de logout único, defina os metadados SingleLogoutEnabled como false.

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

Depurar protocolo SAML

Para ajudar a configurar e depurar a federação com um provedor de identidade SAML, você pode usar uma extensão de navegador para o protocolo SAML, como a extensão SAML DevTools para Chrome, SAML-tracer para Firefox ou ferramentas de desenvolvedor do Microsoft Edge ou Internet Explorer.

Usando essas ferramentas, você pode verificar a integração entre o Azure AD B2C e seu provedor de identidade SAML. Por exemplo:

Verifique se a solicitação SAML contém uma assinatura e determine qual algoritmo é usado para entrar na solicitação de autorização.
Obtenha as reivindicações (asserções) na AttributeStatement seção.
Verifique se o provedor de identidade retorna uma mensagem de erro.
Verifique se a seção de asserção está criptografada.

Amostras de solicitação e resposta, SAML

O SAML (Security Assertion Markup Language) é um padrão aberto para a troca de dados de autenticação e autorização entre um provedor de identidade e um provedor de serviços. Quando o Azure AD B2C se federa com um provedor de identidade SAML, ele age como um provedor de serviços iniciando uma solicitação SAML para o provedor de identidade SAML e aguardando uma resposta SAML.

Uma resposta SAML de sucesso contém asserções de segurança que são declarações feitas pelos provedores de identidade SAML externos. O Azure AD B2C analisa e mapeia as asserções em declarações.

Pedido de autorização

Para solicitar uma autenticação de usuário, o Azure AD B2C envia um AuthnRequest elemento para o provedor de identidade SAML externo. Um exemplo de AuthnRequest SAML 2.0 pode ser semelhante ao exemplo a seguir:

<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>

Resposta

Quando um logon solicitado é concluído com êxito, o provedor de identidade SAML externo envia uma resposta para o ponto final de serviço ao consumidor de asserção do Azure AD B2C. Uma resposta a uma tentativa de logon bem-sucedida se parece com o exemplo a seguir:

<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>

Pedido de saída

Após um pedido de encerramento de sessão da aplicação, o Azure AD B2C tenta encerrar a sessão do seu fornecedor de identidade SAML. O Azure AD B2C envia uma LogoutRequest mensagem para o IDP externo para indicar que uma sessão foi encerrada. O trecho a seguir mostra um elemento de exemplo LogoutRequest .

O valor do elemento NameID corresponde ao NameID do utilizador que está a ser desconectado. O elemento SessionIndex corresponde ao atributo SessionIndex de AuthnStatement na resposta SAML de início de sessão.

<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>

Próximos passos

Saiba como diagnosticar problemas com suas políticas personalizadas usando o Application Insights.