- Introdução
- Melhores práticas
- Tenant
- Sobre o contexto do tenant
- Pesquisa de recursos em um tenant
- Gerenciamento de robôs
- Conectar Robôs ao Orchestrator
- Armazenamento de credenciais do robô no CyberArk
- Armazenamento de senhas do Unattended Robot no Azure Key Vault (somente leitura)
- Armazenamento de credenciais do Unattended Robot no HashiCorp Vault (somente leitura)
- Armazenando credenciais de Unattended Robots no AWS Secrets Manager (somente leitura)
- Exclusão de sessões não assistidas desconectadas e não responsivas
- Autenticação do robô
- Autenticação de robôs com credenciais de cliente
- Autenticação do SmartCard
- Auditar
- Configurações - Nível do tenant
- Serviço Catálogo de recursos
- Contexto de Pastas
- Automações
- Processos
- Trabalhos
- Gatilhos
- Logs
- Monitoramento
- Filas
- Ativos
- Armazenar Buckets
- Test Suite - Orchestrator
- Outras configurações
- Integrações
- Robôs Clássicos
- Administração do host
- Sobre o nível do host
- Gerenciamento dos administradores do sistema
- Gerenciando Tenants
- Configurando notificações de e-mail do sistema
- Logs de auditoria para o portal do host
- Modo de Manutenção
- Administração da organização
- Solução de problemas
Configurando a integração SAML
Você pode conectar o Orchestrator a qualquer provedor de identidade (IdP) que use o padrão SAML 2.0. Esta página descreve o processo geral mostrando alguns exemplos de configurações de integração do SAML.
-
As declarações SAML criptografadas do seu provedor de identidade não são compatíveis.
-
Você não pode pesquisar usuários e grupos a partir do seu provedor de identidade. Apenas os usuários do diretório provisionado estão disponíveis para pesquisa.
Para configurar a integração SAML, você precisa:
-
Permissões de administrador no Orchestrator e no seu provedor de identidade terceirizado.
Se você não tiver permissões de administrador em seu provedor de identidade, poderá trabalhar em conjunto com um administrador para concluir o processo de configuração.
-
UiPath® Studio e UiPath Assistant versão 2020.10.3 ou posterior, para que você possa configurá-los para usar a implantação recomendada.
Observação:Se você estiver usando a integração do Azure Active Directory para autenticação, recomendamos permanecer na integração do AAD porque é mais rica em recursos.
Se você decidir transicionar da integração do AAD, deverá substituir manualmente a atribuição de função feita por meio de grupos de diretório pela atribuição de função direta às contas de diretório para que não seja necessário recriar completamente seu esquema de acesso.
Se sua organização recicla endereços de e-mail, é importante remover todas as contas de usuário inativas antes de configurar a integração SAML.
Ao habilitar a integração, as contas locais presentes no Orchestrator podem ser vinculadas à conta do diretório no provedor de identidade externo que usa o mesmo endereço de e-mail. Essa vinculação de conta ocorre quando o usuário da conta do diretório com o endereço de e-mail faz logon pela primeira vez. A identidade do seu provedor de identidade herda todas as funções que a conta local tinha para que a transição seja perfeita.
Por isso, com contas locais inativas presentes no Orchestrator, existe o risco de que contas locais e contas de diretório sejam incompatíveis, o que pode levar à elevação não intencional de permissões.
Para remover contas de usuário inativas:
Agora, você deve configurar o Orchestrator e seu provedor de identidade (IdP) para a integração.
Mantenha esta guia do navegador aberta para mais tarde.
O Orchestrator pode se conectar a qualquer provedor de identidade (IdP) terceiro que use o padrão SAML 2.0.
Embora a configuração possa variar dependendo do IdP escolhido, validamos a configuração para os seguintes provedores:
-
OKTA
-
PingOne.
Você pode usar as instruções de configuração abaixo para configurar integrações com esses provedores.
Para outros provedores de identidade, recomendamos que siga suas documentações de integração.
A. Configuração de amostra para Okta
- Em uma guia diferente do navegador, faça login no Console de administração do Okta.
- Vá para Aplicativos > Aplicativos, clique em Criar Integração de Aplicativo e selecione SAML 2.0 como o método de login.
- Na página Configurações gerais, especifique um nome para o aplicativo com o qual você está integrando, ou seja, Orchestrator.
-
Na página Configurar SAML, preencha a seção Geral da seguinte forma:
- URL de logon único: insira o valor do URL do Serviço de Confirmação do Cliente que você obteve do Orchestrator.
- Selecione a caixa de seleção Use isso para URL de destinatário e URL de destino.
- URI de audiência: insira o valor do ID de entidade que você obteve do Orchestrator.
- Formato do ID do nome: selecione EmailAddress
- Nome de usuário do aplicativo: selecione Email
-
Para Declarações de Atributo, adicione o seguinte:
-
Nome:
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
- Deixe o Formato do Nome como Não especificado.
-
Defina Valor como
user.email
ou o atributo de usuário que contém os endereços de e-mail exclusivos do usuários. - Opcionalmente, adicione outros mapeamentos de atributos. O Orchestrator também oferece suporte aos seguintes atributos de usuário: Nome, Sobrenome, Cargo e Departamento. Essa informação é então propagada para o Orchestrator, onde pode ser disponibilizada para outros serviços, como o Automation Hub.
-
Nome:
- Na página Feedback, selecione a opção de sua preferência.
- Clique em Concluir.
- Na guia Login, na seção Configurações, em Exibir instruções de configuração, copie o valor do URL de metadados do provedor de identidade e salve-o para uso posterior.
- Na página Aplicativo para o Orchestrator, selecione o aplicativo recém-criado.
- Na guia Atribuições, selecione Atribuir > Atribuir a pessoas e, em seguida, selecione os usuários que você deseja permitir que usem a autenticação SAML para o Orchestrator.
B. Configuração de exemplo para PingOne
Para habilitar o Orchestrator como um provedor de serviços que reconhece seu provedor de identidade, conclua as etapas abaixo:
Para validar se a integração do SAML SSO está funcionando corretamente:
- Abra uma janela do navegador no modo anônimo.
- Navegue até o seu URL do Orchestrator.
-
Verifique o seguinte:
- Você é solicitado a fazer login com seu provedor de identidade SAML?
- Você consegue fazer login com sucesso?
- Se estiver fazendo login com um endereço de e-mail que corresponda a uma conta de usuário existente, você tem as permissões apropriadas?
Os administradores podem configurar regras de provisionamento just-in-time que adicionam automaticamente usuários a um grupo do UiPath existente usando os pares de nome/valor do atributo fornecidos pelo IdP por meio de login. Ao utilizar grupos, os usuários são provisionados automaticamente com as licenças e funções certas quando fazem login.
As regras de provisionamento just-in-time são avaliadas quando um usuário faz logon. Se a conta de usuário atender às condições para uma regra, ela será adicionada automaticamente ao grupo local associado à regra.
group
, Relacionamento=is
, Valor=Automation User
.
Fase 1. Configure grupos de provisionamento
Adicionar uma conta a um grupo significa que a conta herda as licenças, funções e configuração do UiPath Robot definidas para o grupo, se houver.
Portanto, se configurar um grupo com um tipo específico de usuário em mente (por exemplo, seus funcionários que criam as automações ou seus funcionários que testam as automações), você pode integrar um novo funcionário desse tipo simplesmente definindo sua conta no IdP da mesma forma que outras contas semelhantes.
Dessa forma, você configura o grupo uma vez e replica a configuração adicionando contas ao grupo quando necessário. Além disso, se a configuração de um determinado grupo de usuários precisar ser alterada, você só precisará atualizar o grupo uma vez e as alterações se aplicarão a todas as contas do grupo.
Para configurar um grupo para uma regra de provisionamento:
-
Se desejar, você pode usar um de seus grupos existentes em vez de criar um novo.
-
(Opcional e requer gerenciamento de licença de usuário) Se os usuários deste grupo precisarem de licenças de usuário, configure as regras de alocação de licença para o grupo.
Se você estiver usando um grupo existente, verifique a alocação de licença para o grupo para certificar-se de que as licenças corretas estão sendo alocadas. Se não, altere as alocações ou considere a criação de um novo grupo.
-
Atribua funções de tenant e, opcionalmente, conclua a configuração do robô para o grupo. Consulte Como atribuir funções a um grupo.
Se você estiver usando um grupo existente, verifique as funções atribuídas ao grupo para certificar-se de que sejam adequadas para o tipo de usuário que você adicionará ao grupo. Se não forem, edite as funções atribuídas a este grupo ou considere a criação de um novo grupo.
-
Adicione o grupo às pastas e atribua funções de pasta, conforme necessário. Consulte Gerenciando o acesso à pasta.
Agora você pode usar esse grupo em uma regra de provisionamento.
Fase 2. Crie uma regra de provisionamento para um grupo
Certifique-se de que a declaração associada à regra de provisionamento SAML seja enviada para a carga útil SAML configurando-a no aplicativo SAML.
Depois que a integração SAML estiver configurada e depois de definir um grupo:
- Vá para Administrador > Configurações de segurança > Configurações de autenticação.
-
Na opção SAML SSO, clique em Exibir regras de provisionamento:
A página Regras de provisionamento de SAML SSO é aberta, na qual suas regras existentes são listadas.
-
No canto superior direito da página, clique em Adicionar regra.
A página Adicionar nova regra é aberta.
- Em Detalhes básicos, preencha o campo Nome da regra e, opcionalmente, preencha o campo Descrição.
-
Em Condições, clique em Adicionar regra.
Uma linha de campos para uma nova condição é adicionada. Juntos, eles definem os critérios que uma conta deve atender ao fazer login para ser adicionada a um grupo (escolhido posteriormente).
- No campo Claim, digite o nome da declaração, conforme aparece no IdP.
-
Na lista Relacionamento, selecione como a declaração se relaciona com o valor. As seguintes opções estão disponíveis:
Relacionamento
Requisito de condição
Exemplo
está
correspondência exata, sensível a maiúsculas e minúsculas
Department is RPA
exige que o valor da declaraçãoDepartment
sejaRPA
.A condição não é atendida se o valor forRPADev
, por exemplo.Essa relação funciona para declarações de múltiplos valores.
Por exemplo, se os valoresadministrator
edeveloper
forem enviados sob a declaraçãoGroup
, entãoGroup is administrator
seria uma relação válida.não está
qualquer coisa exceto o valor especificado, sensível a maiúsculas e minúsculas
ParaDepartment is not ctr
, qualquer conta é adicionada ao grupo, a menos queDepartment
tenha o valorctr
.A condição é satisfeita se o departamento forCtr
ouelectr
.contém
inclui, não requer uma correspondência exata, sensível a maiúsculas e minúsculas
Department contains RPA
requer que o valor para declaraçãoDepartment
incluaRPA
.A condição é satisfeita se o valor forRPADev
,xRPAx
, ouNewRPA
, por exemplo.não contém
exclui, não requer uma correspondência exata, sensível a maiúsculas e minúsculas
ParaDepartment not contains ctr
, qualquer conta é adicionada ao grupo, a menos que o valor deDepartment
incluactr
.Contas para as quais o departamento éctr
ouelectr
, por exemplo, não são adicionadas ao grupo.não diferencia maiúsculas de minúsculas
correspondência exata, não sensível a maiúsculas e minúsculas
Department is case insensitive RPA
requer que o valor para a declaraçãoDepartment
sejarpa
, independente de maiúsculas e minúsculas.A condição é satisfeita se o valor forrpa
, por exemplo. A condição não é satisfeita se o valor forcrpa
.contém maiúsculas e minúsculas
inclui, não requer uma correspondência exata, não sensível a maiúsculas e minúsculas
Department contains case insensitive RPA
requer que o valor para a declaraçãoDepartment
incluaRPA
, independente de maiúsculas e minúsculas.A condição é satisfeita se o valor forrpa
,cRPA
, ourpA
, por exemplo. - No campo Valor, digite o valor necessário para satisfazer à condição.
-
Se você quiser adicionar outra condição, clique em Adicionar regra para adicionar uma nova linha de condição.
Ao adicionar várias condições, todas as condições devem ser satisfeitas para que a regra de provisionamento seja aplicada. Por exemplo, se você definir as regrasDepartment is RPA
eTitle is Engineer
, somente os usuários que estiverem no departamento de RPA e tiverem o título Engenheiro serão adicionados aos grupos especificados. Uma conta para a qual o departamento é RPA, mas o título é QA, não é adicionada aos grupos. -
Em Atribuir a grupos, na caixa Adicionar Grupos, comece a digitar o nome de um grupo e selecione um grupo na lista de resultados. Repita o processo para adicionar mais grupos, se necessário.
Quando as condições forem satisfeitas, as contas serão adicionadas automaticamente a esses grupos quando fizerem login.
- Clique em Salvar no canto inferior direito para adicionar a regra.
Com uma regra em vigor, sempre que um usuário fizer login e sua conta atender às condições especificadas para uma regra, a sua conta será adicionada aos grupos de provisionamento anexados à regra, e a sua conta será configurada para funcionar.
Depois que as permissões forem configuradas, recomendamos que você peça a todos os usuários existentes que desconectem-se de suas contas da UiPath e façam login novamente usando o SAML SSO.
Para fazer login no Studio e no Assistant usando o SAML SSO, os usuários devem configurar o Assistant da seguinte forma:
Isso é necessário apenas para novos usuários que não usaram o Orchestrator antes e, portanto, não tinham uma conta local configurada para si no Orchestrator quando a integração foi habilitada.
Você pode adicionar novos usuários aos grupos do Orchestrator usando seu endereço de e-mail (o mesmo usado no IdP externo). Depois que um usuário for atribuído a um grupo ou estiver conectado, ele estará disponível por meio da pesquisa de atribuição de função em todos os serviços do Orchestrator.
Depois que todos os usuários fizerem a transição para o SAML SSO e os novos usuários forem configurados, recomendamos que você remova todas as contas de usuários locais que não sejam contas de administrador. Isso garante que os usuários não possam mais fazer login com suas credenciais de conta local e tenham que fazê-lo via SAML SSO.
- Restrições conhecidas
- Pré-requisitos
- Etapa 1. Limpe contas de usuário inativas
- Etapa 2. Configure a integração SAML
- Etapa 2.1. Obtenha detalhes do provedor de serviços SAML
- Etapa 2.2. Configurar seu provedor de identidade
- Etapa 2.3. Configurar o Orchestrator
- Etapa 2.4. Verifique se a integração está em execução
- Etapa 2.5. Configure regras de provisionamento (opcional)
- Etapa 3. Faça a transição de seus usuários para SAML SSO
- Etapa 4. Configure permissões e robôs
- Etapa 5. Descontinue o uso de contas de usuários locais (opcional)
- Considerações para descontinuar o uso de contas locais