Registrar um aplicativo SAML no Azure AD B2C

Neste artigo, aprenda a conectar aplicativos (provedores de serviços) SAML (Security Assertion Markup Language) ao Azure Active Directory B2C (Azure AD B2C) para autenticação.

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.

Visão geral

As organizações que usam o Azure Active Directory B2C como solução de gerenciamento de acesso e identidade do cliente podem exigir integração com aplicativos que autenticam por meio do uso do protocolo SAML. O diagrama a seguir mostra como Azure AD B2C serve como um IdP (provedor de identidade) para obter SSO (logon único) com aplicativos baseados em SAML.

Diagram with Azure Active Directory B2C as an identity provider on the left and as a service provider on the right.

  1. O aplicativo cria uma solicitação de AuthN SAML que é enviada ao ponto de extremidade de entrada SAML para o Azure AD B2C.
  2. Para autenticar, o usuário pode utilizar uma conta local do Azure AD B2C ou qualquer outro provedor de identidade federado (se configurado).
  3. Se o usuário entrar usando um provedor de identidade federado, será enviada uma resposta de token ao Azure Active Directory B2C.
  4. O Azure AD B2C gera uma declaração SAML e a envia ao aplicativo.

Assista a este vídeo para saber como integrar aplicativos SAML com o Azure AD B2C.

Pré-requisitos

No cenário neste artigo, é necessário ter:

  • A política personalizada SocialAndLocalAccounts do pacote inicial de política personalizada. Conclua as etapas em Introdução às políticas personalizadas no Azure AD B2C.
  • Uma noção básica sobre o protocolo SAML e familiaridade com a implementação SAML do aplicativo.
  • Um aplicativo Web configurado como um aplicativo SAML. Deve ter a capacidade de enviar solicitações de AuthN SAML e receber, decodificar e verificar respostas de SAML do Azure Active Directory B2C. O aplicativo SAML também é conhecido como o provedor de serviços ou aplicativo de terceira parte confiável.
  • O documento XML ou ponto de extremidade de metadados SAML disponível publicamente do aplicativo SAML.
  • Um locatário do Azure AD B2C.

Se você ainda não tem um aplicativo SAML e um ponto de extremidade de metadados associado, use o aplicativo de teste de SAML que disponibilizamos para teste.

Importante

Seus pontos de extremidade devem estar em conformidade com os requisitos de segurança do Azure AD B2C. As versões e as criptografias de TLS mais antigas foram preterida. Para obter mais informações, consulte TLS do Azure AD B2C e requisitos do conjunto de criptografias.

Configurar certificados

Para criar uma relação de confiança entre o seu aplicativo e o Azure AD B2C, os dois serviços devem conseguir criar e validar as assinaturas um do outro. Configure certificados X509 em seu aplicativo e no Azure Active Directory B2C.

Certificados de aplicativo

Uso Obrigatório Descrição
Assinatura de solicitação SAML Não Certificado com uma chave privada armazenada no aplicativo Web. Seu aplicativo usa o certificado para assinar solicitações SAML enviadas ao Azure Active Directory B2C. O aplicativo Web deve expor a chave pública por meio de seu respectivo ponto de extremidade de metadados SAML. O Azure AD B2C valida a assinatura de solicitação SAML usando a chave pública dos metadados do aplicativo.
Criptografia de declaração SAML Não Certificado com uma chave privada armazenada no aplicativo Web. O aplicativo Web deve expor a chave pública por meio de seu respectivo ponto de extremidade de metadados SAML. O Azure Active Directory B2C pode criptografar declarações para o aplicativo usando a chave pública. O aplicativo usa a chave privada para descriptografar a declaração.

Certificados do Azure AD B2C

