Cenário – uso do Microsoft Entra ID para proteger o acesso a aplicativos e plataformas do SAP

Este documento dá conselhos sobre o design técnico e a configuração de plataformas e aplicativos da SAP ao usar o Microsoft Entra ID como o principal serviço de autenticação de usuário. Saiba mais sobre a configuração inicial neste tutorial.

Terminologia usada neste guia

Abreviação	Descrição
BTP	Business Technology Platform do SAP. O conjunto da oferta de tecnologia do SAP. A maioria das tecnologias do SAP discutidas aqui fazem parte do BTP. Os produtos formalmente conhecidos como SAP Cloud Platform fazem parte do SAP BTP.
IAS	SAP Cloud Identity Services – Identity Authentication Service. O serviço provedor de identidade em nuvem multilocatário fornecido pela SAP. O IAS ajuda os usuários a se autenticarem em suas próprias instâncias de serviço do SAP.
IDS	SAP ID Service. Uma instância do IAS usada pelo SAP para autenticar clientes e parceiros em serviços de PaaS e SaaS operados pelo SAP.
IPS	SAP Cloud Identity Services – Identity Provisioning Service. O IPS ajuda a sincronizar identidades entre diferentes sistemas de armazenamento/destino.
XSUAA	Extended Services for Cloud Foundry User Account and Authentication. XSUAA é um servidor de autorização OAuth multilocatário dentro do SAP BTP.
CF	Cloud Foundry. O Cloud Foundry é o ambiente no qual a SAP construiu sua oferta multinuvem para BTP (AWS, Azure, GCP, Alibaba).
Fiori	A experiência do usuário baseada na Web do SAP (em oposição à experiência baseada na área de trabalho).

Visão geral

Há muitos serviços e componentes na pilha de tecnologia do SAP e da Microsoft que desempenham uma função nos cenários de autenticação e autorização de usuários. Os principais serviços estão listados no diagrama a seguir.

Como há muitas permutações dos possíveis cenários a serem configurados, nos concentramos em um cenário que está de acordo com uma estratégia de priorização de identidade do Microsoft Entra. Faremos as seguintes suposições:

• Você deseja controlar todas as suas identidades centralmente e somente do Microsoft Entra ID.
• Você deseja reduzir os esforços de manutenção o máximo possível e automatizar a autenticação e o acesso de aplicativos entre a Microsoft e o SAP.
• As diretrizes gerais para o Microsoft Entra ID com o IAS destinam-se a aplicativos implantados em aplicativos SaaS da BTP e do SAP configurados no IAS. Recomendações específicas também serão fornecidas quando aplicável ao BTP (por exemplo, usando mapeamentos de função com grupos do Microsoft Entra) e aplicativos SaaS do SAP (por exemplo, usando o serviço de provisionamento de identidade para autorização baseada em função).
• Também supomos que os usuários já estejam provisionados no Microsoft Entra ID e em qualquer sistema SAP que exija que os usuários sejam provisionados para a função. Não importa como isso foi conseguido: o provisionamento pode ter sido feito manualmente, no Active Directory local por meio do Microsoft Entra Connect ou por meio de sistemas de RH, como o SAP SuccessFactors. Portanto, neste documento, o SuccessFactors é considerado como um aplicativo como qualquer outro em que usuários (existentes) farão logon. Não abordamos o provisionamento real de usuários do SuccessFactors no Microsoft Entra ID.

Com base nessas pressuposições, vamos nos concentrar principalmente nos produtos e serviços apresentados no diagrama a seguir. Esses são os diversos componentes mais relevantes para autenticação e autorização em um ambiente baseado em nuvem.

Observação

A maioria das diretrizes aqui se aplica a Azure Active Directory B2C também, mas há algumas diferenças importantes. Consulte usando Azure AD B2C como o provedor de identidade para obter mais informações.

Aviso

Lembre-se dos limites de declaração do SAP SAML e do impacto do comprimento dos nomes de coleção de funções do SAP Cloud Foundry e da quantidade de coleções com proxy por grupos no SAP Cloud Identity Service. Consulte a Nota SAP 2732890 para obter mais informações. Limites excedidos resultam em problemas de autorização.

