Cenário - Usando o Microsoft Entra ID para proteger o acesso a plataformas e aplicativos SAP

Este documento fornece conselhos sobre o projeto técnico e a configuração de plataformas e aplicativos SAP ao usar o Microsoft Entra ID como o principal serviço de autenticação de usuário para o SAP Cloud Identity Services. O SAP Cloud Identity Services inclui autenticação de identidade, provisionamento de identidade, diretório de identidade e gerenciamento de autorização. Saiba mais sobre a configuração inicial para autenticação no tutorial de integração de logon único (SSO) do Microsoft Entra com o SAP Cloud Identity Services. Para obter mais informações sobre provisionamento e outros cenários, consulte Planejar a implantação do Microsoft Entra para provisionamento de usuários com aplicativos de origem e destino SAP e gerenciar o acesso aos seus aplicativos SAP.

Terminologia usada neste guia

Descrição geral

Há muitos serviços e componentes na pilha de tecnologia SAP e Microsoft que desempenham um papel em cenários de autenticação e autorização de usuários. Os principais serviços estão listados no diagrama abaixo.

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

• Você deseja controlar todas as suas identidades centralmente e somente a partir do Microsoft Entra ID.
• Você deseja reduzir ao máximo os esforços de manutenção e automatizar a autenticação e o acesso ao aplicativo na Microsoft e no SAP.
• A orientação geral para o Microsoft Entra ID com IAS aplica-se a aplicativos implantados em aplicativos BTP e SAP SaaS configurados no IAS. Recomendações específicas também serão fornecidas, quando aplicável, para BTP (por exemplo, usando mapeamentos de função com grupos do Microsoft Entra) e aplicativos SAP SaaS (por exemplo, usando o serviço de provisionamento de identidade para autorização baseada em função).
• Também assumimos que os usuários já estão provisionados no Microsoft Entra ID e em qualquer sistema SAP que exija que os usuários sejam provisionados para funcionar. Independentemente de como isso foi alcançado: o provisionamento poderia ter sido feito manualmente, do Ative Directory local através do Microsoft Entra Connect ou através de sistemas de RH como o SAP SuccessFactors. Neste documento, portanto, SuccessFactors é considerado um aplicativo como qualquer outro que os usuários (existentes) entrarão. Não cobrimos o provisionamento real de usuários do SuccessFactors para o Microsoft Entra ID. Para obter mais informações sobre como trazer usuários para o Microsoft Entra ID para uso com cargas de trabalho SAP, consulte Planejar a implantação do Microsoft Entra para provisionamento de usuários com aplicativos de origem e destino SAP e gerenciar o acesso aos seus aplicativos SAP.

Com base nestes pressupostos, concentramo-nos principalmente nos produtos e serviços apresentados no diagrama abaixo. Estes são os vários componentes mais relevantes para autenticação e autorização em um ambiente baseado em nuvem.

Se você estiver usando o SAP Identity Management (IDM), poderá migrar cenários de gerenciamento de identidades do SAP IDM para o Microsoft Entra. Para obter mais informações, consulte Migrar cenários de gerenciamento de identidades do SAP IDM para o Microsoft Entra.

Recomendações

Resumo

• 1 - Use a autenticação federada em aplicativos SAP Business Technology Platform e SAP SaaS através do SAP Identity Authentication Service
• 2 - Use o Microsoft Entra ID para autenticação e IAS/BTP para autorização
• 3 - Use grupos do Microsoft Entra para autorização por meio de coleções de funções no IAS/BTP
• 4 - Use uma única subconta BTP apenas para aplicativos que tenham requisitos de identidade semelhantes
• 5 - Usar o locatário IAS de produção para todos os usuários finais Autenticação e Autorização
• 6 - Definir um processo de substituição de certificados de assinatura SAML

1 - Use a autenticação federada em aplicativos SAP Business Technology Platform e SAP SaaS através do SAP Identity Authentication Service

Contexto

Seus aplicativos em 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 BTP/XSUAA e o provedor de identidade. Observe que apenas SAML 2.0 é suportado, mesmo que o protocolo OpenID Connect seja usado entre o próprio aplicativo e BTP/XSUAA (não relevante neste contexto).

No BTP, você pode optar por configurar uma configuração de confiança para o SAP Cloud Identity Services - Identity Authentication (que é o padrão), mas quando seu diretório de usuário autoritativo é Microsoft Entra ID, você pode configurar a federação para que os usuários possam entrar com suas contas existentes do Microsoft Entra.

