Configurar a autenticação do Alteryx Server

O domínio no qual o Server é executado precisa ter a mesma diretiva de confiança que outros usuários do domínio para que o Active Directory possa resolver e determinar as permissões de usuário.

Ambos os domínios precisam fazer parte da mesma floresta.

O Alteryx Service precisa ser capaz de ler todos os atributos dos contêineres CN=Users e CN=Computers para ambos os domínios. O Alteryx Service é executado na conta do sistema local no servidor em que está instalado. Se você definir uma conta de serviço dedicada em vez de usar o sistema local, a conta deve ter permissão para ler todos os atributos de ambos os contêineres para habilitar a autenticação para ambos os domínios.

Para obter informações sobre como configurar o Alteryx Server para SCIM com o Ative Directory do Azure, vá para Configurar o Server para SCIM com o Azure Active Directory .

Para obter mais informações sobre o SCIM no Azure, consulte a documentação do Microsoft Azure .

Para obter mais informações sobre como implantar e testar seu ponto de extremidade do SCIM no Azure, acesse Tutorial: desenvolver um ponto de extremidade de amostra do SCIM no Azure Active Directory .

Depois de habilitar o SCIM, todas as entidades no Azure (ou outro IDP) serão sincronizadas com o Server, e as alterações futuras nessas entidades causarão alterações nos objetos relacionados no Server. Os usuários e grupos existentes no Server que também existem no IDP serão vinculados e atualizados com as alterações do IDP. O IDP atua como a fonte de verdade para esses objetos. Por exemplo, digamos que o usuário João Silva exista em ambos e você tenha habilitado o SCIM. Se você alterar "João Silva" para "João Santos" no Server, a próxima sincronização alterará o nome de volta para "João Silva".

Os grupos são vinculados por nome e os usuários por e-mail.

Os usuários e grupos locais que existem apenas no Server estão fora do escopo do IDP e permanecerão como objetos gerenciados pelo Server.

Alguns caracteres podem não ser transferidos do SCIM para o Server — isso depende do IDP. Se o IDP permitir caracteres especiais, restritos ou reservados no nome de um grupo ou objeto de usuário, o caractere será sincronizado com o Server. Não permitimos nem proibimos explicitamente quaisquer caracteres para esses nomes de objetos.

O Server não inicia uma conexão com o IDP para o SCIM. Em vez disso, ele fornece um número de pontos de extremidade de API e um token de acesso que o IDP usa para iniciar uma conexão com o Server. Você pode testar manualmente esses pontos de extremidade usando ferramentas de teste de API padrão, como o Postman.

O registro em log de auditoria do Server audita todas as alterações feitas em objetos de usuários e grupos. Isso inclui as alterações feitas pelo SCIM.

O SCIM não atualiza a posse de ativos, funções ou permissões. Dessa forma, todos os usuários e grupos existentes mantêm os ativos que possuem atualmente, bem como as funções e permissões atribuídas a eles.

As configurações de grupo do Server determinam as permissões. O Azure Active Directory não armazena permissões.

Quando você sincroniza um grupo do AD do Azure com o Server, os administradores podem definir permissões para esse grupo recém-criado no Server. Depois, quando você adiciona um novo usuário a esse grupo do AD, o SCIM adiciona automaticamente esse usuário ao grupo do Server. O usuário então obtém permissões com base nesse grupo do Server.

O recurso SCIM inclui apenas a concessão de acesso de usuários e grupos ao Server a partir do Azure AD. Essa sincronização não inclui permissões para nenhum outro ativo no Azure, como bancos de dados. Os usuários ainda precisarão usar conexões do DCM ou do Server para todos os dados.

Se você tiver que reverter para uma versão mais antiga do Server que não inclua SCIM, o SCIM não funcionará e não estará disponível até que você atualize o Server novamente.

Se você restaurar um backup de banco de dados para como era antes de o SCIM ser configurado, será necessário reconfigurar o SCIM após a restauração e executar a sincronização inicial.

Se você tiver que restaurar um backup para uma versão do Server que usa SCIM, deverá executar uma ressincronização completa do lado do IDP para que nosso banco de dados seja sincronizado novamente com o IDP.

Quando você desabilita um usuário usando o SCIM, os agendamentos se comportam como fazem agora quando você desativa ou exclui um usuário. O comportamento será o mesmo do que desativar o usuário via IU do Server ou API ou excluir por meio da API. Para obter mais informações, acesse Desabilitar um usuário .

Os tempos de sincronização variam de acordo com o IDP e podem ser configuráveis. Para o Azure, as sincronizações podem levar até 40 minutos e são representadas por valor estático que não pode ser configurado.

Fizemos testes extensivos com o Azure e testes limitados com o Okta. No entanto, não foi possível testar o agente de provisionamento do Okta, pois ele é fornecido apenas aos clientes pagantes. Os outros IDPs devem funcionar, mas não foram testados.