Opções para registrar um aplicativo SAML no Azure AD B2C

Este artigo descreve as opções de configuração que estão disponíveis ao conectar o Azure Active Directory B2C (Azure AD B2C) com o aplicativo SAML (Security Assertion Markup Language).

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.

Especificar uma assinatura de resposta SAML

Você pode especificar um certificado a ser usado para assinar as mensagens SAML. A mensagem é o elemento <samlp:Response> dentro da resposta SAML enviada ao aplicativo.

Se você ainda não tiver uma chave de política, crie uma. Em seguida, configure o item de metadados SamlMessageSigning no perfil técnico do Emissor do Token SAML. O StorageReferenceId deve referenciar o nome da chave de política.

<ClaimsProvider>
  <DisplayName>Token Issuer</DisplayName>
  <TechnicalProfiles>
    <!-- SAML Token Issuer technical profile -->
    <TechnicalProfile Id="Saml2AssertionIssuer">
      <DisplayName>Token Issuer</DisplayName>
      <Protocol Name="SAML2"/>
      <OutputTokenFormat>SAML2</OutputTokenFormat>
        ...
      <CryptographicKeys>
        <Key Id="SamlMessageSigning" StorageReferenceId="B2C_1A_SamlMessageCert"/>
        ...
      </CryptographicKeys>
    ...
    </TechnicalProfile>

Algoritmo de assinatura

Você pode configurar o algoritmo de assinatura que é usado para assinar a declaração SAML. Os valores possíveis são Sha256, Sha384, Sha512 ou Sha1. Verifique se o perfil técnico e o aplicativo usam o mesmo algoritmo de assinatura. Use apenas o algoritmo com suporte do seu certificado.

Configure o algoritmo de assinatura usando a chave de metadados XmlSignatureAlgorithm dentro do elemento de Metadata da terceira parte confiável.

<RelyingParty>
  <DefaultUserJourney ReferenceId="SignUpOrSignIn" />
  <TechnicalProfile Id="PolicyProfile">
    <DisplayName>PolicyProfile</DisplayName>
    <Protocol Name="SAML2"/>
    <Metadata>
      <Item Key="XmlSignatureAlgorithm">Sha256</Item>
    </Metadata>
   ..
  </TechnicalProfile>
</RelyingParty>

Verificar a assinatura de asserção SAML

Quando seu aplicativo espera que a seção de declaração SAML seja assinada, verifique se o provedor de serviços SAML definiu WantAssertionsSigned como true. Se estiver definido como false, ou não existir, a seção de declaração não será assinada.

O exemplo a seguir mostra os metadados para um provedor de serviços SAML com o WantAssertionsSigned definido como true.

<EntityDescriptor ID="id123456789" entityID="https://samltestapp2.azurewebsites.net" validUntil="2099-12-31T23:59:59Z" xmlns="urn:oasis:names:tc:SAML:2.0:metadata">
  <SPSSODescriptor WantAssertionsSigned="true" AuthnRequestsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
  ...
  </SPSSODescriptor>
</EntityDescriptor>

Certificado de assinatura

Sua política deve especificar um certificado a ser usado para assinar a seção de declarações SAML da resposta SAML. Se você ainda não tiver uma chave de política, crie uma. Em seguida, configure o item de metadados SamlAssertionSigning no perfil técnico do Emissor do Token SAML. O StorageReferenceId deve referenciar o nome da chave de política.

<ClaimsProvider>
  <DisplayName>Token Issuer</DisplayName>
  <TechnicalProfiles>
    <!-- SAML Token Issuer technical profile -->
    <TechnicalProfile Id="Saml2AssertionIssuer">
      <DisplayName>Token Issuer</DisplayName>
      <Protocol Name="SAML2"/>
      <OutputTokenFormat>SAML2</OutputTokenFormat>
        ...
      <CryptographicKeys>
        <Key Id="SamlAssertionSigning" StorageReferenceId="B2C_1A_SamlMessageCert"/>
        ...
      </CryptographicKeys>
    ...
    </TechnicalProfile>

Habilitar a criptografia em asserções SAML

Quando seu aplicativo espera que as declarações SAML estejam em um formato criptografado, certifique-se de que a criptografia esteja habilitada na política do Azure AD B2C.

O Azure AD B2C usa o certificado da chave pública do provedor de serviços para criptografar a declaração SAML. A chave pública deve existir no ponto de extremidade de metadados do aplicativo SAML com valor KeyDescriptoruse definido como Encryption, conforme mostrado no seguinte exemplo:

<KeyDescriptor use="encryption">
  <KeyInfo xmlns="https://www.w3.org/2000/09/xmldsig#">
    <X509Data>
      <X509Certificate>valid certificate</X509Certificate>
    </X509Data>
  </KeyInfo>
</KeyDescriptor>

Para permitir que o Azure AD B2C envie declarações criptografadas, defina o item de metadados WantsEncryptedAssertion como true no perfil técnico de terceira parte confiável. Você também pode configurar o algoritmo usado para criptografar a declaração SAML.

<RelyingParty>
  <DefaultUserJourney ReferenceId="SignUpOrSignIn" />
  <TechnicalProfile Id="PolicyProfile">
    <DisplayName>PolicyProfile</DisplayName>
    <Protocol Name="SAML2"/>
    <Metadata>
      <Item Key="WantsEncryptedAssertions">true</Item>
    </Metadata>
   ..
  </TechnicalProfile>
</RelyingParty>

Método de criptografia

Para configurar o método de criptografia que é usado para criptografar os dados de declaração SAML, defina a chave de metadados DataEncryptionMethod na terceira parte confiável. Os valores possíveis são Aes256 (padrão), Aes192, Sha512 ou Aes128. Os metadados controlam o valor do elemento <EncryptedData> na resposta SAML.

Para configurar o método de criptografia para criptografar a cópia da chave que foi usada para criptografar os dados de declaração SAML, defina a chave de metadados KeyEncryptionMethod na terceira parte confiável. Os valores possíveis são:

  • Rsa15(padrão): algoritmo Criptografia por Chave pública Padrão (PKCS) do RSA versão 1.5.
  • RsaOaep: Algoritmo de criptografia de Preenchimento de Criptografia Assimétrica ideal (OAEP) do RSA.

Os metadados controlam o valor do elemento <EncryptedKey> na resposta SAML.

O exemplo a seguir mostra a seção EncryptedAssertion de uma declaração SAML. O método de dados criptografados é Aes128 e o método de chave criptografada é Rsa15.

<saml:EncryptedAssertion>
  <xenc:EncryptedData xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
    xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" Type="http://www.w3.org/2001/04/xmlenc#Element">
    <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc" />
    <dsig:KeyInfo>
      <xenc:EncryptedKey>
        <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5" />
        <xenc:CipherData>
          <xenc:CipherValue>...</xenc:CipherValue>
        </xenc:CipherData>
      </xenc:EncryptedKey>
    </dsig:KeyInfo>
    <xenc:CipherData>
      <xenc:CipherValue>...</xenc:CipherValue>
    </xenc:CipherData>
  </xenc:EncryptedData>
</saml:EncryptedAssertion>

Você pode alterar o formato das asserções criptografadas. Para configurar o formato de criptografia, defina a chave de metadados UseDetachedKeys na terceira parte confiável. Valores possíveis: true ou false (padrão). Quando o valor é definido como true, as chaves desanexadas adicionam a declaração criptografada como um filho do EncryptedAssertion em vez de EncryptedData.

Configure o método e o formato de criptografia usando as chaves de metadados dentro do perfil técnico de terceira parte confiável:

<RelyingParty>
  <DefaultUserJourney ReferenceId="SignUpOrSignIn" />
  <TechnicalProfile Id="PolicyProfile">
    <DisplayName>PolicyProfile</DisplayName>
    <Protocol Name="SAML2"/>
    <Metadata>
      <Item Key="DataEncryptionMethod">Aes128</Item>
      <Item Key="KeyEncryptionMethod">Rsa15</Item>
      <Item Key="UseDetachedKeys">false</Item>
    </Metadata>
   ..
  </TechnicalProfile>
</RelyingParty>

Configurar o fluxo iniciado pelo IdP

Quando seu aplicativo espera receber uma declaração SAML sem primeiro enviar uma solicitação SAML AuthN para o provedor de identidade (IdP), você deve configurar o Azure AD B2C para o fluxo iniciado pelo IdP.

No fluxo iniciado pelo IdP, o provedor de identidade (Azure AD B2C) inicia o processo de entrada. O provedor de identidade envia uma resposta SAML não solicitada ao provedor de serviço (seu aplicativo de terceira parte confiável).

No momento, não há suporte para cenários em que o provedor de identidade inicial é um provedor de identidade externo federado com Azure AD B2C, como os Serviços de Federação do Active Directory (AD FS) ou o Salesforce. O fluxo iniciado pelo IdP tem suporte apenas para autenticação de conta local no Azure AD B2C.

