Compartilhar via


Registrar um aplicativo SAML no Azure AD B2C

Importante

A partir de 1º de maio de 2025, o Azure AD B2C não estará mais disponível para compra para novos clientes. Saiba mais em nossas perguntas frequentes.

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

Antes de começar, use o seletor Escolha um tipo de política na parte superior dessa página 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 de usuários predefinidos ou por meio de políticas personalizadas totalmente configuráveis. As etapas necessárias neste artigo são diferentes para cada método.

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

Visão geral

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

Diagrama com o Azure Active Directory B2C como um provedor de identidade à esquerda e como um provedor de serviços à direita.

  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. O usuário pode usar uma conta local do Azure AD B2C ou qualquer outro provedor de identidade federado (se configurado) para autenticar.
  3. Se o usuário entrar usando um provedor de identidade federado, uma resposta de token será enviada ao Azure AD B2C.
  4. O Azure AD B2C gera uma declaração SAML e a envia para o aplicativo.

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

Pré-requisitos

Para o cenário deste artigo, você precisa:

  • 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 compreensão básica do protocolo SAML e familiaridade com a implementação SAML do aplicativo.
  • Um aplicativo Web configurado como um aplicativo SAML. Ele deve ter a capacidade de enviar solicitações de autenticação SAML e receber, decodificar e verificar respostas SAML do Azure AD B2C. O aplicativo SAML também é conhecido como aplicativo de terceira parte confiável ou provedor de serviços.
  • O documento XML ou ponto de extremidade de metadados SAML disponível publicamente do aplicativo SAML.
  • Um inquilino do Azure AD B2C.

Se você ainda não tiver um aplicativo SAML e um endpoint de metadados associado, poderá usar o aplicativo de teste SAML que disponibilizamos para teste.

Importante

Seus endpoints devem cumprir os requisitos de segurança do Azure AD B2C. Versões e criptografias TLS mais antigas são preteridas. Para obter mais informações, consulte os requisitos do TLS do Azure AD B2C e do conjunto de criptografias.

Configurar certificados

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

Certificados de aplicação

Uso Obrigatório Descrição
Assinatura de solicitação SAML Não Um certificado com uma chave privada armazenada em seu aplicativo Web. Seu aplicativo usa o certificado para assinar solicitações SAML enviadas ao Azure AD B2C. O aplicativo Web deve expor a chave pública por meio de seu endpoint 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 asserção SAML Não Um certificado com uma chave privada armazenada em seu aplicativo Web. O aplicativo Web deve expor a chave pública por meio de seu endpoint de metadados SAML. O Azure AD B2C pode criptografar declarações para seu aplicativo usando a chave pública. O aplicativo usa a chave privada para descriptografar a asserção.

Certificados do Azure AD B2C

Uso Obrigatório Descrição
Assinatura de resposta SAML Sim Um 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. Seu aplicativo lê a chave pública de metadados no Azure AD B2C para validar a assinatura da resposta SAML.
Assinatura de declaração SAML Sim Um certificado com uma chave privada armazenada no Azure AD B2C. O Azure AD B2C usa esse certificado para assinar a <saml:Assertion> parte da resposta SAML.

Em um ambiente de produção, recomendamos o uso de certificados emitidos por uma autoridade de certificação pública. Mas você também pode concluir este procedimento com certificados autoassinados.

Criar uma chave de política

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

Dica

Você pode usar essa chave de política para outras finalidades, como assinar a asserçã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 Próximo>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 seu 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 seu locatário do Azure AD B2C no menu Diretórios + assinaturas.
  3. Selecione Todos os serviços no canto superior esquerdo do portal do Azure e, em seguida, pesquise e selecione Azure AD B2C.
  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 Name (Nome), insira um nome para a chave de política. Por exemplo, insira SamlIdpCert. O prefixo B2C_1A_ é adicionado automaticamente ao nome da sua chave.
  8. Navegue até o seu arquivo .pfx do certificado com a chave privada e selecione-o.
  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 deve ser capaz de criar respostas SAML.

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

Localize a <ClaimsProviders> seção e adicione o seguinte snippet XML para implementar seu gerador de resposta 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 URI do emissor da resposta SAML

Você pode alterar o valor do IssuerUri item de metadados no perfil técnico do emissor de token SAML. Essa alteração é refletida no issuerUri atributo retornado na resposta SAML do Azure AD B2C. Configure seu aplicativo para aceitar o mesmo IssuerUri valor durante a validação da resposta 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>

Configure sua política para emitir uma resposta SAML

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

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

  1. Crie uma cópia do arquivo SignUpOrSignin.xml no diretório de trabalho do pacote inicial e salve-o 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 em seu editor preferencial.

  3. Altere o valor de:

    1. PolicyId a B2C_1A_signup_signin_saml

    2. PublicPolicyUri às http://<tenant-name>.onmicrosoft.com/B2C_1A_signup_signin_saml. Substitua o marcador <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 AD B2C contém uma SendClaims etapa. Esta etapa faz referência ao perfil técnico do Emissor de Token. Para emitir uma resposta SAML em vez da resposta JWT padrão, modifique a SendClaims etapa para fazer referência ao novo perfil Saml2AssertionIssuertécnico do Emissor do Token SAML.

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

