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

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 <samlp:Response> elemento dentro da resposta SAML enviada para o 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, Sha384, Sha512, 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 XmlSignatureAlgorithm metadados dentro do elemento de 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 a sua aplicação espera que a secção de asserção SAML seja assinada, certifique-se de que o fornecedor de serviços SAML configure WantAssertionsSigned como 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 declaraçã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 afirmações criptografadas, defina o item de WantsEncryptedAssertion metadados como true no perfil técnico da 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 encriptação usado para encriptar os dados de asserção SAML, defina a chave de metadados DataEncryptionMethod dentro da parte confiável. Os valores possíveis são Aes256 (padrão), Aes192, Sha512, ou 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 chave de metadados KeyEncryptionMethod dentro da entidade 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.

Este exemplo mostra a seção EncryptedAssertion de uma asserçã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 encriptação, defina a chave de metadados UseDetachedKeys dentro da parte confiável. Valores possíveis: true ou false (padrão). Quando o valor é definido como true, as chaves desanexadas adicionam a asserção criptografada como um filho de EncryptedAssertion em vez de 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 parte confiante.

<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 confiança de parte dependente SAML.
• Substitua <app-identifier-uri> pelo valor identifierUris no ficheiro 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 exemplar

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 nome do seu inquilino. 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. Este valor é o número de segundos que podem decorrer a partir 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 o desvio de tempo aplicado ao carimbo de tempo da resposta SAML NotBefore. 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 está definido para 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 os 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, NotBefore, NotOnOrAfter, e AuthnInstant.) Para remover os milissegundos, defina a chave de metadados RemoveMillisecondsFromDateTime dentro da 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 identificador de emissor para substituir um URI do emissor

Se tiver várias aplicações SAML que dependem de diferentes valores entityID, pode substituir o valor IssuerUri no seu ficheiro de parte fidedigna. Para substituir o URI do emissor, copie o perfil técnico com o ID Saml2AssertionIssuer do arquivo base e substitua o valor IssuerUri.

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