Partilhar via

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

  • Artigo

O Azure Active Directory B2C (Azure AD B2C) suporta a federação com fornecedores de identidade SAML 2.0. Este artigo descreve como analisar as afirmações de segurança e as opções de configuração disponíveis ao ativar o início de sessão com um fornecedor de identidade SAML.

Antes de começar, utilize o seletor Escolher um tipo de política para escolher o tipo de política que está a configurar. O Azure Active Directory B2C oferece dois métodos para definir a forma como os utilizadores interagem com as suas aplicações: através de fluxos de utilizador predefinidos ou através de políticas personalizadas totalmente configuráveis. Os passos necessários neste artigo são diferentes para cada método.

Esta funcionalidade só está disponível para políticas personalizadas. Para obter os passos de configuração, selecione Política personalizada no seletor anterior.

Mapeamento de afirmações

O elemento OutputClaims contém uma lista de afirmações devolvidas pelo fornecedor de identidade SAML. Tem de mapear o nome da afirmação definida na sua política para o nome definido no fornecedor de identidade. Verifique o fornecedor de identidade para obter a lista de afirmações (asserções). Também pode verificar o conteúdo da resposta SAML que o seu fornecedor de identidade devolve. Para obter mais informações, veja Depurar as mensagens SAML. Para adicionar uma afirmação, primeiro defina uma afirmação e, em seguida, adicione a afirmação à coleção de afirmações de saída.

Também pode incluir afirmações que não são devolvidas pelo fornecedor de identidade, desde que defina o DefaultValue atributo. O valor predefinido pode ser estático ou dinâmico, utilizando afirmações de contexto.

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

  • ClaimTypeReferenceId é a referência a um tipo de afirmação.
  • PartnerClaimType é o nome da propriedade que aparece como asserção SAML.
  • DefaultValue é um valor predefinido predefinido. Se a afirmação estiver vazia, será utilizado o valor predefinido. Também pode utilizar uma resolução de afirmações com um valor contextual, como o ID de correlação ou o endereço IP do utilizador.

Nome do requerente

Para ler o NameId de afirmação SAML no Assunto como uma afirmação normalizada, defina a afirmação PartnerClaimType como o valor do SPNameQualifier atributo. Se o SPNameQualifieratributo não for apresentado, defina a afirmação PartnerClaimType para o valor do NameQualifier atributo.

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

Afirmação de saída:

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

Se ambos os SPNameQualifier atributos ou NameQualifier não forem apresentados na asserção SAML, defina a afirmação PartnerClaimType como assertionSubjectName. Certifique-se de que o NameId é o primeiro valor no XML de asserção. Quando define mais do que uma afirmação, Azure AD B2C escolhe o valor do assunto da última afirmação.

Configurar enlaces de protocolo SAML

Os pedidos SAML são enviados para o fornecedor de identidade, conforme especificado no elemento de metadados SingleSignOnService do fornecedor de identidade. A maioria dos pedidos de autorização dos fornecedores de identidade são transportados diretamente na cadeia de consulta de URL de um pedido HTTP GET (uma vez que as mensagens são relativamente curtas). Veja a documentação do fornecedor de identidades sobre como configurar os enlaces para ambos os pedidos SAML.

O XML seguinte é um exemplo de um serviço de início de sessão único de metadados Microsoft Entra com dois enlaces. O HTTP-Redirect tem precedência sobre o HTTP-POST porque aparece primeiro nos metadados do fornecedor 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 consumidor de Asserção

O Assertion Consumer Service (ou ACS) é onde as respostas SAML do fornecedor de identidade são enviadas e recebidas por Azure AD B2C. As respostas SAML são transmitidas para Azure AD B2C através do enlace HTTP POST. A localização ACS aponta para a política base da entidade confiadora. Por exemplo, se a política confiadora for B2C_1A_signup_signin, o ACS é a política base do B2C_1A_signup_signin, como B2C_1A_TrustFrameworkBase.

O XML seguinte é um exemplo de um elemento de serviço de consumidor Azure AD de metadados de política 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 do pedido SAML