Uso Obrigatório Descrição
Assinatura de resposta SAML Sim Certificado com uma chave privada armazenada no Azure AD B2C. O Azure AD B2C usa esse certificado para assinar a resposta SAML enviada ao seu aplicativo. O aplicativo lê a chave pública de metadados no Azure Active Directory B2C para validar a assinatura da resposta de SAML.
Assinatura de declaração SAML Sim Certificado com uma chave privada armazenada no Azure AD B2C. O Azure Active Directory B2C usa esse certificado para assinar a parte <saml:Assertion> da resposta de SAML.

Em um ambiente de produção, é recomendável usar certificados que uma autoridade de certificação pública emitiu. Contudo, também é possível concluir esse procedimento com certificados autoassinados.

Criar uma chave de política

Para ter uma relação de confiança entre seu aplicativo e o Azure Active Directory B2C, crie um certificado de autenticação para resposta de SAML. O Azure AD B2C usa esse certificado para assinar a resposta SAML enviada ao seu aplicativo. O aplicativo lê a chave pública de metadados do Azure Active Directory B2C para validar a assinatura da resposta de SAML.

Dica

Você pode usar essa chave de política para outras finalidades, como assinar a declaração SAML.

Obter um certificado

Se você ainda não tiver um certificado, será possível usar um certificado autoassinado. Um certificado autoassinado é um certificado de segurança que não é assinado por uma autoridade de certificação (AC) e não fornece as garantias de segurança de um certificado assinado por uma AC.

