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

Artigo
03/23/2023

AAD 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 as credenciais com um provedor de identidade SAML.

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

Esse recurso só está disponível para políticas personalizadas. Para obter as etapas de instalação, escolha Política personalizada no seletor anterior.

Mapeamento das declarações

O elementoOutputClaimscontém uma lista de declarações retornadas pelo provedor de identidade SAML. Talvez seja necessário mapear o nome da declaração definida em sua política para o nome definido no provedor de identidade. Verifique seu provedor de identidade da 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çãoe, em seguida, adicione a declaração à coleção de declarações de saída.

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

O elemento 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 é exibido na declaraçã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 um resolvedor de declaração com um valor contextual, como a ID de correlação ou o endereço IP do usuário.

Nome da entidade

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

Declaraçã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>

Declaração de saída:

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

Se ambos os atributos SPNameQualifier ou NameQualifier não forem apresentados na declaração SAML, defina a declaração PartnerClaimType como assertionSubjectName. Verifique se o NameId é o primeiro valor na declaração XML. Quando definir mais de uma asserção, o Azure AD B2C escolherá o valor do assunto da última declaração.

Configurar associações de protocolo SAML

As solicitações SAML são enviadas para o provedor de identidade conforme especificado no elemento SingleSignOnService de metadados 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 da URL de uma solicitação HTTP GET (pois as mensagens são relativamente curtas). Consulte a documentação do provedor de identidade para saber como configurar as associações para as duas solicitações SAML.

O XML a seguir é um exemplo de serviço de logon único de metadados do Microsoft Entra com duas associações. HTTP-Redirect tem precedência sobre HTTP-POST por aparecer 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 declaração do consumidor

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

O seguinte XML é um exemplo de um elemento do serviço do consumidor de declaração de metadados da 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 de criptografia SamlMessageSigning. Para desabilitar a assinatura de solicitação SAML, defina WantsSignedRequests como false. Se os metadados forem definidos como false, os parâmetros SigAlg e Signature (cadeia de caracteres de consulta ou parâmetro de postagem) serão omitidos da solicitação.

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

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). Esse metadado controla o valor do parâmetro SigAlg (cadeia de caracteres de consulta ou parâmetro de postagem) na solicitação SAML. Certifique-se de configurar o algoritmo de assinatura em ambos os lados com o mesmo valor. Use apenas o algoritmo com suporte do seu certificado.

Incluir informações de chave

Quando o provedor de identidade indica que a associação do Azure AD B2C é 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 a ID do Microsoft Entra para incluir a chave pública do certificado quando a associação é definida como HTTP-POST. Use os metadados IncludeKeyInfo como true ou false. No exemplo a seguir, a ID do Microsoft Entra não inclui a chave pública do certificado.

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

Configurar ID do nome da solicitação SAML

O elemento <NameID> de solicitação de 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 usuário preferencial

Durante um percurso do usuário de entrada, um aplicativo de terceira parte confiável pode ser direcionado a um nome de usuário. 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 no Subject da solicitação de autorização SAML.

Para incluir a ID de nome da entidade na solicitação de autorização, adicione o seguinte elemento <InputClaims> 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 no Subject 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 ID do nome

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

Para mudar este comportamento, consulte a documentação do provedor de identidade para obter orientação sobre qual nome há suporte para políticas de ID. Em seguida, adicione os metadados NameIdPolicyFormat no formato da política correspondente. Por exemplo:

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

A solicitação de autorização SAML a seguir contém a política de ID 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 de política de ID de nome, também poderá especificar a propriedade AllowCreate 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 provedor de identidade das diretrizes.

O Azure AD B2C omite a propriedade AllowCreate por padrão. Você pode alterar esse comportamento usando os metadados NameIdPolicyAllowCreate. 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

É possível pode forçar o IDP SAML externo a solicitar a autenticação do usuário passando a propriedade ForceAuthN na solicitação de autenticação SAML. Seu provedor de identidade também deve dar suporte a essa propriedade.

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

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

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

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

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

Nome do provedor

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

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

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

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

Incluir referências de classe 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 deve apresentar ao usuário.