Recomendações

Resumo

• 1 – Usar a Autenticação Federada na Business Technology Platform do SAP e em aplicativos SaaS do SAP por meio do Identity Authentication Service do SAP
• 2 – usar o Microsoft Entra ID para autenticação e o IAS/BTP para autorização
• 3 – Usar grupos do Microsoft Entra para Autorização por meio de Coleções de Funções no IAS/BTP
• 4 – Usar uma única subconta da BTP somente para aplicativos que têm requisitos de Identidade semelhantes
• 5 – Usar o locatário do IAS de produção para toda a Autenticação e Autorização do usuário final
• 6 – Definir um Processo para a Sobreposição de Certificado de Autenticação SAML

1 – Usar a Autenticação Federada na Business Technology Platform do SAP e em aplicativos SaaS do SAP por meio do Identity Authentication Service do SAP

Contexto

Seus aplicativos na BTP podem usar provedores de identidade por meio de Configurações de Confiança para autenticar usuários usando o protocolo SAML 2.0 entre a BTP/o XSUAA e o provedor de identidade. Observe que somente o SAML 2.0 tem suporte, embora o protocolo OpenID Connect seja usado entre o próprio aplicativo e a BTP/o XSUAA (não relevante neste contexto).

Na BTP, você pode optar por definir uma configuração de confiança em relação ao Serviço de ID do SAP (que é o padrão), mas quando o seu diretório de usuário autoritativo é o Microsoft Entra ID, você pode configurar a federação para que os usuários possam entrar com as contas existentes do Microsoft Entra.

Além da federação, você também pode configurar o provisionamento de usuário para que os usuários do Microsoft Entra sejam provisionados antecipadamente na BTP. No entanto, não há suporte nativo para isso (somente para Microsoft Entra ID -> Identity Authentication Service do SAP); uma solução integrada com suporte nativo seria o Identity Provisioning Service da BTP. O provisionamento de contas de usuário antecipadamente pode ser útil para fins de autorização (por exemplo, para adicionar usuários a funções). Dependendo dos requisitos, no entanto, você também pode fazer isso com os grupos do Microsoft Entra (veja abaixo), evitando a necessidade de provisionamento de usuários.

Ao configurar a relação de federação, há várias opções:

• Você pode optar por federar no Microsoft Entra ID diretamente da BTP/XSUAA.
• Você pode optar por federar com o IAS que, por sua vez, é configurado para federar com o Microsoft Entra ID como um Provedor de Identidade Corporativa (também conhecido como "proxy de SAML").

Para aplicativos SaaS do SAP, o IAS é provisionado e pré-configurado para facilitar a integração de usuários finais. (Exemplos disso incluem SuccessFactors, Marketing Cloud, Cloud4Customer, Sales Cloud e outros). Esse cenário é menos complexo, pois o IAS está diretamente conectado ao aplicativo de destino e não faz proxy com o XSUAA. Em qualquer caso, as mesmas regras se aplicam a essa configuração para o Microsoft Entra ID com o IAS em geral.

O que recomendamos?

Quando o seu diretório de usuário autoritativo é o Microsoft Entra ID, é recomendável definir uma configuração de confiança na BTP em relação ao IAS. O IAS, por sua vez, é configurado para federar com o Microsoft Entra ID como um Provedor de Identidade Corporativa.

Na configuração de confiança da BTP, recomendamos que a opção "Create Shadow Users During Logon" esteja habilitada. Dessa forma, os usuários que ainda não tiverem sido criados na BTP, receberão automaticamente uma conta quando entrarem por meio do IAS/Microsoft Entra ID pela primeira vez. Se essa configuração for desabilitada, somente usuários previamente provisionados teriam permissão para entrar.

Por que essa recomendação?

Ao usar a federação, você pode optar por definir a configuração de confiança no nível da Subconta da BTP. Nesse caso, você deve repetir a configuração para cada subconta que estiver usando. Usando o IAS como uma configuração de confiança intermediária, você se beneficia da configuração centralizada em várias subcontas e pode usar recursos do IAS, como a autenticação baseada em risco e o enriquecimento centralizado de atributos de asserção. Para proteger a experiência do usuário, esses recursos de segurança avançados devem ser aplicados somente em um único local. Este pode ser o IAS ou ao manter o Microsoft Entra ID como o único repositório de usuário autoritativo (como é a premissa deste documento), que seria centralmente tratado pelo Gerenciamento de Acesso Condicional do Microsoft Entra.