Azure AD B2C assina todos os pedidos de autenticação de saída com a chave criptográfica SamlMessageSigning. Para desativar a assinatura do pedido SAML, defina WantSignedRequests como false. Se os metadados estiverem definidos como false, os parâmetros SigAlg e Signature (cadeia de consulta ou parâmetro post) são omitidos do pedido.

Estes metadados também controlam o atributo AuthnRequestsSigned, que está incluído com os metadados da Azure AD perfil técnico B2C que é partilhado com o fornecedor de identidade. Azure AD B2C não assinará o pedido se o valor de WantSignedRequests nos metadados do perfil técnico estiver definido como false e os metadados do fornecedor de identidade WantAuthnRequestsSigned estiverem definidos como false ou não especificados.

O exemplo seguinte remove a assinatura do pedido SAML.

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

Algoritmo de assinatura

Azure AD B2C utiliza Sha1 para assinar o pedido SAML. Utilize os metadados XmlSignatureAlgorithm para configurar o algoritmo a ser utilizado. Os valores possíveis são Sha256, Sha384, Sha512ou Sha1 (predefinição). Estes metadados controlam o valor do parâmetro SigAlg (cadeia de consulta ou pós-parâmetro) no pedido SAML. Certifique-se de que configura o algoritmo de assinatura em ambos os lados com o mesmo valor. Utilize apenas o algoritmo suportado pelo certificado.

Incluir informações de chave

Quando o fornecedor de identidade indica que Azure AD enlace B2C está definido como HTTP-POST, Azure AD B2C inclui a assinatura e o algoritmo no corpo do pedido SAML. Também pode configurar Microsoft Entra ID para incluir a chave pública do certificado quando o enlace estiver definido como HTTP-POST. Utilize os metadados IncludeKeyInfo para true, ou false. No exemplo seguinte, Microsoft Entra ID não inclui a chave pública do certificado.

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

Configurar o ID do nome do pedido SAML

O elemento de pedido <NameID> de autorização SAML indica o formato de identificador de nome SAML. Esta secção descreve a configuração predefinida e como personalizar o elemento de ID de nome.

Nome de utilizador preferencial

Durante um percurso de início de sessão do utilizador, uma aplicação de entidade confiadora pode visar um utilizador específico. Azure AD B2C permite-lhe enviar um nome de utilizador preferencial para o fornecedor de identidade SAML. O elemento InputClaims é utilizado para enviar um NameId no Assunto do pedido de autorização SAML.

Para incluir o ID do nome do requerente no pedido de autorização, adicione o seguinte <InputClaims> elemento imediatamente após o <CryptographicKeys>. O PartnerClaimType tem de estar definido como subject.

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

Neste exemplo, Azure AD B2C envia o valor da afirmação signInName com NameId no Assunto do pedido de autorização SAML.

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

Pode utilizar afirmações de contexto, como {OIDC:LoginHint} preencher o valor da afirmaçã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 de nome

Por predefinição, o pedido de autorização SAML especifica a urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified política. Este ID de nome indica que qualquer tipo de identificador suportado pelo fornecedor de identidade para o requerente pedido pode ser utilizado.

Para alterar este comportamento, consulte a documentação do fornecedor de identidade para obter orientações sobre as políticas de ID de nome 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 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 especificar o formato de política ID de Nome, também pode especificar a AllowCreate propriedade nameIDPolicy para indicar se o fornecedor de identidade tem permissão para criar uma nova conta durante o fluxo de início de sessão. Consulte a documentação do seu fornecedor de identidade para obter orientações.

Azure AD B2C omite a AllowCreate propriedade por predefinição. Pode alterar este comportamento com os NameIdPolicyAllowCreate metadados. O valor destes metadados é true ou false.

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

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

O exemplo seguinte demonstra um pedido de autorização com AllowCreate do elemento NameIDPolicy no pedido 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

Pode forçar o IDP SAML externo a pedir autenticação ao utilizador ao transmitir a ForceAuthN propriedade no pedido de autenticação SAML. O seu fornecedor de identidade também tem de suportar esta propriedade.