Além da federação, você também pode, opcionalmente, configurar o provisionamento de usuários para que os usuários do Microsoft Entra sejam provisionados antecipadamente no BTP. No entanto, não há suporte nativo para isso (apenas para Microsoft Entra ID -> SAP Identity Authentication Service), uma solução integrada com suporte nativo seria o BTP Identity Provisioning Service. 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 conseguir isso com os grupos do Microsoft Entra (veja abaixo), o que pode significar que você não precisa de provisionamento de usuário.

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

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

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

O que recomendamos?

Quando seu diretório de usuário autoritativo é Microsoft Entra ID, recomendamos configurar uma configuração de confiança no BTP para IAS. O IAS, por sua vez, é configurado para se federar com o Microsoft Entra ID como um Provedor de Identidade Corporativa.

Na configuração de confiança no BTP, recomendamos que "Criar usuários sombra durante o logon" esteja habilitado. Desta forma, os utilizadores que ainda não foram criados em BTP, obtêm automaticamente uma conta quando iniciam sessão através do IAS / Microsoft Entra ID pela primeira vez. Se essa configuração for desabilitada, somente os usuários pré-provisionados terão permissão para entrar.

Porquê esta recomendação?

Ao usar a federação, você pode optar por definir a configuração de confiança no nível da Subconta BTP. Nesse caso, você deve repetir a configuração para cada Subconta que está usando. Ao usar 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 autenticação baseada em risco e enriquecimento centralizado de atributos de asserção. Para proteger a experiência do usuário, esses recursos avançados de segurança só devem ser aplicados em um único local. Isso poderia ser IAS ou ao manter o Microsoft Entra ID como o único armazenamento de usuário autorizado (como é a premissa deste artigo), isso seria tratado centralmente pelo Microsoft Entra Conditional Access Management.

Nota: para o IAS, cada Subconta é considerada uma "aplicação", mesmo que dentro dessa Subconta uma ou mais aplicações possam ser implementadas. Dentro do IAS, cada aplicativo desse tipo pode ser configurado para federação com o mesmo provedor de identidade corporativa (Microsoft Entra ID neste caso).

Resumo da aplicaçã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 ativado, os utilizadores não precisam de escrever as palavras-passe para iniciar sessão no Microsoft Entra ID e, habitualmente, nem sequer o nome de utilizador.

No Microsoft Entra ID e IAS:

• Siga a documentação para conectar o Microsoft Entra ID ao IAS no modo de federação (proxy) (SAP doc, Microsoft doc). Fique atento à configuração em NameID sua configuração de SSO no Microsoft Entra ID, porque UPNs não são necessariamente endereços de email.
• Configure o "Aplicativo Incluído" para usar a ID do Microsoft Entra indo para a página "Autenticação Condicional" e definindo o "Provedor de Identidade de Autenticação Padrão" para o Provedor de Identidade Corporativa que representa seu diretório do Microsoft Entra.

Na BTP:

• Configure uma configuração de confiança para IAS (doc SAP) e certifique-se de que "Disponível para logon do usuário" e "Criar usuários sombra durante o logon" estejam habilitados.
• Opcionalmente, desative "Disponível para logon do usuário" na configuração de confiança padrão do "SAP ID Service" para que os usuários sempre se autentiquem por meio do Microsoft Entra ID e não recebam uma tela para escolher seu provedor de identidade.

2 - Use o Microsoft Entra ID para autenticação e IAS/BTP para autorização

Contexto

Quando o BTP e o IAS foram configurados para autenticação de usuário via federação para 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 entradas e, fazendo isso, impedindo o acesso ao aplicativo no BTP.
• No 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 "Atribuição de usuário necessária" no Aplicativo Empresarial na ID do Microsoft Entra. Observe que, para aplicativos SAML, essa configuração é habilitada por padrão, portanto, você deve executar uma ação explícita para desativá-la.

Porquê esta recomendação?

Quando o aplicativo é federado através do IAS, do ponto de vista do Microsoft Entra ID o usuário está essencialmente "autenticando no IAS" durante o fluxo de entrada. Isso significa que o Microsoft Entra ID não tem informações sobre qual aplicativo BTP final 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 muito grosseira, por exemplo, permitindo que o usuário entre em qualquer aplicativo no BTP, ou em nenhum. Isso também enfatiza a estratégia da SAP para isolar aplicativos e mecanismos de autenticação no nível de subconta BTP.

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