Observação: para o IAS, todas as Subcontas são consideradas um "aplicativo", embora um ou mais aplicativos possam ser implantados dentro dessa subconta. No IAS, cada aplicativo desse tipo pode ser configurado para federação com o mesmo provedor de identidade corporativa (o Microsoft Entra ID, neste caso).

Resumo da implementação

No Microsoft Entra ID:

• Opcionalmente, configure o Microsoft Entra ID para logon único contínuo (SSO contínuo), que conecta automaticamente os usuários quando eles estão em seus dispositivos corporativos conectados à sua rede corporativa. Quando habilitado, os usuários não precisam digitar as senhas para entrar no Microsoft Entra ID e, geralmente, nem precisam digitar os nomes de usuário.

No Microsoft Entra ID e IAS:

• Siga a documentação para conectar o Microsoft Entra ID ao IAS no modo de federação (proxy) (documentação do SAP, documentação da Microsoft). Tome cuidado com a configuração NameID em sua configuração de SSO no Microsoft Entra ID, pois os UPNs não são necessariamente endereços de email.
• Configure o "Aplicativo Empacotado" para usar o Microsoft Entra ID acessando a página "Autenticação Condicional" e definindo o "Provedor de Identidade de Autenticação Padrão" como o Provedor de Identidade Corporativa que representa o seu diretório do Microsoft Entra.

Na BTP:

• Defina uma configuração de confiança para o IAS (documentação do SAP) e confirme se as opções "Available for User Logon" e "Create Shadow Users During Logon" estão habilitadas.
• Opcionalmente, desabilite "Available for User Logon" na configuração de confiança padrão do "Serviço de ID do SAP" para que os usuários sempre se autentiquem por meio do Microsoft Entra ID e não se deparem com uma tela para escolher o provedor de identidade.

2 – usar o Microsoft Entra ID para autenticação e o IAS/BTP para autorização

Contexto

Quando a BTP e o IAS foram configurados para autenticação de usuário por meio de federação com o Microsoft Entra ID, há várias opções para configurar a autorização:

• No Microsoft Entra ID, você pode atribuir usuários e grupos do Microsoft Entra ao aplicativo empresarial que representa sua instância do SAP IAS no Microsoft Entra ID.
• No IAS, você pode usar a Autenticação Baseada em Risco para permitir ou bloquear as entrada e, fazendo isso, você impede o acesso ao aplicativo na BTP.
• Na BTP, você pode usar Coleções de Funções para definir quais usuários e grupos podem acessar o aplicativo e obter determinadas funções.

O que recomendamos?

Recomendamos que você não coloque nenhuma autorização diretamente no próprio Microsoft Entra e desative explicitamente a opção "Atribuição de usuário necessária" no Aplicativo Empresarial no Microsoft Entra ID. Observe que, para aplicativos SAML, essa configuração está habilitada por padrão, portanto, você deve realizar uma ação explícita para desabilitá-la.

Por que essa recomendação?

Quando o aplicativo é federado por meio do IAS, do ponto de vista do Microsoft Entra ID, o usuário está essencialmente "se autenticando no IAS" durante o fluxo de entrada. Isso significa que o Microsoft Entra ID não tem informações de qual aplicativo final da BTP o usuário está tentando entrar. Isso também implica que a autorização no Microsoft Entra ID só pode ser usada para fazer uma autorização de granularidade muito alta, por exemplo, permitindo que o usuário entre em qualquer ou em nenhum aplicativo na BTP. Isso também enfatiza a estratégia do SAP de isolar aplicativos e mecanismos de autenticação no nível de Subconta da BTP.

