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

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 em nossas perguntas frequentes.

O Azure AD B2C (Azure Active Directory 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 Escolher um tipo de política na parte superior desta página 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 está disponível apenas para políticas personalizadas. Para as etapas de instalação, selecione Política personalizada no seletor anterior.

Mapeamento de declarações

O elemento OutputClaims contém uma lista de declarações retornadas pelo provedor de identidade SAML. Você precisa mapear o nome da reivindicação definida em sua política para o nome definido no provedor de identidade. Verifique com seu provedor de identidade a lista de reivindicações (afirmações). Você também pode verificar o conteúdo da resposta SAML retornada pelo provedor de identidade. Para obter mais informações, consulte Depurar as mensagens SAML. Para adicionar uma declaração, primeiro defina uma declaração e 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 você defina o DefaultValue atributo. 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ção com um valor contextual, como a ID de correlação ou o endereço IP do usuário.

Nome da entidade

Para ler a asserção SAML NameId no Sujeito como declarações normalizadas, defina a declaração PartnerClaimType como o valor do atributo SPNameQualifier. Se o SPNameQualifier atributo não for apresentado, defina a reivindicação PartnerClaimType para o 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 SPNameQualifier ou NameQualifier atributos não forem apresentados na declaração SAML, defina a declaração PartnerClaimType como assertionSubjectName. Verifique se o NameId é o primeiro valor em XML de asserção. Quando você define mais de uma asserção, o Azure AD B2C escolhe o valor de assunto da última asserção.

Configurar associaçõ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 é realizada diretamente na cadeia 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>

Afirmação de serviço ao consumidor

O Assertion Consumer Service (ou ACS) é o local 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. A localização do ACS aponta para a política base da sua parte confiável. Por exemplo, se a política de confiança for B2C_1A_signup_signin, o ACS é 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 (cadeia de caracteres de consulta ou pós-parâmetro) serão omitidos da solicitação.

Esses metadados também controlam o atributo AuthnRequestsSigned , que é 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 assinará a solicitação se o valor de WantsSignedRequests nos metadados do perfil técnico estiver configurado como false e os metadados do provedor de identidade WantAuthnRequestsSigned estiverem configurados 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ãoSha256, ou Sha384Sha512Sha1 (padrão). Esses metadados controlam o valor do parâmetro SigAlg (string 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-chave

Quando o provedor de identidade indica que a associação do Azure AD B2C está definida 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 for definida como HTTP-POST. Utilize o metadado IncludeKeyInfo para 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 o ID do nome da solicitação SAML

O elemento de solicitação <NameID> 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 a jornada de login do usuário, um aplicativo de terceira parte confiável pode ter como alvo um usuário 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 uma NameId dentro do Assunto da solicitação de autorização SAML.

Para incluir a ID do nome do sujeito dentro da solicitação de autorização, adicione o 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 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. Este identificador de nome indica que qualquer tipo de identificador suportado pelo provedor de identidade para o assunto solicitado pode ser utilizado.

Para alterar esse comportamento, consulte a documentação do provedor de identidade para obter diretrizes sobre quais políticas de ID de nome têm suporte. Em seguida, adicione o metadado NameIdPolicyFormat no formato de política correspondente. Por exemplo:

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

A seguinte solicitação de autorização SAML 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 da política de ID de nome, também poderá especificar a AllowCreatepropriedade NameIDPolicy para indicar se o provedor de identidade tem permissão para criar uma nova conta durante o fluxo de logon. Consulte a documentação do provedor de identidade para obter diretrizes.

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 autenticação ao usuário passando a propriedade ForceAuthN na solicitação de autenticação SAML. Seu provedor de identidade também deve oferecer suporte a essa propriedade.

A propriedade ForceAuthN é um valor true booleano 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), então o valor ForceAuthN será definido como true. Definir os metadados ForceAuthN como true força o valor de 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 provedor

Opcionalmente, você pode incluir o ProviderName atributo na solicitação de autorização SAML. Defina os ProviderName metadados para incluir o nome do provedor para 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 da classe de contexto de autenticação, adicione os metadados IncludeAuthnContextClassReferences. No valor, especifique uma ou mais referências de URI que identificam 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 diretrizes sobre as URIs AuthnContextClassRef com suporte.

O exemplo a seguir permite que os usuários entrem com nome de usuário e senha e entrem com o nome de usuário e a 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 às classes do 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[Your Custom XML]]>CDATA. Verifique a documentação do provedor de identidade para ver se o elemento de extensões tem suporte.

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 de protocolo SAML, a resposta SAML se parece com o seguinte exemplo:

<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 declarações nesse caso, mas mesmo que isso ocorra, o Azure AD B2C não valida a assinatura.

Os metadados WantsSignedAssertions controlam o sinalizador de metadados SAML WantAssertionsSigned, que está 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 declarações, também poderá desabilitar a validação da assinatura da mensagem de resposta. Defina o metadado ResponsesSigned para false. O provedor de identidade não deve assinar a mensagem de resposta SAML nesse caso, mas mesmo que isso ocorra, 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 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, 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 declaração de resposta SAML:

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

Defina os metadados de 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 para que encryption contenha 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, você pode incluir declarações que não são retornadas pelo provedor de identidade, desde que você defina o DefaultValue atributo. 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 no BuildingBlocks.

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

<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 de saída do aplicativo, o Azure AD B2C tenta sair do seu provedor de identidade SAML. Para obter mais informações, veja Sair da sessão do Azure AD B2C. Para desabilitar 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, o rastreamento SAML para Firefox ou as 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 (afirmações) na seção AttributeStatement.
Verifique se o provedor de identidade retorna uma mensagem de erro.
Verifique se a seção asserção está criptografada.

Exemplos de solicitações e respostas 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 Azure AD B2C federa com um provedor de identidade SAML, ele atua 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 bem-sucedida 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.

Solicitação 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 sucesso, o provedor de identidade SAML externo publica uma resposta no ponto de extremidade do serviço de consumidor de asserção do Azure AD B2C. Uma resposta a uma tentativa de logon bem-sucedida se parece com o seguinte 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 logout

Após uma solicitação de saída do aplicativo, o Azure AD B2C tenta sair do seu provedor 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 usuário que está sendo desconectado. O elemento SessionIndex corresponde ao atributo SessionIndex de AuthnStatement na resposta SAML de login.

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

Comentários

Esta página foi útil?

Last updated on 2025-05-06