Provisionamento de Usuários e Grupos¶

App Builder suporta provisionamento automatizado de usuários e grupos. O provisionamento reduz a carga administrativa ao minimizar a criação manual de usuários e grupos dentro App Builder.

Estratégias de Provisionamento¶

As estratégias de provisionamento se enquadram em uma de duas categorias:

Just-In-Time (JIT) - As contas de usuário são criadas sob demanda durante o processo de login.
APIs do Provedor de Serviços (SP) - Os Provedores de Identidade (IdPs) gerenciam usuários e grupos por meio de APIs fornecidas pelo SP.

Cada abordagem tem vantagens e desvantagens.

As desvantagens do provisionamento JIT incluem:

Os usuários não podem ser desprovisionados.
O SP não tem uma lista completa de usuários e grupos.
Usuários e grupos podem ficar fora de sincronia se não tiverem um identificador imutável (como um GUID ou SID).

As desvantagens das APIs SP incluem:

A maioria das APIs de SP são proprietárias (Salesforce, Azure, Google, etc.). Padrões emergentes, como o System for Cross-Domain Identity Management (SCIM), não são comumente implantados.
Uma API SP é mais complicada de configurar, geralmente exigindo codificação personalizada.
Todos os usuários precisam ser registrados no SP. Contas de usuários existentes precisam ser registradas em massa durante a configuração inicial.

App Builder estratégia de Provisionamento da¶

App Builder implementa o provisionamento JIT no nível do provedor de segurança. Quando habilitado, App Builder cria contas de usuário após validar com sucesso tokens de segurança (como uma asserção SAML ou código de autorização OAuth 2.0).

Ao configurar o provisionamento de usuário, os administradores podem indicar se o token de segurança inclui associação de grupo. Nesse caso, App Builder extrairá os grupos do token de segurança, registrando-os dentro App Builder e associar o usuário a esses grupos. Observe que nem todos os esquemas de autenticação oferecem suporte a essa opção. Revise a documentação do provedor de segurança para obter mais informações.

Conforme observado acima, a estratégia JIT não oferece suporte ao desprovisionamento de usuários. App Builder atenua essa limitação ao proibir o login local. Especificamente, se a conta do usuário não tiver uma senha atribuída, o usuário não poderá fazer login App Builder diretamente. Independentemente disso, os administradores de segurança precisarão fazer login App Builder e exclua quaisquer contas de usuários órfãos.

Habilitando o Provisionamento¶

O provisionamento de usuários pressupõe que a autenticação seja delegada a um Provedor de Identidade (IdP). Como tal, o provisionamento de usuários requer um provedor de segurança de autenticação, como um provedor de segurança Single Sign-On (SSO). Exemplos incluem SAML SSO (como Okta), WS-Federation (Azure Active Directory ou Active Directory Federation Services) ou outros provedores de autenticação externos (por exemplo, Salesforce).

O provisionamento de usuários é desabilitado por padrão e deve ser habilitado por um administrador de segurança. Para habilitar o provisionamento de usuários:

Navegue até o IDE.
Clique em Provedores de segurança.
Clique duas vezes no Provedor de Segurança aplicável no painel Autenticação do Usuário.
Clique em Editar no painel Provedor.
Marque a opção Provisionamento de Usuário.
Clique no botão Salvar.

Mapeando Identidades para Usuários Existentes¶

Por padrão, o processo de provisionamento de usuário criará novas contas de usuário, mas não mapeará uma identidade para uma conta existente. O provisionamento falhará se existir um usuário com o nome fornecido.

Se o IdP for uma fonte única e confiável de autoridade, considere habilitar a opção Match Existing User. Esta opção permite que o processo de provisionamento mapeie uma identidade para um usuário existente com o mesmo nome. O mapeamento só ocorre se a conta de usuário ainda não tiver uma identidade associada ao provedor de segurança.

A opção Match Existing User fica disponível após habilitar User Provisioning.

Configurando Autorização¶

O provisionamento de usuários é apenas uma parte do quebra-cabeça. Por padrão, novas contas de usuário não terão acesso a nenhum aplicativo. Para automatizar totalmente o processo de provisionamento, os administradores vão querer garantir que novos usuários recebam privilégios apropriados ao fazer login. Há 4 abordagens que podem ser tomadas:

Por padrão, novos usuários são adicionados ao grupo de segurança Usuários. Os administradores podem conceder ao grupo Usuários acesso a um ou mais aplicativos. Isso geralmente não é recomendado. O grupo de segurança Usuários é destinado a todos os usuários autenticados. Como resultado, todos os usuários autenticados terão acesso aos aplicativos concedidos, o que pode não ser o resultado desejado. Além disso, App Builder possui o grupo de segurança Usuários e pode modificar o grupo durante uma atualização.
Crie um novo grupo de segurança e habilite a opção Conceder na criação de usuário. Quando Conceder na criação de usuário está habilitado, os usuários recém-criados são adicionados ao grupo automaticamente. Isso é preferível à opção nº 1 porque usa um grupo de segurança personalizado em vez do grupo Usuários integrado. No entanto, a opção Conceder na criação de usuário se aplica a todos os usuários, independentemente de serem criados manualmente por meio da interface do usuário ou provisionados automaticamente por um provedor de segurança.
Crie um novo grupo de provedores de segurança e habilite a opção Conceder na criação de identidade. Ao contrário de um grupo de segurança, um grupo de provedores de segurança é específico para um provedor de segurança. Como na opção nº 2, os administradores precisarão criar um grupo de segurança e conceder a ele acesso a um ou mais aplicativos. No entanto, não habilite a opção Conceder na criação de usuário. Em vez disso, crie um grupo de provedores de segurança, mapeie-o para o grupo de segurança interno e habilite a opção Conceder na criação de identidade. Usando essa técnica, apenas os usuários provisionados pelo provedor de segurança receberão privilégios automaticamente.
Se o provedor de segurança fornecer associação ao grupo, a autorização pode ser transferida do Provedor de Identidade (IdP) para App Builder. App Builder extrairá as declarações de associação de grupo do token de segurança e registrará esses grupos como grupos de provedores de segurança. Os administradores devem mapear um ou mais grupos de provedores de segurança para grupos de segurança internos. Essa opção leva mais tempo para ser configurada e pode exigir configuração adicional no Provedor de Identidade (IdP). No entanto, uma vez configurado, App Builder honrará a associação de grupo fornecida pelo IdP.

As opções 3 e 4 são mutuamente exclusivas: ou App Builder ou o provedor de segurança pode gerenciar grupos de provedores de segurança, mas não ambos. No entanto, ambos podem ser combinados com a opção Conceder na criação do usuário.