Embora isso possa ser um motivo válido para usar a opção "Atribuição de usuário necessária", também significa que agora há potencialmente dois locais diferentes em que as informações de autorização precisam ser mantidas: no Microsoft Entra ID no Aplicativo Empresarial (em que se aplica a todos os aplicativos da BTP), bem como em cada Subconta da BTP. Isso pode levar à confusão e configurações incorretas em que as configurações de autorização são atualizadas em um local, mas não em outro. Por exemplo: um usuário foi permitido na BTP, mas não atribuído ao aplicativo no Microsoft Entra ID, resultando em uma falha na autenticação.

Resumo da implementação

No Aplicativo Empresarial do Microsoft Entra que representa a relação de federação com o IAS, desabilite "Atribuição de usuário necessária". Isso também significa que você pode ignorar com segurança a atribuição de usuários.

3 – Usar grupos do Microsoft Entra para Autorização por meio de Coleções de Funções no IAS/BTP

Contexto

Quando você deseja configurar a autorização para seus aplicativos da BTP, há várias opções:

• Você pode configurar um controle de acesso refinado dentro do próprio aplicativo, com base no usuário conectado.
• Você pode especificar o acesso por meio de Funções e Coleções de Funções na BTP, com base em atribuições de usuário ou atribuições de grupo.

A implementação final pode usar uma combinação de ambas as estratégias. No entanto, para a atribuição por meio de Coleções de Funções, isso pode ser feito por usuário ou pode-se usar grupos do provedor de identidade configurado.

O que recomendamos?

Se você quiser usar o Microsoft Entra ID como a fonte autoritativa para autorização refinada, recomendamos usar grupos do Microsoft Entra e atribuí-los a Coleções de Funções na BTP. Assim, conceder aos usuários o acesso a determinados aplicativos significa simplesmente adicioná-los aos grupos relevantes do Microsoft Entra sem nenhuma configuração posterior necessária no IAS/na BTP.

Com essa configuração, recomendamos usar a ID de Grupo (ID de Objeto) do grupo do Microsoft Entra como o identificador exclusivo do grupo, e não o nome de exibição ("sAMAccountName"). Isso significa que você deve usar a ID do Grupo como a declaração "Grupos" no token SAML emitido pelo Microsoft Entra ID. Além disso, a ID do Grupo é usada para a atribuição à Coleção de Funções na BTP.

Por que essa recomendação?

Se você atribuir usuários diretamente a Coleções de Funções na BTP, não centralizará as decisões de autorização no Microsoft Entra ID. Isso também significa que o usuário já deve existir no IAS antes de ser atribuído a uma Coleção de Funções na BTP – e, considerando que recomendamos federação em vez de provisionamento de usuários, isso significa que a conta de sombra do usuário pode ainda não existir no IAS no momento em que você deseja fazer a atribuição de usuário. Usar grupos do Microsoft Entra e atribuí-los a Coleções de Funções elimina esses problemas.

A atribuição de grupos a Coleções de Funções pode parecer uma contradição à recomendação anterior de não usar o Microsoft Entra ID para autorização. Mesmo nesse caso, no entanto, a decisão de autorização ainda está sendo tomada na BTP; o que ocorre é que a decisão agora é baseada na associação de grupo mantida no Microsoft Entra ID.

É recomendável usar a ID de Grupo do grupo do Microsoft Entra em vez de seu nome porque a ID do Grupo é globalmente exclusiva, imutável e nunca poderá ser reutilizada para outro grupo; enquanto que o uso do nome do grupo poderá levar a problemas quando o nome for alterado e haverá um risco de segurança se um grupo for excluído e outro criado com o mesmo nome, mas com usuários que não deveriam ter acesso ao aplicativo.

Resumo da implementação

No Microsoft Entra ID:

• Crie grupos aos quais os usuários podem ser adicionados, que precisam de acesso a aplicativos na BTP (por exemplo, crie um grupo do Microsoft Entra para cada Coleção de Funções na BTP).
• No Aplicativo Empresarial do Microsoft Entra que representa a relação de federação com o IAS, configure os Atributos e Declarações do Usuário do SAML para adicionar uma declaração de grupo para grupos de segurança:

  • Defina o atributo Source como "ID de Grupo" e o Name como Groups (escrito exatamente assim, com 'G' maiúsculo).

  • Além disso, para manter o conteúdo das declarações pequeno e evitar a limitação pela qual o Microsoft Entra ID limitará o número de declarações de grupo a 150 nas declarações SAML, é altamente recomendável limitar os grupos retornados nas declarações somente aos grupos que explicitamente foram atribuídos:

    • Em "quais grupos associados ao usuário devem ser retornados na declaração?", responda com "grupos atribuídos ao aplicativo". Em seguida, para os grupos que você deseja incluir como declarações, atribua-os ao Aplicativo Empresarial usando a seção "Usuários e Grupos" e selecionando "Adicionar usuário/grupo".

    