Resumo da aplicação

No Aplicativo Empresarial Microsoft Entra que representa a relação de federação com o IAS, desative "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 - Use 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 BTP, há várias opções:

• Você pode configurar o 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 no BTP, com base em atribuições de usuário ou atribuições de grupo.

A implementação final pode utilizar 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 usuário a 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 autorizada para autorização refinada, recomendamos usar grupos do Microsoft Entra e atribuí-los a Coleções de Funções no BTP. Conceder aos usuários acesso a determinados aplicativos significa simplesmente adicioná-los ao(s) grupo(s) Microsoft Entra relevante(s) sem qualquer configuração adicional necessária no IAS/BTP.

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

Porquê esta recomendação?

Se você atribuir usuários diretamente às Coleções de Funções no BTP, não estará centralizando 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 poder ser atribuído a uma Coleção de Funções no BTP - e dado que recomendamos federação em vez de provisionamento de usuário, isso significa que a conta sombra do usuário pode não existir ainda 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 contradizer a recomendação anterior de não usar o ID do Microsoft Entra para autorização. Mesmo neste caso, no entanto, a decisão de autorização ainda está sendo tomada no BTP, só que a decisão agora é baseada na associação de grupo mantida no Microsoft Entra ID.

Recomendamos usar a ID de Grupo do grupo Microsoft Entra em vez de seu nome, porque a ID de Grupo é globalmente exclusiva, imutável e nunca pode ser reutilizada para outro grupo mais tarde; considerando que usar o nome do grupo pode levar a problemas quando o nome é alterado, e há um risco de segurança em ter um grupo sendo excluído e outro sendo criado com o mesmo nome, mas com usuários nele que não devem ter acesso ao aplicativo.

Resumo da aplicação

No Microsoft Entra ID:

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

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

  • Além disso, para manter as cargas úteis de declarações pequenas e evitar esbarrar na limitação pela qual o ID do Microsoft Entra limitará o número de declarações de grupo a 150 em asserções SAML, é altamente recomendável limitar os grupos retornados nas declarações apenas aos grupos que foram explicitamente 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 SAI:

• Na configuração do Provedor de Identidade Corporativa, nas opções de Federação de Identidades, certifique-se de desabilitar "Usar armazenamento de usuário de Autenticação de Identidade", caso contrário, as informações do grupo do ID do Microsoft Entra não serão preservadas no token SAML para BTP e a autorização falhará.

Na BTP:

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

4 - Use uma única subconta BTP apenas para aplicativos que tenham requisitos de identidade semelhantes

Contexto

Dentro do BTP, cada Subconta pode conter vários aplicativos. No entanto, do ponto de vista do IAS, uma "Aplicação Integrada" é uma Subconta BTP completa, não as aplicações 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 no 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 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, marca, ...).

Porquê esta recomendação?

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

Resumo da aplicação

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

5 - Usar o locatário IAS de produção para todos os usuários finais Autenticação e Autorização

Contexto

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

O que recomendamos?

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

Recomendamos o uso de outros locatários IAS apenas para testar a configuração relacionada à identidade, que deve ser feita isoladamente do locatário de produção.

Porquê esta recomendação?

Como o IAS é o componente centralizado que foi configurado para federar com o Microsoft Entra ID, há apenas um único local onde a federação e a configuração de identidade devem ser configuradas e mantidas. A duplicação disso em outros locatários IAS pode levar a configurações incorretas ou inconsistências no acesso do usuário final entre ambientes.

6 - Definir um processo de substituição de certificados de assinatura SAML

Contexto

Ao configurar a federação entre o ID do Microsoft Entra e o IAS, bem como entre o IAS e o BTP, são trocados metadados SAML que contêm 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 em que um certificado foi comprometido, por exemplo).