A ForceAuthN propriedade é booleana true ou false valor. Por predefinição, Azure AD B2C define o valor ForceAuthN como false. Se a sessão for reposta (por exemplo, com o prompt=login no OIDC), o ForceAuthN valor será definido como true. Definir os ForceAuthN metadados para true forçar o valor de todos os pedidos para o IDP externo.

O exemplo seguinte mostra a ForceAuthN propriedade definida como true:

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

O exemplo seguinte mostra a ForceAuthN propriedade num pedido de autorização:

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

Nome do fornecedor

Opcionalmente, pode incluir o ProviderName atributo no pedido de autorização SAML. Defina os ProviderName metadados para incluir o nome do fornecedor para todos os pedidos para o IDP SAML externo. O exemplo seguinte mostra a ProviderName propriedade definida como Contoso app:

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

O exemplo seguinte mostra a ProviderName propriedade num pedido de autorização:

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

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

Um pedido de autorização SAML pode conter um elemento AuthnContext , que especifica o contexto de um pedido de autorização. O elemento pode conter uma referência de classe de contexto de autenticação, que indica ao fornecedor de identidade SAML qual o mecanismo de autenticação a apresentar ao utilizador.

Para configurar as referências da classe de contexto de autenticação, adicione metadados 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írgulas. Veja a documentação do seu fornecedor de identidade para obter orientações sobre os URIs AuthnContextClassRef suportados.

O exemplo seguinte permite que os utilizadores iniciem sessão com o nome de utilizador e a palavra-passe e iniciem sessão com o nome de utilizador e a palavra-passe numa 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>

O seguinte pedido de autorização SAML contém as referências da 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 no pedido de autorização

Opcionalmente, pode incluir elementos de extensão de mensagens de protocolo que são acordados tanto pelo Azure AD B2C como pelo seu fornecedor de identidade. A extensão é apresentada no formato XML. Pode incluir elementos de extensão ao adicionar dados XML dentro do elemento <![CDATA[Your Custom XML]]>CDATA . Verifique a documentação do seu fornecedor de identidade para ver se o elemento extensions é suportado.

O exemplo seguinte ilustra a utilização 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>

Nota

De acordo com a especificação SAML, os dados da extensão têm de ser XML qualificado para espaço de nomes (por exemplo, "urn:ext:custom" mostrado no exemplo) e não podem ser um dos espaços de nomes específicos de SAML.

Com a extensão de mensagem de protocolo SAML, a resposta SAML é semelhante ao 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

Azure AD B2C requer que todas as asserções recebidas sejam assinadas. Pode remover este requisito ao definir WantSignedAssertions como false. O fornecedor de identidade não deve assinar as asserções neste caso, mas mesmo que o faça, Azure AD B2C não valida a assinatura.

Os metadados WantSignedAssertions controlam o sinalizador de metadados SAML WantAssertionsSigned, que está incluído nos metadados do perfil técnico Azure AD B2C que é partilhado com o fornecedor de identidade.

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

Se desativar a validação de asserções, também poderá querer desativar a validação da assinatura da mensagem de resposta. Defina os metadados ResponsesSigned como false. O fornecedor de identidade não deve assinar a mensagem de resposta SAML neste caso, mas mesmo que o faça, Azure AD B2C não valida a assinatura.

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

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

Exigir respostas SAML encriptadas

Para exigir que todas as asserções recebidas sejam encriptadas, defina os metadados WantEncryptedAssertions . Quando a encriptação é necessária, o fornecedor de identidade utiliza uma chave pública de um certificado de encriptação num perfil técnico Azure AD B2C. Azure AD B2C desencripta a asserção de resposta com a parte privada do certificado de encriptação.