No IAS:

• Na configuração do Provedor de Identidade Corporativa, nas opções de Federação de Identidade, desabilite "Usar repositório do usuário do Identity Authentication"; caso contrário, as informações do grupo do Microsoft Entra ID não serão preservadas no token SAML em relação à BTP e a autorização falhará.

Observação

Se você precisar usar o armazenamento de usuário de autenticação de identidade (por exemplo, para incluir declarações que não podem ser originadas do Microsoft Entra ID, mas que estão disponíveis no repositório de usuários do IAS), você pode manter essa configuração habilitada. Nesse caso, no entanto, será necessário configurar os atributos padrão enviados ao aplicativo para incluir as declarações relevantes provenientes do Microsoft Entra ID (por exemplo, com o formato ${corporateIdP.Groups}).

Na BTP:

• Nas Coleções de Funções usadas pelos aplicativos nessa Subconta, mapeie as Coleções de Funções para Grupos de Usuários adicionando uma configuração para o Provedor de Identidade do IAS e definindo o Nome como a ID do Grupo (ID de Objeto) do grupo do Microsoft Entra.

Observação

Caso você tenha outra declaração no Microsoft Entra ID para conter as informações de autorização a serem usadas no BTP, você não precisa usar o nome da declaraçãoGroups. Isso é o que o BTP usa quando você mapeia as coleções de função para grupos de usuários como acima, mas você também pode mapear as coleções de funções para atributos de usuário, o que proporciona um pouco mais de flexibilidade.

4 – Usar uma única subconta da BTP somente para aplicativos que têm requisitos de Identidade semelhantes

Contexto

Na BTP, cada Subconta pode conter vários aplicativos. No entanto, do ponto de vista do IAS, um "Aplicativo Empacotado" é uma Subconta completa da BTP, e não os aplicativos mais granulares dentro dela. Isso significa que todas as Configurações de confiança, Autenticação e Acesso, bem como as opções de Identidade Visual e Layout no IAS se aplicam a todos os aplicativos dentro dessa Subconta. Da mesma forma, todas as Configurações de Confiança e Coleções de Funções na BTP também se aplicam a todos os aplicativos dentro dessa Subconta.

O que recomendamos?

Recomendamos que você combine vários aplicativos em uma única Subconta da BTP somente se eles tiverem requisitos semelhantes no nível de identidade (usuários, grupos, provedores de identidade, funções, configuração de confiança, identidade visual...).

Por que essa recomendação?

Ao combinar vários aplicativos que têm requisitos de identidade muito diferentes em uma única Subconta na BTP, você pode obter uma configuração insegura ou que pode ser mais facilmente configurada de maneira errada. Por exemplo: quando uma alteração de configuração de um recurso compartilhado como um provedor de identidade é feita para um único aplicativo na BTP, isso afeta todos os aplicativos que dependem desse recurso compartilhado.

Resumo da implementação

Considere cuidadosamente como você deseja agrupar vários aplicativos em Subcontas na BTP. Para obter mais informações, confira a Documentação do Modelo de Conta do SAP.

5 – Usar o locatário do IAS de produção para toda a Autenticação e Autorização do usuário final

Contexto

Ao trabalhar com o IAS, normalmente você tem um locatário de Produção e Desenvolvimento/Teste. Para diferentes Subcontas ou aplicativos na BTP, você pode escolher qual provedor de identidade (locatário do IAS) usar.

O que recomendamos?

É recomendável sempre usar o locatário do IAS de Produção para qualquer interação com os usuários finais, mesmo no contexto de uma versão de desenvolvimento/teste ou no ambiente do aplicativo no qual eles precisam entrar.