Nota: o período de validade padrão do certificado Microsoft Entra inicial usado para assinar asserções SAML é de 3 anos (e observe que o certificado é específico para o Aplicativo Empresarial, ao contrário dos tokens 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 expiram, 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 sendo usados para assinar os tokens SAML.

Em alguns casos, a terceira parte confiável pode fazer isso automaticamente fornecendo um ponto de extremidade de metadados que retorna as informações de metadados mais recentes dinamicamente - ou seja, normalmente uma URL acessível publicamente a partir da qual a terceira parte confiável pode recuperar periodicamente os metadados e atualizar seu armazenamento de configuração interna.

No entanto, o IAS só permite que os Provedores de Identidade Corporativa sejam configurados por meio de uma importação do arquivo XML de metadados, ele não suporta o 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, o BTP não permite que uma nova Configuração de Confiança seja configurada a partir do ponto de extremidade de metadados IAS (por exemplo https://my-ias-tenant.accounts.ondemand.com/saml2/metadata), ele também precisa de um carregamento único de um arquivo XML de metadados.

O que recomendamos?

Ao configurar a federação de identidades entre quaisquer dois sistemas (por exemplo, Microsoft Entra ID e IAS, bem como IAS e BTP), certifique-se de capturar a data de expiração dos certificados que estão sendo usados. Certifique-se de que esses certificados possam ser substituídos com bastante antecedência e de que haja um processo documentado para atualizar os novos metadados em todas as partes confiáveis que dependem desses certificados.

Como discutido anteriormente, recomendamos configurar uma configuração de confiança no BTP para IAS, que por sua vez é 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 SAML) são importantes:

• O certificado de subconta em BTP: quando isso muda, a configuração SAML 2.0 do aplicativo no IAS deve ser atualizada.
• O certificado de locatário no IAS: quando isso muda, a Configuração SAML 2.0 do Aplicativo Empresarial na ID do Microsoft Entra e a Configuração de Confiança no BTP devem ser atualizadas.
• O certificado de aplicativo corporativo no Microsoft Entra ID: quando isso é alterado, a configuração SAML 2.0 do provedor de identidade corporativa no IAS deve ser atualizada.

A SAP tem exemplos de implementações para notificações de certificados de clientes com SAP Cloud Integration e tratamento de quase expiração. Isso pode ser adaptado com o Azure Integration Services ou o PowerAutomate. No entanto, eles precisariam ser adaptados para trabalhar com certificados de servidor. Tal abordagem requer uma implementação personalizada.

Porquê esta recomendação?

Se os certificados tiverem permissão para expirar, ou quando forem substituídos a tempo, mas as 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 aplicação

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

Considere a automação de edifícios para executar todo o processo de substituição de certificados. Por exemplo, pode-se verificar periodicamente se há certificados expirando e substituí-los enquanto atualiza todas as partes confiáveis com os novos metadados.

Usando o Azure AD B2C como o provedor de identidade

O Azure Ative Directory B2C fornece identidade de empresa para cliente como um serviço. Dado que a integração com o Azure AD B2C é semelhante à forma como você permitiria que os usuários corporativos entrassem com a ID do Microsoft Entra, 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 sociais, empresariais ou locais preferidas.

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

Registrando um aplicativo SAML no Azure AD B2C

O Azure AD B2C não tem uma galeria de aplicativos corporativos que você possa usar para configurar facilmente a relação de confiança com o Provedor de Identidade Corporativa no IAS. Em vez disso, você terá que usar políticas personalizadas para registrar um aplicativo SAML no Azure AD B2C. No entanto, esse aplicativo SAML desempenha a mesma função lógica que o aplicativo corporativo no Microsoft Entra ID, portanto, a mesma orientação sobre a substituição de certificados SAML se aplica, por exemplo.

Autorização com o Azure AD B2C

O Azure AD B2C não suporta nativamente o uso de grupos para criar coleções de usuários aos quais você pode atribuir acesso, o que significa que a orientação para usar grupos do Microsoft Entra para autorização por meio de Coleções de Funções no BTP precisa ser implementada de forma diferente.

Felizmente, o Azure AD B2C é altamente personalizável, portanto, você pode configurar os tokens SAML enviados ao IAS para incluir quaisquer informações personalizadas. Para obter 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, você pode, opcionalmente, ainda 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, elas podem ser emitidas como o Groups atributo 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. No entanto, observe 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 Groups atributo.

Passos Seguintes

• Saiba mais sobre a configuração inicial neste tutorial
• planejar a implantação do Microsoft Entra para provisionamento de usuários com aplicativos de origem e destino SAP e
• gerenciar o acesso aos seus aplicativos SAP
• Descubra cenários adicionais de integração SAP com o Microsoft Entra ID e muito mais