Configurar a autenticação do Alteryx Server
Configure o método de autenticação que deseja usar para gerenciar o acesso ao Server na página Configurações do sistema > Gallery Authentication.
Comece selecionando o método de autenticação que deseja usar para o Server. Em seguida, vá para as etapas de configuração do método selecionado.
Selecionar tipo de autenticação
O Server é compatível com autenticação interna, autenticação integrada do Windows (com ou sem suporte do Kerberos) e autenticação SAML.
Built-in (interna): os usuários especificam um endereço de e-mail e uma senha de sua escolha para acessar o Server.
Integrated Windows authentication (autenticação integrada do Windows): os usuários acessam o Server com credenciais de rede internas.
Integrated Windows authentication with Kerberos (autenticação integrada do Windows com Kerberos): os usuários acessam o Server com credenciais de rede internas usando protocolos de autenticação Kerberos. O processo de configuração para autenticação integrada do Windows e para autenticação integrada do Windows com Kerberos é o mesmo. Para obter mais informações, vá para Concluir a configuração do tipo de autenticação selecionado e escolha Configurar autenticação integrada do Windows.
SAML authentication (autenticação SAML): os usuários acessam o Server com credenciais do provedor de identidade (IDP).
Atenção
O Server não oferece suporte à alteração do tipo de autenticação após a configuração. Tentar fazer isso pode comprometer a funcionalidade do Server. Se você quiser alterar o tipo de autenticação, entre em contato com a equipe da sua conta para discutir as opções de assistência.
Concluir a configuração do tipo de autenticação selecionado
A configuração para cada tipo de autenticação varia. Selecione o tipo de autenticação desejado para ver as etapas para concluir a configuração.
Etapa 1. Definir o administrador padrão do Server para autenticação interna
Depois de selecionar Built-in (autenticação interna), atribua um administrador padrão para a IU do Server em Default Gallery Administrator, na parte inferior da página Gallery Authentication. O administrador do Server (Gallery) gerencia usuários, fluxos de trabalho e outros. Para o tipo de autenticação Built-in, digite o endereço de e-mail do administrador.
Conclua as telas restantes das Configurações do sistema (vá para as páginas de ajuda IU do Server e Motor para obter mais informações sobre essas telas) e clique em Finish para concluir.
Etapa 2. Concluir a criação da conta de administrador do Server
Para concluir a criação da conta de administrador da IU do Server, vá para a página de login do Server. Para fazer isso, clique no link para o Server exibido na página Configurações do sistema > Status ou digite o URL para o Server no seu navegador da Internet.
Clique em Entrar.
Na página de login, selecione Inscrever-se para uma nova conta.
Insira um Nome e um Sobrenome e selecione um fuso horário no menu suspenso.
Em E-mail, digite o endereço de e-mail do administrator que você forneceu no campo Default Gallery Administrator na página Configurações do sistema > Gallery Authentication.
Em Senha, crie uma senha de conta. A sua senha deve ter:
Pelo menos 8 caracteres
Pelo menos 1 letra
Pelo menos 1 número
Letras maiúsculas e minúsculas
Pelo menos 1 caractere especial
Clique em Inscrever-se.
Agora você está conectado como o administrador do Server (Gallery). As credenciais inseridas no formulário de inscrição serão salvas como as suas credencias. Agora você está pronto para adicionar usuários ao Server. Acesse Adicionar usuários do Server.
Importante
Se você estiver usando o AWS com autenticação do Windows, a conexão TCP terá que manter a mesma porta de origem para permanecer autenticada. Por esse motivo, recomendamos usar o balanceador de carga de rede ou clássico em vez do balanceador de carga do aplicativo.
Nota
A diferença na configuração entre a autenticação integrada do Windows e a autenticação integrada do Windows com Kerberos é o protocolo usado para autenticar usuários com o Active Directory. A opção para autenticação integrada do Windows usa NTLM, enquanto a autenticação integrada do Windows com Kerberos substitui o NTLM pelo Kerberos.
Nenhuma configuração especial é necessária dentro do próprio Server, mas a opção com Kerberos requer que realm Kerberos e KDC estejam corretamente configurados e presentes no domínio do Active Directory.
Etapa 1. Definir um administrador padrão do Server para autenticação do Windows
Depois de selecionar Integrated Windows authentication (autenticação integrada do Windows), atribua um administrador padrão para a IU do Server em Default Gallery Administrator na parte inferior da página Gallery Authentication. O administrador do Server (Gallery) gerencia usuários, fluxos de trabalho e outros. Para a opção Integrated Windows authentication, digite a conta de usuário neste formato: domínio\nomedeusuário.
Conclua as telas restantes das Configurações do sistema (vá para as páginas de ajuda IU do Server e Motor para obter mais informações sobre essas telas) e clique em Finish para concluir.
Etapa 2. Acessar o Server
O administrador padrão do Server (Gallery) agora pode acessar o Server. Para fazer isso, clique no link para o Server exibido na página Configurações do sistema > Status ou digite o URL para o Server no seu navegador da Internet. Agora você está conectado como administrador do Server (Gallery) e pronto para adicionar usuários ao Server. Acesse Adicionar usuários do Server.
Suporte a múltiplos domínios
O Server oferece suporte a múltiplos domínios para autenticação do Windows. Você não precisa configurar nada no Server para habilitar isso, mas esses recursos e permissões precisam estar presentes em todos os domínios.
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 configurar a autenticação SAML para login único (SSO), seu provedor de identidade (IDP) deve ter suporte para SAML.
Importante
Antes de configurar a autenticação SAML para o Server, você precisa adicioná-lo como um provedor de serviços no IDP. O IDP pode precisar de...
O URL base do ACS (por exemplo, http://localhost/webapi/Saml2/Acs).
O ID de entidade do provedor de serviços (por exemplo, http://localhost/webapi/Saml2).
A partir da versão 2022.3, estamos usando pontos de extremidade atualizados do provedor de serviços por meio do serviço da API Web. As configurações existentes que usam os pontos de extremidade anteriores continuam a funcionar, e nenhuma ação é necessária no momento para continuar usando SAML para seu Alteryx Server existente. Para obter mais informações, consulte as Notas de versão do Server 2022.3.
O IDP também pode exigir que você mapeie instruções de atributos de e-mail, nome e sobrenome (email, firstName e lastName) para os campos correspondentes no IDP para autenticar usuários.
O certificado de assinatura do IDP deve ser configurado com um algoritmo de assinatura SHA-256 ou superior.
Selecione uma opção para obter os metadados exigidos pelo IDP. Você pode configurar o SAML usando um URL de metadados do IDP pela opção IDP Metadata URL ou usar um certificado X509 e URL de SSO do IDP pela opção X509 certificate and IDP SSO URL.
Conclua a configuração na seção SAML IDP Configuration.
ACS Base URL: o URL para o serviço do consumidor de declaração (ACS) que aceita mensagens SAML para estabelecer uma sessão.
IDP URL: o URL para o aplicativo Alteryx configurado no IDP, também conhecido como o ID de entidade do IDP.
IDP Metadata URL: o URL fornecido pelo IDP que inclui o URL de SSO do IDP e o certificado X509 para configurar o serviço de autenticação da Alteryx.
IDP SSO URL: o URL de SSO, fornecido pelo IDP, que o serviço de autenticação da Alteryx usa para fazer login no IDP.
X509 certificate: o certificado público fornecido pelo IDP para comunicação segura com o serviço de autenticação da Alteryx.
Enable Request Signing: para IDPs que requerem assinatura de solicitação, você pode habilitar essa configuração para habilitar assinatura de solicitação. Essa configuração requer que um certificado assinado válido com uma chave privada RSA associada seja instalado no Repositório de Certificados do Windows.
SSL/TLS Certificate Hash: depois que o certificado e a chave privada estiverem instalados, forneça o hash exclusivo para o certificado SSL/TLS.
Verify IDP: clique para abrir uma janela do navegador, fazer login, testar a configuração do IDP e definir o administrador padrão do Server.
Definir um administrador padrão do Server para SAML
Uma conta de administrador do Server (Gallery) deve ser criada para administrar o site (gerenciar usuários, fluxos de trabalho e outros). Para a opção SAML authentication, clique em Verify IDP para testar a configuração do IDP e preencher o campo com credenciais do IDP.
Agora você está conectado como o administrador do Server. Agora você está pronto para adicionar usuários ao Server. Acesse Adicionar usuários do Server.
Nota
Os administradores podem sincronizar o acesso de usuários e grupos ao Server usando o Azure Active Directory (Azure AD) e o protocolo SCIM. Isso permite que os administradores gerenciem o acesso ao Server e as permissões para usuários e grupos usando o seu provedor de identidade. A sincronização de usuários e grupos do Azure AD para o Server é automática. Isso acelera a integração e a remoção de usuários do Server.
Essa funcionalidade está disponível para clientes que usam SAML como o método de autenticação. Qualquer provedor de identidade que ofereça suporte ao SCIM pode usar essa funcionalidade. Observe que somente testamos e oferecemos suporte oficialmente ao Azure AD.
Para ler mais sobre as configurações do SCIM, consulte Configurações do Alteryx Server.
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.
Consulte estas respostas para as perguntas mais importantes sobre o SCIM no Azure com o Alteryx Server:
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.