É recomendável usar outros locatários do IAS somente para testar a configuração relacionada à identidade, o que deve ser feito isoladamente do locatário de Produção.

Por que essa recomendação?

Como o IAS é o componente centralizado que foi definido para federar com o Microsoft Entra ID, há apenas um local em que a federação e a configuração de identidade devem ser configuradas e mantidas. Duplicar isso em outros locatários do IAS poderá levar a configurações incorretas ou inconsistências entre ambientes quando se tratar do acesso do usuário final.

6 – Definir um Processo para a Sobreposição de Certificado de Autenticação SAML

Contexto

Ao configurar a federação entre o Microsoft Entra ID e o IAS, bem como entre o IAS e a BTP, os metadados do SAML são trocados, contendo certificados X.509 usados para criptografia e assinaturas criptográficas dos tokens SAML que estão sendo enviados entre ambas as partes. Esses certificados têm datas de validade e devem ser atualizados periodicamente (mesmo em situações de emergência, quando um certificado foi comprometido, por exemplo).

Observação: o período de validade padrão do certificado inicial do Microsoft Entra usado para assinar declarações SAML é de 3 anos (e observe que o certificado é específico para o Aplicativo Empresarial, ao contrário dos tokens do OpenID Connect e OAuth 2.0 que são assinados por um certificado global no Microsoft Entra ID). Você pode optar por gerar um novo certificado com uma data de validade diferente ou criar e importar seu próprio certificado.

Quando os certificados perdem a validade, eles não podem mais ser usados e novos certificados devem ser configurados. Portanto, um processo deve ser estabelecido para manter a configuração do certificado dentro da terceira parte confiável (que precisa validar as assinaturas) atualizada com os certificados reais que estão sendo usados para assinar os tokens SAML.

Em alguns casos, a terceira parte confiável pode fazer isso automaticamente fornecendo a ele um ponto de extremidade de metadados que retorna dinamicamente as informações de metadados mais recentes, ou seja, normalmente uma URL publicamente acessível na qual a terceira parte confiável pode recuperar periodicamente os metadados e atualizar seu repositório de configurações interno.