Se ativar a encriptação de asserções, também poderá ter de desativar a validação da assinatura de resposta (para obter mais informações, veja Exigir respostas SAML assinadas.

Quando os metadados WantEncryptedAssertions estão definidos como true, os metadados do perfil técnico Azure AD B2C incluem a secção de encriptação. O fornecedor de identidade lê os metadados e encripta a asserção de resposta SAML com a chave pública fornecida nos metadados do perfil técnico Azure AD B2C.

O exemplo seguinte mostra a secção Descritor de Chaves dos metadados SAML utilizados para encriptação:

<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 encriptar a asserção da resposta SAML:

  1. Crie uma chave de política com um identificador exclusivo. Por exemplo, B2C_1A_SAMLEncryptionCert.

  2. Na coleção CryptographicKeys do perfil técnico SAML. Defina StorageReferenceId como o nome da chave de política que criou no primeiro passo. O SamlAssertionDecryption ID indica a utilização da chave criptográfica para encriptar e desencriptar a asserção da resposta SAML.

    <CryptographicKeys>
        ...
  <Key Id="SamlAssertionDecryption" StorageReferenceId="B2C_1A_SAMLEncryptionCert"/>
</CryptographicKeys>

  3. Defina os metadados do perfil técnico WantEncryptedAssertions como true.

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

  4. Atualize o seu fornecedor de identidade com os novos metadados do perfil técnico do Azure AD B2C. Deverá ver o KeyDescriptor com a propriedade use definida para encryption conter a chave pública do certificado.

Ativar a utilização de afirmações de contexto

Na coleção de afirmações de entrada e saída, pode incluir afirmações que não são devolvidas pelo fornecedor de identidade, desde que defina o DefaultValue atributo. Também pode utilizar afirmações de contexto para serem incluídas no perfil técnico. Para utilizar uma afirmação de contexto:

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

  2. Adicione uma afirmação de saída à coleção de entrada ou saída. No exemplo seguinte, a primeira afirmação define o valor do fornecedor de identidade. A segunda afirmação utiliza as afirmações de contexto do endereço IP do utilizador.

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

Desativar a fim de sessão único

Após um pedido de fim de sessão da aplicação, Azure AD B2C tenta terminar sessão no seu fornecedor de identidade SAML. Para obter mais informações, veja Azure AD início de sessão B2C. Para desativar o comportamento de fim de sessão ú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 fornecedor de identidade SAML, pode utilizar uma extensão de browser para o protocolo SAML, como a extensão SAML DevTools para Chrome, SAML-tracer para FireFox ou Microsoft Edge ou IE Ferramentas de programação.

Com estas ferramentas, pode verificar a integração entre Azure AD B2C e o seu fornecedor de identidade SAML. Por exemplo:

  • Verifique se o pedido SAML contém uma assinatura e determine que algoritmo é utilizado para iniciar sessão no pedido de autorização.
  • Obtenha as afirmações (asserções) na AttributeStatement secção .
  • Verifique se o fornecedor de identidade devolve uma mensagem de erro.
  • Verifique se a secção de asserção está encriptada.

Exemplos de pedidos e respostas SAML

O Security Assertion Markup Language (SAML) é um padrão aberto para troca de autenticações e dados de autenticação entre um fornecedor de identidade e um fornecedor de serviço. Quando Azure AD federações B2C com um fornecedor de identidade SAML, atua como um fornecedor de serviços que inicia um pedido SAML ao fornecedor de identidade SAML e aguarda uma resposta SAML.

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

Pedido de autorização

Para pedir uma autenticação de utilizador, Azure AD B2C envia um AuthnRequest elemento para o fornecedor de identidade SAML externo. Um SAML 2.0 AuthnRequest de exemplo pode ter o seguinte aspeto:

<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 início de sessão pedido é concluído com êxito, o fornecedor de identidade SAML externo publica uma resposta ao Azure AD ponto final de serviço de consumidor de asserção B2C. Uma resposta a uma tentativa de início de sessão bem-sucedida tem o seguinte aspeto:

<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 fim de sessão

Após um pedido de fim de sessão da aplicação, Azure AD B2C tenta terminar sessão no seu fornecedor de identidade SAML. Azure AD B2C envia uma LogoutRequest mensagem para o IDP externo para indicar que uma sessão foi terminada. O seguinte excerto mostra um elemento de exemplo LogoutRequest .

O valor do NameID elemento corresponde ao NameID do utilizador que está a ter sessão iniciada. O SessionIndex elemento corresponde ao SessionIndex atributo de na resposta SAML de AuthnStatement 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>

Passos seguintes

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