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 KeyDescriptor
use
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 valoridentifierUris
no arquivo de metadados, comohttps://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âmetrorelay-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:
- Baixe a política de exemplo de logon iniciada pelo SAML-SP.
- Atualize
TenantId
para corresponder ao nome do locatário. Este artigo usa o exemplo contoso.b2clogin.com. - 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
- Encontre mais informações sobre o protocolo SAML no site da OASIS.
- Obtenha o aplicativo Web de teste SAML no repositório da comunidade GitHub do Azure AD B2C.