Para habilitar o fluxo iniciado pelo IdP, defina o item de metadados IdpInitiatedProfileEnabled como true no perfil técnico de terceira parte confiável.

<RelyingParty>
  <DefaultUserJourney ReferenceId="SignUpOrSignIn" />
  <TechnicalProfile Id="PolicyProfile">
    <DisplayName>PolicyProfile</DisplayName>
    <Protocol Name="SAML2"/>
    <Metadata>
      <Item Key="IdpInitiatedProfileEnabled">true</Item>
    </Metadata>
   ..
  </TechnicalProfile>
</RelyingParty>

Para entrar ou inscrever um usuário por meio do fluxo iniciado pelo IdP, use a seguinte URL:

https://<tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/<policy-name>/generic/login?EntityId=<app-identifier-uri>&RelayState=<relay-state> 

Substitua os seguintes valores:

  • Substitua <tenant-name> pelo seu nome de locatário.
  • Substitua <policy-name> com o nome da política de terceira parte confiável SAML.
  • Substitua <app-identifier-uri> com o valor identifierUris no arquivo de metadados, como https://contoso.onmicrosoft.com/app-name.
  • [Opcional] substitua <relay-state> por um valor incluído na solicitação de autorização que também é retornado na resposta do token. O parâmetro relay-state é usado para codificar as informações sobre o estado do usuário no aplicativo antes da solicitação de autenticação ocorrida, como a página em que ele estava.

Política de exemplo

É possível utilizar uma política de exemplo completa para testar com o aplicativo teste SAML:

  1. Baixe a política de exemplo de logon iniciada pelo SAML-SP.
  2. Atualize TenantId para corresponder ao nome do locatário. Este artigo usa o exemplo contoso.b2clogin.com.
  3. Mantenha o nome da política B2C_1A_signup_signin_saml.

Configurar o tempo de vida da resposta SAML

Você pode configurar o tempo que a resposta SAML permanece válida. Defina o tempo de vida usando o item de metadados TokenLifeTimeInSeconds dentro do perfil técnico do Emissor do Token SAML. Esse valor é o número de segundos que podem decorrer do carimbo de data/hora NotBefore calculado no momento da emissão do token. O tempo de vida padrão é de 300 segundos (cinco minutos).

<ClaimsProvider>
  <DisplayName>Token Issuer</DisplayName>
  <TechnicalProfiles>
    <TechnicalProfile Id="Saml2AssertionIssuer">
      <DisplayName>Token Issuer</DisplayName>
      <Protocol Name="SAML2"/>
      <OutputTokenFormat>SAML2</OutputTokenFormat>
      <Metadata>
        <Item Key="TokenLifeTimeInSeconds">400</Item>
      </Metadata>
      ...
    </TechnicalProfile>

Configurar a distorção de tempo de uma resposta SAML

Você pode configurar a distorção de tempo aplicada ao carimbo de data/hora NotBefore de resposta SAML. Essa configuração garante que se os tempos entre duas plataformas não estiverem em sincronia, a declaração SAML ainda será considerada válida estiver quando dentro dessa distorção de tempo.

Defina a distorção de tempo usando o item de metadados TokenNotBeforeSkewInSeconds dentro do perfil técnico do Emissor do Token SAML. O valor de distorção é fornecido em segundos, com um valor padrão de 0. O valor máximo é 3600 (uma hora).

Por exemplo, quando o TokenNotBeforeSkewInSeconds é definido como 120 segundos:

  • O token é emitido às 13:05:10 UTC.
  • O token é válido de 13:03:10 UTC.
<ClaimsProvider>
  <DisplayName>Token Issuer</DisplayName>
  <TechnicalProfiles>
    <TechnicalProfile Id="Saml2AssertionIssuer">
      <DisplayName>Token Issuer</DisplayName>
      <Protocol Name="SAML2"/>
      <OutputTokenFormat>SAML2</OutputTokenFormat>
      <Metadata>
        <Item Key="TokenNotBeforeSkewInSeconds">120</Item>
      </Metadata>
      ...
    </TechnicalProfile>

Remover milissegundos da data e hora