No entanto, o IAS só permite que Provedores de Identidade Corporativa sejam configurados por meio de uma importação do arquivo XML de metadados; ele não dá suporte ao fornecimento de um ponto de extremidade de metadados para recuperação dinâmica dos metadados do Microsoft Entra (por exemplo, https://login.microsoftonline.com/my-azuread-tenant/federationmetadata/2007-06/federationmetadata.xml?appid=my-app-id). Da mesma forma, a BTP não permite que uma nova Configuração de Confiança seja configurada no ponto de extremidade de metadados do IAS (por exemplo, https://my-ias-tenant.accounts.ondemand.com/saml2/metadata), ela também precisa de um carregamento único de um arquivo XML de metadados.

O que recomendamos?

Ao configurar a federação de identidade entre dois sistemas (por exemplo, Microsoft Entra ID e IAS, bem como IAS e BTP), capture a data de validade dos certificados que estão sendo usados. Verifique se esses certificados podem ser substituídos com antecedência e se há um processo documentado para atualizar os novos metadados em todas as terceiras partes confiáveis que dependem desses certificados.

Conforme discutido anteriormente, é recomendável definir uma configuração de confiança na BTP com o IAS, que, por sua vez, está configurado para federar com o Microsoft Entra ID como um Provedor de Identidade Corporativa. Nesse caso, os seguintes certificados (que são usados para assinatura e criptografia de SAML) são importantes:

• O certificado da Subconta na BTP: quando ele é alterado, a Configuração do SAML 2.0 do aplicativo no IAS deve ser atualizada.
• O certificado do locatário no IAS: quando ele é alterado, a Configuração do SAML 2.0 do Aplicativo Empresarial no Microsoft Entra ID e a Configuração de Confiança na BTP devem ser atualizadas.
• O certificado do Aplicativo Empresarial no Microsoft Entra ID: quando ele é alterado, a Configuração do SAML 2.0 do Provedor de Identidade Corporativa no IAS deve ser atualizada.

A SAP tem implementações de exemplo para notificações de certificados de cliente com o SAP Cloud Platform Integration e gestão de vencimento próximo. Estes podem ser adaptados com o Integration Services ou PowerAutomate do Azure. No entanto, eles precisariam ser adaptados para trabalhar com certificados do servidor. Essa abordagem requer uma implementação personalizada.

Por que essa recomendação?

Se os certificados tiverem permissão para expirar ou quando forem substituídos a tempo, mas as terceiras partes confiáveis que dependem deles não forem atualizadas com as novas informações de certificado, os usuários não poderão mais entrar em nenhum aplicativo por meio da federação. Isso pode significar um tempo de inatividade significativo para todos os usuários enquanto você restaura o serviço reconfigurando os metadados.

Resumo da implementação

Adicione um endereço de notificação por email para a expiração do certificado no Microsoft Entra ID e defina-o como uma caixa de correio de grupo para que ele não seja enviado para um único indivíduo (que talvez até não tenha mais uma conta no momento em que o certificado estiver prestes a expirar). Por padrão, somente o usuário que criou o Aplicativo Empresarial receberá uma notificação.

Considere a criação de automação para executar todo o processo de substituição de certificado. Por exemplo, é possível verificar periodicamente os certificados que estiverem expirando e substituí-los, atualizando todas as terceiras partes confiáveis com os novos metadados.

Usando o Azure AD B2C como provedor de identidade

O Azure Active Directory B2C fornece a identidade de empresa para cliente como um serviço. Considerando que a integração com o Azure AD B2C é semelhante a como você permitiria que os usuários empresariais se inserissem com o Microsoft Entra ID, as recomendações acima ainda se aplicam principalmente quando você deseja usar o Azure AD B2C para seus clientes, consumidores ou cidadãos e permitir que eles usem suas identidades de conta social, empresarial ou local preferenciais.

No entanto, há algumas diferenças importantes, no entanto. A configuração do Azure AD B2C como um provedor de identidade corporativo na IAS e a definição da federação entre ambos os locatários são descritas em mais detalhes nesta postagem no blog.

Registrar um aplicativo SAML no Azure AD B2C

Azure AD B2C tem uma galeria de aplicativos empresariais que você pode usar para configurar facilmente a relação de confiança em relação ao Provedor de Identidade Corporativa na IAS. Em vez disso, você terá que usar políticas personalizadas para registrar um aplicativo SAML no Azure AD B2C. Esse aplicativo SAML desempenha a mesma função lógica que o aplicativo empresarial no Microsoft Entra ID, portanto, as mesmas diretrizes sobre a sobreposição de certificados SAML se aplica, por exemplo.

Autorização com o Azure AD B2C

O Azure AD B2C não dá suporte nativo ao uso de grupos para criar coleções de usuários aos quais você pode atribuir acesso, o que significa que as diretrizes para usar grupos do Microsoft Entra para autorização por meio de Coleções de Funções no BTP devem ser implementadas de maneira diferente.

Felizmente, Azure AD B2C é altamente personalizável, portanto, você pode configurar os tokens SAML que ele envia à IAS para incluir informações personalizadas. Para várias opções sobre como dar suporte a declarações de autorização, consulte a documentação que acompanha o exemplo de Funções de Aplicativo do Azure AD B2C, mas em resumo: por meio de seu mecanismo de extensibilidade do Conector de API opcionalmente, você ainda pode usar grupos, funções de aplicativo ou até mesmo um banco de dados personalizado para determinar o que o usuário tem permissão para acessar.

Independentemente de onde as informações de autorização vêm, ela pode ser emitida como o atributo Groups dentro do token SAML configurando esse nome de atributo como o tipo de declaração de parceiro padrão no esquema de declarações ou substituindo o tipo de declaração de parceiro nas declarações de saída. Observe, no entanto, que o BTP permite mapear coleções de funções para atributos de usuário, o que significa que qualquer nome de atributo pode ser usado para decisões de autorização, mesmo que você não use o nome do atributoGroups.

Próximas etapas

• Saiba mais sobre a configuração inicial neste tutorial
• Descobrir outros cenários de integração do SAP com o Microsoft Entra ID e muito mais