Para configurar as referências de classe de contexto de autenticação, adicione os metadados IncludeAuthnContextClassReferences. No valor, especifique uma ou mais referências de URI que identifica as classes de contexto de autenticação. Especifique vários URIs como uma lista delimitada por vírgulas. Consulte a documentação do 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 solicitação de autorização SAML a seguir contém as referências de 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 no formato XML. Você inclui elementos de extensão adicionando dados XML dentro do elemento CDATA <![CDATA[Your Custom XML]]>. Verifique a documentação do provedor de identidade para ver se o elemento de extensões é suportado.

O exemplo a seguir ilustra o uso dos 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 por namespace (por exemplo, 'urn:ext:custom' mostrados 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 será parecida 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 requer que todas as declarações de entrada sejam assinadas. Você pode remover esse requisito definindo o WantsSignedAssertions como false. O provedor de identidade não deve assinar as afirmações neste caso, mas caso isso ocorra, o Azure AD B2C não valida a assinatura.

Esses metadados WantsSignedAssertions controlam o sinalizador de metadados SAML WantAssertionsSigned, que é incluído nos metadados do perfil técnico do Azure AD B2C que é 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 declarações, também deverá desabilitar a validação de assinatura de mensagem de resposta. Defina os metadados de ResponsesSigned para false. O provedor de identidade não deve assinar a mensagem de resposta SAML neste caso, mas caso isso ocorra, o Azure AD B2C não valida a assinatura.

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

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

Exigir respostas SAML criptografadas

Para exigir que todas as declarações de entrada 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 declarações, também precisará desabilitar a validação de assinatura de resposta (para obter mais informações, consulteExigir respostas SAML assinadas.

Quando o metadado WantsEncryptedAssertions é definido como true, os metadados do perfil técnico do Azure AD B2C incluirão 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 que é 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 declaração de resposta SAML:

Crie uma chave de política com um identificador exclusivo. Por exemplo, B2C_1A_SAMLEncryptionCert.
Em sua coleção de CryptographicKeys de perfil técnico do SAML. Defina StorageReferenceId para o nome da chave de política que você criou na primeira etapa. A ID SamlAssertionDecryption indica o uso da chave de criptografia para criptografar e descriptografar a declaração da resposta SAML.
```
<CryptographicKeys>
        ...
  <Key Id="SamlAssertionDecryption" StorageReferenceId="B2C_1A_SAMLEncryptionCert"/>
</CryptographicKeys>
```

Defina os metadados do perfil técnico WantsEncryptedAssertions para 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 KeyDescriptor com a propriedade use definida como encryption contendo a chave pública do certificado.

Habilitar o uso de declarações de contexto

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

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

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

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

Desabilitar logoff único

Após uma solicitação para sair do aplicativo, o Azure AD B2C tenta sair do seu provedor de identidade SAML. Para obter mais informações, consulte Sair da sessão do Azure AD B2C. Para desabilitar o comportamento de logoff único, defina os metadados SingleLogoutEnabled como false.

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

Depurar o protocolo SAML

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

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 declarações na seção AttributeStatement.
Verifique se o provedor de identidade retorna uma mensagem de erro.
Verifique se a seção de declaração está criptografada.

Exemplos de solicitação e resposta SAML

Security Assertion Markup Language (SAML) é 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 AAD B2C confedere-se junto de um provedor de identidade SAML, ele atua comoprovedor de serviços iniciando uma solicitação SAML provedor de identidade e aguardando uma resposta SAML.

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

Solicitação de autorização

Para solicitar uma autenticação de usuário, o Azure AD B2C envia um elemento AuthnRequest para o provedor de identidade SAML externo. Um exemplo de SAML 2.0 AuthnRequest teria a seguinte a aparência:

<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 posta uma resposta para o ponto de extremidade de serviço do consumidor de declaração do Azure AD B2C. Uma resposta para uma tentativa de logon bem-sucedida se parece com este exemplo:

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

Solicitação de logoff

Após uma solicitação para sair do aplicativo, o Azure AD B2C tenta sair do seu provedor de identidade SAML. O Azure AD B2C envia uma mensagem LogoutRequest ao IDP externo para indicar que uma sessão foi encerrada. O trecho a seguir mostra um exemplo de elemento LogoutRequest .

O valor do elemento NameID corresponde ao NameID do usuário que está sendo desconectado. O elemento SessionIndex corresponde ao SessionIndex atributo de AuthnStatement na resposta SAML de credenciais.

<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óximas etapas

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

Compartilhar via