É possível especificar se os milissegundos serão removidos dos valores de data e hora dentro da resposta SAML. (Esses valores incluem IssueInstant, NotBefore, NotOnOrAfter e AuthnInstant). Para remover os milissegundos, defina a chave de metadados RemoveMillisecondsFromDateTime na terceira parte confiável. Valores possíveis: false (padrão) ou true.

  <RelyingParty>
    <DefaultUserJourney ReferenceId="SignUpOrSignIn" />
    <TechnicalProfile Id="PolicyProfile">
      <DisplayName>PolicyProfile</DisplayName>
      <Protocol Name="SAML2" />
      <Metadata>
        <Item Key="RemoveMillisecondsFromDateTime">true</Item>
      </Metadata>
      <OutputClaims>
             ...
      </OutputClaims>
      <SubjectNamingInfo ClaimType="objectId" ExcludeAsClaim="true" />
    </TechnicalProfile>
  </RelyingParty>

Usar uma ID do emissor para substituir um URI do emissor

Se você tiver vários aplicativos SAML que dependem de diferentes valores entityID, poderá substituir o valor IssuerUri em seu arquivo de terceira parte confiável. Para substituir o URI do emissor, copie o perfil técnico com a ID Saml2AssertionIssuer do arquivo base e substitua o valor IssuerUri.

Dica

Copie a seção <ClaimsProviders> da base e preserve esses elementos dentro do provedor de declarações: <DisplayName>Token Issuer</DisplayName>, <TechnicalProfile Id="Saml2AssertionIssuer"> e <DisplayName>Token Issuer</DisplayName>.

Exemplo:

   <ClaimsProviders>   
    <ClaimsProvider>
      <DisplayName>Token Issuer</DisplayName>
      <TechnicalProfiles>
        <TechnicalProfile Id="Saml2AssertionIssuer">
          <DisplayName>Token Issuer</DisplayName>
          <Metadata>
            <Item Key="IssuerUri">customURI</Item>
          </Metadata>
        </TechnicalProfile>
      </TechnicalProfiles>
    </ClaimsProvider>
  </ClaimsProviders>
  <RelyingParty>
    <DefaultUserJourney ReferenceId="SignUpInSAML" />
    <TechnicalProfile Id="PolicyProfile">
      <DisplayName>PolicyProfile</DisplayName>
      <Protocol Name="SAML2" />
      <Metadata>
     …

Gerenciar uma sessão

Você pode gerenciar a sessão entre o Azure AD B2C e o aplicativo de terceira parte confiável SAML usando o elemento UseTechnicalProfileForSessionManagement e o SamlSSOSessionProvider.

Forçar os usuários a autenticar novamente

Para forçar os usuários a autenticar novamente, o aplicativo pode incluir o atributo ForceAuthn na solicitação de autenticação SAML. O atributo ForceAuthn é um valor booliano. Quando definido como true, a sessão do usuário será invalidada no Azure AD B2C e o usuário será forçado a autenticar novamente.

A solicitação de autenticação SAML a seguir demonstra como definir o atributo ForceAuthn como true.

<samlp:AuthnRequest 
       Destination="https://contoso.b2clogin.com/contoso.onmicrosoft.com/B2C_1A_SAML2_signup_signin/samlp/sso/login"
       ForceAuthn="true" ...>
    ...
</samlp:AuthnRequest>

Assinar os metadados do IdP do SAML do Azure AD B2C

Você pode instruir o Azure AD B2C a assinar seu documento de metadados para o provedor de identidade SAML se o aplicativo exigir. Se você ainda não tiver uma chave de política, crie uma. Em seguida, configure o item de metadados MetadataSigning no perfil técnico do Emissor do Token SAML. O StorageReferenceId deve referenciar o nome da chave de política.

<ClaimsProvider>
  <DisplayName>Token Issuer</DisplayName>
  <TechnicalProfiles>
    <!-- SAML Token Issuer technical profile -->
    <TechnicalProfile Id="Saml2AssertionIssuer">
      <DisplayName>Token Issuer</DisplayName>
      <Protocol Name="SAML2"/>
      <OutputTokenFormat>SAML2</OutputTokenFormat>
        ...
      <CryptographicKeys>
        <Key Id="MetadataSigning" StorageReferenceId="B2C_1A_SamlMetadataCert"/>
        ...
      </CryptographicKeys>
    ...
    </TechnicalProfile>

Depurar o protocolo SAML

Para ajudar a configurar e depurar a integração com seu provedor de serviços, você pode utilizar uma extensão de navegador para o protocolo SAML. As extensões de navegador incluem a extensão SAML DevTools para Chrome, a SAML-tracer para Firefox e as Ferramentas de desenvolvedor para Edge ou Internet Explorer.

Ao usar essas ferramentas, você pode verificar a integração entre seu aplicativo e o Azure AD B2C. 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.
  • Verifique se o Azure AD B2C retorna uma mensagem de erro.
  • Verifique se a seção de declaração está criptografada.

Próximas etapas