No Windows, use o cmdlet New-SelfSignedCertificate no PowerShell para gerar um certificado.

  1. Execute o seguinte comando do PowerShell para gerar um certificado autoassinado. Modifique o argumento -Subject conforme apropriado para o aplicativo e o nome do locatário do Azure AD B2C, como contosowebapp.contoso.onmicrosoft.com. Você também pode ajustar a data -NotAfter para especificar uma expiração diferente para o certificado.

    New-SelfSignedCertificate `
        -KeyExportPolicy Exportable `
        -Subject "CN=yourappname.yourtenant.onmicrosoft.com" `
        -KeyAlgorithm RSA `
        -KeyLength 2048 `
        -KeyUsage DigitalSignature `
        -NotAfter (Get-Date).AddMonths(12) `
        -CertStoreLocation "Cert:\CurrentUser\My"
    
  2. No Windows, pesquise e selecione Gerenciar certificados de usuário

  3. Em Certificados – Usuário Atual, selecione Pessoal>Certificados>yourappname.yourtenant.onmicrosoft.com.

  4. Selecione o certificado e, em seguida, selecione Ação>Todas as Tarefas>Exportar.

  5. Selecione Próximo>Sim, exportar a chave privada>Próximo.

  6. Aceite os padrões para Formato de arquivo para exportação e selecione Próximo.

  7. Habilite a opção Senha, insira uma senha para o certificado e selecione Próximo.

  8. Para especificar um local para salvar seu certificado, selecione Procurar e navegue até um diretório de sua preferência.

  9. Na janela Salvar como, insira um Nome de arquivo e, em seguida, selecione Salvar.

  10. Selecione Avançar>Concluir.

Para o Azure AD B2C aceitar a senha do arquivo .pfx, a senha deve estar criptografada com a opção TripleDES-SHA1 no utilitário de exportação do repositório de certificados do Windows, em oposição ao AES256-SHA256.

Carregar o certificado

Você precisa armazenar o certificado em seu locatário do Azure AD B2C.

  1. Entre no portal do Azure.
  2. Se você tiver acesso a vários locatários, selecione o ícone Configurações no menu superior para alternar para o seu locatário do Azure Active Directory B2C no menu Diretórios + assinaturas.
  3. Selecione Todos os serviços no canto superior esquerdo do portal do Microsoft Azure, pesquise por Azure Active Directory B2C e selecione-o.
  4. Na página Visão geral, selecione Identity Experience Framework.
  5. Selecione Chaves de Política e, em seguida, escolha Adicionar.
  6. Em Opções, selecione Carregar.
  7. Em Nome, insira um nome para a chave de política. Por exemplo, insira SamlIdpCert. O prefixo B2C_1A_ será adicionado automaticamente ao nome da chave.
  8. Procure e selecione o arquivo .pfx do certificado com a chave privada.
  9. Selecione Criar.

Habilitar sua política para se conectar a um aplicativo SAML

Para se conectar ao seu aplicativo SAML, o Azure AD B2C precisa conseguir criar respostas SAML.

Abra SocialAndLocalAccounts\TrustFrameworkExtensions.xml no pacote inicial da política personalizada.

Encontre a seção <ClaimsProviders> e adicione o trecho XML a seguir para implementar o gerador de resposta de SAML:

<ClaimsProvider>
  <DisplayName>Token Issuer</DisplayName>
  <TechnicalProfiles>

    <!-- SAML Token Issuer technical profile -->
    <TechnicalProfile Id="Saml2AssertionIssuer">
      <DisplayName>Token Issuer</DisplayName>
      <Protocol Name="SAML2"/>
      <OutputTokenFormat>SAML2</OutputTokenFormat>
      <Metadata>
        <Item Key="IssuerUri">https://issuerUriMyAppExpects</Item>
      </Metadata>
      <CryptographicKeys>
        <Key Id="SamlAssertionSigning" StorageReferenceId="B2C_1A_SamlIdpCert"/>
        <Key Id="SamlMessageSigning" StorageReferenceId="B2C_1A_SamlIdpCert"/>
      </CryptographicKeys>
      <InputClaims/>
      <OutputClaims/>
      <UseTechnicalProfileForSessionManagement ReferenceId="SM-Saml-issuer"/>
    </TechnicalProfile>

    <!-- Session management technical profile for SAML-based tokens -->
    <TechnicalProfile Id="SM-Saml-issuer">
      <DisplayName>Session Management Provider</DisplayName>
      <Protocol Name="Proprietary" Handler="Web.TPEngine.SSO.SamlSSOSessionProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"/>
    </TechnicalProfile>

  </TechnicalProfiles>
</ClaimsProvider>

Configurar o Uniform Resource Identifier do emissor da resposta de SAML

Você pode configurar o valor do item de metadados IssuerUri no perfil técnico do Emissor do token SAML. Essa alteração será refletida no atributo issuerUri retornado na resposta SAML do Azure AD B2C. Configurar aplicativo para aceitar o mesmo valor de IssuerUri durante a validação da resposta de SAML.

<ClaimsProvider>
  <DisplayName>Token Issuer</DisplayName>
  <TechnicalProfiles>
    <!-- SAML Token Issuer technical profile -->
    <TechnicalProfile Id="Saml2AssertionIssuer">
      <DisplayName>Token Issuer</DisplayName>
      <Protocol Name="SAML2"/>
      <OutputTokenFormat>SAML2</OutputTokenFormat>
      <Metadata>
        <Item Key="IssuerUri">https://issuerUriMyAppExpects</Item>
      </Metadata>
      ...
    </TechnicalProfile>

Configurar política para emitir uma resposta de SAML

Agora que sua política pode criar respostas SAML, você deve configurá-la para emitir uma resposta SAML em vez da resposta JWT padrão para o seu aplicativo.

Criar uma política de inscrição ou de entrada que seja configurada para SAML

  1. Crie uma cópia do arquivo SignUpOrSignin.xml no diretório de trabalho do pacote inicial e salve-a com um novo nome. Este artigo usa SignUpOrSigninSAML.xml como exemplo. Esse arquivo é seu arquivo de política para a terceira parte confiável. Ele está configurado para emitir uma resposta JWT por padrão.

  2. Abra o arquivo SignUpOrSigninSAML.xml no editor de sua preferência.

  3. Altere o valor de:

    1. PolicyId em B2C_1A_signup_signin_saml

    2. PublicPolicyUri para http://<tenant-name>.onmicrosoft.com/B2C_1A_signup_signin_saml. Substitua o espaço reservado <tenant-name> pelo subdomínio do nome de domínio do locatário do Azure AD B2C. Por exemplo, se o domínio primário do locatário for contoso.onmicrosoft.com, use contoso. Se você não tiver o nome do locatário, saiba como ler os detalhes do locatário.

    <TrustFrameworkPolicy
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    xmlns="http://schemas.microsoft.com/online/cpim/schemas/2013/06"
    PolicySchemaVersion="0.3.0.0"
    TenantId="<tenant-name>.onmicrosoft.com"
    PolicyId="B2C_1A_signup_signin_saml"
    PublicPolicyUri="http://<tenant-name>.onmicrosoft.com/B2C_1A_signup_signin_saml">
    
  4. No final do percurso do usuário, o Azure Active Directory B2C contém uma etapa SendClaims. Esta etapa faz referência ao perfil técnico do Emissor do Token. Para emitir uma resposta de SAML em vez da resposta JWT padrão, modifique a etapa SendClaims para fazer referência ao novo perfil técnico do Emissor do token SAML, Saml2AssertionIssuer.

Adicione o trecho XML a seguir imediatamente antes do elemento <RelyingParty>. Esse XML substitui a etapa de orquestração nº 7 no percurso do usuário SignUpOrSignIn.

Se você começou em uma pasta diferente no pacote inicial ou personalizou o percurso do usuário adicionando ou removendo etapas de orquestração, verifique se o número no elemento order corresponde ao número especificado no percurso do usuário para a etapa de emissor do token. Por exemplo, nas outras pastas do pacote inicial, o número da etapa correspondente é 4 para LocalAccounts, 6 para SocialAccounts e 9 para SocialAndLocalAccountsWithMfa.

<UserJourneys>
  <UserJourney Id="SignUpOrSignIn">
    <OrchestrationSteps>
      <OrchestrationStep Order="7" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="Saml2AssertionIssuer"/>
    </OrchestrationSteps>
  </UserJourney>
</UserJourneys>

O elemento de terceira parte confiável determina o protocolo que será usado pelo seu aplicativo. O padrão é OpenId. O elemento Protocol deve ser configurado como SAML. As declarações de saída criarão o mapeamento de declarações para a instrução de declaração SAML.

Substitua todo o elemento <TechnicalProfile> no elemento <RelyingParty> pelo XML de perfil técnico a seguir.

    <TechnicalProfile Id="PolicyProfile">
      <DisplayName>PolicyProfile</DisplayName>
      <Protocol Name="SAML2"/>
      <OutputClaims>
        <OutputClaim ClaimTypeReferenceId="displayName" />
        <OutputClaim ClaimTypeReferenceId="givenName" />
        <OutputClaim ClaimTypeReferenceId="surname" />
        <OutputClaim ClaimTypeReferenceId="email" DefaultValue="" />
        <OutputClaim ClaimTypeReferenceId="identityProvider" DefaultValue="" />
        <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="objectId"/>
      </OutputClaims>
      <SubjectNamingInfo ClaimType="objectId" ExcludeAsClaim="true"/>
    </TechnicalProfile>

O arquivo final de política para a terceira parte confiável deve ser semelhante ao seguinte código XML:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<TrustFrameworkPolicy
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:xsd="http://www.w3.org/2001/XMLSchema"
  xmlns="http://schemas.microsoft.com/online/cpim/schemas/2013/06"
  PolicySchemaVersion="0.3.0.0"
  TenantId="contoso.onmicrosoft.com"
  PolicyId="B2C_1A_signup_signin_saml"
  PublicPolicyUri="http://contoso.onmicrosoft.com/B2C_1A_signup_signin_saml">

  <BasePolicy>
    <TenantId>contoso.onmicrosoft.com</TenantId>
    <PolicyId>B2C_1A_TrustFrameworkExtensions</PolicyId>
  </BasePolicy>

  <UserJourneys>
    <UserJourney Id="SignUpOrSignIn">
      <OrchestrationSteps>
        <OrchestrationStep Order="7" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="Saml2AssertionIssuer"/>
      </OrchestrationSteps>
    </UserJourney>
  </UserJourneys>

  <RelyingParty>
    <DefaultUserJourney ReferenceId="SignUpOrSignIn" />
    <TechnicalProfile Id="PolicyProfile">
      <DisplayName>PolicyProfile</DisplayName>
      <Protocol Name="SAML2"/>
      <OutputClaims>
        <OutputClaim ClaimTypeReferenceId="displayName" />
        <OutputClaim ClaimTypeReferenceId="givenName" />
        <OutputClaim ClaimTypeReferenceId="surname" />
        <OutputClaim ClaimTypeReferenceId="email" DefaultValue="" />
        <OutputClaim ClaimTypeReferenceId="identityProvider" DefaultValue="" />
        <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="objectId"/>
      </OutputClaims>
      <SubjectNamingInfo ClaimType="objectId" ExcludeAsClaim="true"/>
    </TechnicalProfile>
  </RelyingParty>
</TrustFrameworkPolicy>

Observação

Siga esse mesmo processo para implementar outros tipos de fluxos de usuário (por exemplo: fluxos de edição de perfil, de entrada e de redefinição de senha).

Carregar sua política

Salve as alterações e carregue os novos arquivos de política TrustFrameworkExtensions.xml e SignUpOrSigninSAML.xml para o portal do Azure.

Testar os metadados SAML do IdP do Azure Active Directory B2C

Depois que os arquivos de política forem carregados, o Azure Active Directory B2C usará as informações de configuração para gerar o documento de metadados SAML do provedor de identidade que o aplicativo usará. O documento de metadados SAML contém os locais dos serviços, como métodos de entrada, métodos de saída e certificados.

Os metadados de política do Azure AD B2C estão disponíveis na seguinte URL:

https://<tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/<policy-name>/samlp/metadata

Substitua <tenant-name> pelo nome de seu locatário do Azure AD B2C. Substitua <policy-name> pelo nome (ID) da política. Aqui está um exemplo:

https://contoso.b2clogin.com/contoso.onmicrosoft.com/B2C_1A_signup_signin_saml/samlp/metadata

Registrar seu aplicativo SAML no Azure AD B2C

Para que o Azure Active Directory B2C confie em seu aplicativo, crie um registro de aplicativo do Azure Active Directory B2C. O registro contém informações de configuração, como o ponto de extremidade de metadados do aplicativo.

  1. Entre no portal do Azure.
  2. Se você tiver acesso a vários locatários, selecione o ícone Configurações no menu superior para alternar para o seu locatário do Azure Active Directory B2C no menu Diretórios + assinaturas.
  3. No menu à esquerda, selecione Azure Active Directory B2C. Ou selecione Todos os serviços e, em seguida, pesquise e selecione Azure Active Directory B2C.
  4. Escolha Registros de aplicativo e Novo registro.
  5. Insira um Nome para o aplicativo. Por exemplo, insira SAMLApp1.
  6. Em Tipos de contas com suporte, selecione Contas somente neste diretório organizacional.
  7. Em URI de Redirecionamento, selecione Web e, em seguida, digite https://localhost. Você modificará esse valor posteriormente no manifesto do registro de aplicativo.
  8. Selecione Registrar.

Configurar seu aplicativo no Azure AD B2C

Em aplicativos SAML, é necessário configurar várias propriedades no manifesto do registro de aplicativo.

  1. No portal do Microsoft Azure, vá até o registro de aplicativo criado na seção anterior.
  2. Em Gerenciar, selecione Manifesto para abrir o editor de manifesto. Em seguida, modifique as propriedades descritas nas seguintes seções.

Adicionar o identificador

Quando seu aplicativo SAML faz uma solicitação ao Azure Active Directory B2C, a solicitação AuthN SAML inclui um atributo Issuer. O valor desse atributo normalmente é o mesmo que o valor entityID de metadados do aplicativo. O Azure AD B2C usa esse valor para pesquisar o registro de aplicativo no diretório e ler a configuração. Para que essa pesquisa seja realizada com sucesso, identifierUri no registro de aplicativo deverá ser preenchido com um valor que corresponda ao atributo Issuer.

No manifesto do registro, localize o parâmetro identifierURIs e adicione o valor adequado. Este será o mesmo valor configurado nas solicitações AuthN SAML para EntityId no aplicativo, e o valor entityID nos metadados do aplicativo. Você também precisará localizar o parâmetro accessTokenAcceptedVersion e definir o valor como 2.

Importante

Se você não atualizar o accessTokenAcceptedVersion para 2, receberá uma mensagem de erro exigindo um domínio verificado.

O exemplo a seguir mostra o valor entityID nos metadados SAML:

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

A propriedade identifierUris aceitará URLs apenas no domínio tenant-name.onmicrosoft.com.

"identifierUris":"https://tenant-name.onmicrosoft.com/app-name",

Compartilhar os metadados do aplicativo com o Azure AD B2C

Depois que o registro de aplicativo for carregado pelo valor identifierUri, o Azure Active Directory B2C usará os metadados do aplicativo para validar a solicitação AuthN SAML e determinar qual será a resposta.

Recomenda-se que o aplicativo exponha um ponto de extremidade de metadados acessível publicamente.

Se houver propriedades especificadas tanto na URL de metadados SAML quanto no manifesto do registro de aplicativo, elas serão mescladas. As propriedades especificadas na URL de metadados são processadas primeiro e têm precedência.

Usando o aplicativo de teste SAML como exemplo, você utilizaria o seguinte valor para samlMetadataUrl no manifesto do aplicativo:

"samlMetadataUrl":"https://samltestapp2.azurewebsites.net/Metadata",

Substituir ou definir a URL do consumidor de declaração (opcional)

Você pode configurar a URL de resposta para a qual o Azure AD B2C envia respostas SAML. As URLs de resposta podem ser configuradas no manifesto do aplicativo. Essa configuração é útil quando seu aplicativo não expõe um ponto de extremidade de metadados acessível publicamente.

A URL de resposta para um aplicativo SAML é o ponto de extremidade em que o aplicativo espera receber respostas SAML. O aplicativo geralmente fornece essa URL no documento de metadados sob o atributo Location do elemento AssertionConsumerService, conforme mostrado neste exemplo:

<SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
    ...
    <AssertionConsumerService index="0" isDefault="true" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://samltestapp2.azurewebsites.net/SP/AssertionConsumer" />        
</SPSSODescriptor>

Se o elemento de metadados do aplicativo AssertionConsumerService estiver ausente ou se você quiser substituí-lo, configure a propriedade de manifesto de registro do aplicativo replyUrlsWithType. O Azure AD B2C usa o replyUrlsWithType para redirecionar os usuários depois que eles estiverem conectados usando o tipo de associação HTTP-POST.

Usando o aplicativo de teste SAML como exemplo, defina a propriedade url de replyUrlsWithType como o valor mostrado no trecho JSON a seguir:

"replyUrlsWithType":[
  {
    "url":"https://samltestapp2.azurewebsites.net/SP/AssertionConsumer",
    "type":"Web"
  }
],

Substituir ou definir a URL de saída (opcional)

A URL de saída define para onde redirecionar o usuário após uma solicitação de saída. O aplicativo geralmente fornece essa URL no documento de metadados sob o atributo Location do elemento SingleLogoutService, conforme mostrado no exemplo a seguir:

<SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
    <SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://samltestapp2.azurewebsites.net/logout" ResponseLocation="https://samltestapp2.azurewebsites.net/logout" />

</SPSSODescriptor>

Se o elemento de metadados do aplicativo SingleLogoutService estiver ausente, configure a propriedade logoutUrl do manifesto de registro do aplicativo. O Azure AD B2C usa o logoutURL para redirecionar os usuários depois que eles estiverem desconectados usando o tipo de associação HTTP-Redirect.

Usando o aplicativo de teste SAML como exemplo, defina a propriedade logoutUrl como https://samltestapp2.azurewebsites.net/logout:

"logoutUrl": "https://samltestapp2.azurewebsites.net/logout",

Observação

Se você optar por configurar a URL de resposta e a URL de logout no manifesto do aplicativo sem preencher o ponto de extremidade de metadados do aplicativo por meio da propriedade samlMetadataUrl, o Azure Active Directory B2C não validará a assinatura de solicitação SAML. Ele também não criptografará a resposta SAML.

Configurar o Azure AD B2C como um IdP SAML no seu aplicativo SAML

A última etapa é habilitar o Azure AD B2C como um IdP SAML no seu aplicativo SAML. Cada aplicativo é diferente e as etapas variam. Consulte a documentação do seu aplicativo para obter detalhes.

Os metadados podem ser configurados no aplicativo como metadados estáticos ou metadados dinâmicos. No modo estático, copie os metadados total ou parcialmente dos metadados de política do Azure AD B2C. No modo dinâmico, forneça a URL aos metadados e permita que o aplicativo leia os metadados dinamicamente.

Alguns ou todos os itens a seguir são necessários normalmente:

  • Metadados: use o formato https://<tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/<policy-name>/Samlp/metadata.

  • Emissor: o valor issuer da solicitação SAML deve corresponder a um dos URIs configurados no elemento identifierUris do manifesto do registro de aplicativo. Se o nome issuer da solicitação SAML não existe no elemento identifierUris, adicione-o ao manifesto do registro de aplicativo. Por exemplo: https://contoso.onmicrosoft.com/app-name.

  • URL de logon, ponto de extremidade SAML, URL SAML: no arquivo de metadados de política SAML do Azure Active Directory B2C, verifique o valor referente ao elemento XML <SingleSignOnService>.

  • Certificado: este certificado é B2C_1A_SamlIdpCert, mas sem a chave privada. Para obter a chave pública do certificado:

    1. Acesse a URL de metadados especificada anteriormente.
    2. Copie o valor no elemento <X509Certificate>.
    3. Cole-o em um arquivo de texto.
    4. Salve o arquivo de texto como um arquivo .cer.

Testar com o aplicativo de teste SAML

Use nosso aplicativo de teste SAML para testar sua configuração:

  • Atualize o nome do locatário.
  • Atualize o nome da política. Por exemplo, use B2C_1A_signup_signin_saml.
  • Especifique o Uniform Resource Identifier do emissor. Use um dos Uniform Resource Identifiers encontrados no elemento identifierUris no manifesto do registro de aplicativo. Por exemplo, use https://contoso.onmicrosoft.com/app-name.

Selecione Logon e uma tela de logon do usuário deverá aparecer. Depois que você entrar, uma resposta SAML será emitida de volta para o aplicativo de exemplo.

Modalidades SAML com e sem suporte

Há suporte para os seguintes cenários de aplicativo SAML por meio do seu próprio ponto de extremidade de metadados:

  • Especifique várias URLs de saída ou associação POST para a URL de saída no objeto de aplicativo ou entidade de serviço.
  • Especifique uma chave de assinatura para verificar solicitações de terceira parte confiável no objeto de aplicativo ou entidade de serviço.
  • Especifique uma chave de criptografia de token no objeto de aplicativo ou entidade de serviço.
  • Especifique o logon iniciado por provedor de identidade, que é o Azure Active Directory B2C.

Próximas etapas