Se você começou a partir de 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 order elemento corresponde ao número especificado no percurso do usuário para a etapa do emissor do token. Por exemplo, nas outras pastas do pacote inicial, o número da etapa correspondente é 4 para LocalAccounts, 6 para SocialAccountse 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 qual protocolo seu aplicativo usa. O padrão é OpenId. O Protocol elemento deve ser alterado para SAML. As declarações de saída criarão o mapeamento de declarações para a declaração SAML.

Substitua todo o elemento <TechnicalProfile> dentro do elemento <RelyingParty> pelo seguinte XML de perfil técnico.

    <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

Você pode seguir esse mesmo processo para implementar outros tipos de fluxos de usuário (por exemplo: entrada, redefinição de senha ou fluxos de edição de perfil).

Carregar sua política

Salve suas alterações e carregue os novos arquivos de políticaTrustFrameworkExtensions.xml e SignUpOrSigninSAML.xml no portal do Azure.

Testar os metadados SAML do IdP do Azure Active Directory B2C

Depois que os arquivos de política são carregados, o Azure AD B2C usa 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 da 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. Veja 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 AD B2C confie em seu aplicativo, crie um registro de aplicativo do Azure AD 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 seu locatário do Azure AD B2C no menu Diretórios + assinaturas.
  3. No menu à esquerda, selecione Azure AD B2C. Ou selecione Todos os serviços e, em seguida, pesquise e selecione O Azure AD 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 insira https://localhost. Você modifica esse valor posteriormente no manifesto do registro do aplicativo.
  8. Selecione Registrar.

Configurar seu aplicativo no Azure AD B2C

Para aplicativos SAML, você precisa configurar várias propriedades no manifesto do registro do aplicativo.

  1. No portal do Azure, acesse o registro do aplicativo que você criou na seção anterior.
  2. Em Gerenciar, selecione Manifesto para abrir o editor de manifesto. Em seguida, modifique as propriedades descritas nas seções a seguir.

Adicionar o identificador

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

No manifesto de registro, localize o identifierURIs parâmetro e adicione o valor apropriado. Esse valor será o mesmo valor configurado nas solicitações de SAML AuthN para o EntityId no aplicativo e o valor entityID nos metadados do aplicativo. Você também precisará localizar o accessTokenAcceptedVersion parâmetro 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 entityID valor 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 identifierUris propriedade aceita URLs somente 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.

Recomendamos que seu aplicativo exponha um endpoint de metadados publicamente acessível.

Se houver propriedades especificadas em ambos, a URL de metadados SAML e o 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ê usaria 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 como o Location atributo do AssertionConsumerService elemento, 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 AssertionConsumerService do aplicativo estiver ausente ou você quiser substituí-lo, configure a propriedade do manifesto replyUrlsWithType de registro do aplicativo. O Azure AD B2C usa o replyUrlsWithType para redirecionar os usuários depois que eles são conectados usando o HTTP-POST tipo de associação.

Usando o aplicativo de teste SAML como exemplo, você definiria a url propriedade 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 como o Location atributo do SingleLogoutService elemento, 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 SingleLogoutService do aplicativo estiver ausente, configure a propriedade do manifesto logoutUrl 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, você definiria a logoutUrl propriedade 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 na sua aplicação SAML

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

Os metadados podem ser configurados em seu aplicativo como metadados estáticos ou metadados dinâmicos. No modo estático, copie todos ou parte dos metadados da política do Azure AD B2C. No modo dinâmico, forneça a URL para os metadados e permita que seu aplicativo leia os metadados dinamicamente.

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

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

  • Emissor: O valor da solicitação SAML issuer deve corresponder a um dos URIs configurados no elemento de manifesto identifierUris do registro de aplicativo. Se o nome da issuer solicitação SAML não existir no identifierUris elemento, adicione-o ao manifesto de registro do 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. Vá para a URL de metadados especificada anteriormente.
    2. Copie o valor do 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

Você pode usar 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 URI do emissor. Use um dos URIs encontrados no identifierUris elemento no manifesto de registro do aplicativo. Por exemplo, use https://contoso.onmicrosoft.com/app-name.

Selecione Logon e uma tela de login do usuário deve aparecer. Depois de entrar, uma resposta SAML será enviada de volta para o aplicativo de exemplo.

Modalidades SAML com e sem suporte

Os seguintes cenários de aplicativo SAML são suportados por meio de seu próprio endpoint 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 pelo IdP, em que o provedor de identidade é Azure AD B2C.