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

  • Artigo

Este artigo descreve as opções de configuração que estão disponíveis quando você está conectando o Azure Ative Directory B2C (Azure AD B2C) com seu aplicativo SAML (Security Assertion Markup Language).

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

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

Especificar uma assinatura de resposta SAML

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

Se ainda não tiver uma chave de política, crie uma. Em seguida, configure o item de SamlMessageSigning metadados no perfil técnico do Emissor de Token SAML. StorageReferenceId deve fazer referência ao nome da chave da 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 usado para assinar a asserção SAML. Os valores possíveis são Sha256, , Sha512Sha384, ou Sha1. Verifique se o perfil técnico e o aplicativo usam o mesmo algoritmo de assinatura. Utilize apenas o algoritmo suportado pelo certificado.

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

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

Verifique a assinatura da asserção SAML

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

O exemplo a seguir mostra metadados para um provedor de serviços SAML, com 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>

Certidão de assinatura

Sua política deve especificar um certificado a ser usado para assinar a seção de asserções SAML da resposta SAML. Se ainda não tiver uma chave de política, crie uma. Em seguida, configure o item de SamlAssertionSigning metadados no perfil técnico do Emissor de Token SAML. StorageReferenceId deve fazer referência ao nome da chave da 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 criptografia em asserções SAML

Quando seu aplicativo espera que as asserções SAML estejam em um formato criptografado, verifique se a criptografia está habilitada na política do Azure AD B2C.

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

<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 WantsEncryptedAssertion metadados como true no perfil técnico da terceira parte confiável. Você também pode configurar o algoritmo usado para criptografar a asserçã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 encriptação

Para configurar o método de criptografia usado para criptografar os dados de asserção SAML, defina a DataEncryptionMethod chave de metadados dentro da terceira parte confiável. Os valores possíveis são Aes256 (padrão), Aes192, , Sha512ou Aes128. Os metadados controlam o <EncryptedData> valor do elemento 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 asserção SAML, defina a KeyEncryptionMethod chave de metadados dentro da terceira parte confiável. Os valores possíveis são:

  • Rsa15 (padrão): algoritmo RSA Public Key Cryptography Standard (PKCS) Versão 1.5.
  • RsaOaep: Algoritmo de encriptação RSA Optimal Asymmetric Encryption Padding (OAEP).

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

O exemplo a seguir mostra a EncryptedAssertion seção de uma asserção SAML. O método de dados criptografados é , e o método de chave criptografada é Aes128Rsa15.

<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 encriptação, defina a chave de UseDetachedKeys metadados na entidade confiadora. Valores possíveis: true ou false (padrão). Quando o valor é definido como , as chaves desanexadas adicionam a asserção criptografada como trueum filho de em vez de EncryptedAssertion EncryptedData.

Configure o método e o formato de criptografia usando as chaves de metadados dentro do perfil técnico da 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 fluxo iniciado pelo IdP

Quando seu aplicativo espera receber uma asserção SAML sem primeiro enviar uma solicitação SAML AuthN para o provedor de identidade (IdP), você deve configurar o Azure AD B2C para 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 para o provedor de serviços (seu aplicativo de terceira parte confiável).

Atualmente, não oferecemos suporte a cenários em que o provedor de identidade inicial é um provedor de identidade externo federado com o Azure AD B2C, como os Serviços de Federação do Ative Directory ou o Salesforce. O fluxo iniciado pelo IdP é suportado apenas para autenticação de conta local no Azure AD B2C.

Para habilitar o fluxo iniciado pelo IdP, defina o item de IdpInitiatedProfileEnabled metadados como true no perfil técnico da 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 nome do locatário.
  • Substitua <policy-name> pelo nome da sua política de terceira parte confiável SAML.
  • Substitua <app-identifier-uri> pelo identifierUris valor 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 relay-state parâmetro é usado para codificar informações sobre o estado do usuário no aplicativo antes da solicitação de autenticação ocorrer, como a página em que ele estava.

Política de exemplo

Você pode usar uma política de exemplo completa para testar com o aplicativo de teste SAML:

  1. Baixe a política de exemplo de login iniciada pelo SAML-SP.
  2. Atualize TenantId para corresponder ao seu nome de 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 período de tempo em que a resposta SAML permanece válida. Defina o tempo de vida usando o TokenLifeTimeInSeconds item de metadados dentro do perfil técnico do Emissor de Token SAML. Esse valor é o número de segundos que pode decorrer do carimbo de data/hora, calculado no momento da emissão do NotBefore 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 tempo de resposta NotBefore SAML. Essa configuração garante que, se os tempos entre duas plataformas não estiverem sincronizados, a asserção SAML ainda será considerada válida quando estiver dentro dessa inclinação de tempo.

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

Por exemplo, quando TokenNotBeforeSkewInSeconds é definido como 120 segundos:

  • O token é emitido às 13:05:10 UTC.
  • O token é válido a partir das 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

Você pode especificar se milissegundos serão removidos dos valores de data e hora dentro da resposta SAML. (Esses valores incluem IssueInstant, , NotOnOrAfterNotBefore, e AuthnInstant.) Para remover os milissegundos, defina a chave de RemoveMillisecondsFromDateTime metadados 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 um ID de emissor para substituir um URI do emissor

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

Gorjeta

Copie a <ClaimsProviders> seção da base e preserve esses elementos no 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>
     …

Gerir 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 e o UseTechnicalProfileForSessionManagement SamlSSOSessionProvider.

Forçar os usuários a se autenticarem novamente

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

A seguinte solicitação de autenticação SAML demonstra como definir o ForceAuthn atributo 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 SAML do Azure AD B2C IdP

Você pode instruir o Azure AD B2C a assinar seu documento de metadados para o provedor de identidade SAML, se o aplicativo exigir. Se ainda não tiver uma chave de política, crie uma. Em seguida, configure o item de MetadataSigning metadados no perfil técnico do Emissor de Token SAML. StorageReferenceId deve fazer referência ao nome da chave da 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 usar uma extensão de navegador para o protocolo SAML. As extensões de navegador incluem a extensão SAML DevTools para Chrome, SAML-tracer para Firefox e ferramentas de desenvolvedor para Edge ou Internet Explorer.

Usando 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 asserção está criptografada.

Próximos passos

  • Encontre mais informações sobre o protocolo SAML no site do OASIS.
  • Obtenha o aplicativo Web de teste SAML do repositório da comunidade GitHub do Azure AD B2C.