Este guia foi escrito para administradores de TI e identidade que gerenciam uma instância EK on-premise. Qualquer referência a “seu IdP”, “seu administrador de IdP” ou “seu domínio de e-mail” refere-se à infraestrutura da sua própria organização — não a nada gerenciado pela Automation Anywhere.
Pré-requisitos
Antes de começar, confirme o seguinte:- Sua implantação EK on-premise está em execução com tanto o backend (
<your-backend-host>quanto o frontend (<your-frontend-host>) acessíveis pelo navegador do usuário. O IdP só precisa receber respostas SAML HTTP-POST em<your-backend-host>/user/generic/sso/saml/acs/admin— ele não precisa de conectividade de saída direta ao seu backend se você fornecer os metadados SP como um arquivo para download. - Você está logado no EK como Super Admin. A aba SSO Metadata e todos os seus endpoints subjacentes são restritos a Super Admins.
- Seu IdP é compatível com SAML 2.0 e pode consumir um XML/URL de metadados SP, ou ser configurado manualmente com um Entity ID e URL ACS do SP.
- Seu IdP está configurado para enviar o endereço de e-mail do usuário como o
NameIDSAML, usando o formatourn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress. O EK usa o NameID para buscar ou provisionar contas de usuário. - Você conhece o domínio de e-mail para o qual deseja habilitar o SSO (por exemplo,
acme.com). O SSO é vinculado por domínio, então todos os usuários compartilhando esse domínio —alice@acme.com,bob@acme.com, etc. — serão roteados para o mesmo IdP. - Você sabe qual modo de SSO do frontend sua implantação está executando. Isso é controlado pela variável de ambiente
VITE_ALLOW_ONLY_SSO_LOGINno frontend:true— SSO de clique único. O domínio é codificado viaVITE_SSO_ENTERPRISE_IDe deve corresponder exatamente ao domínio para o qual você carrega os metadados.false(padrão) — SSO com modal de e-mail. O domínio é derivado do e-mail do usuário no login. Vários domínios podem ter seus próprios metadados carregados.
Parte 1 — Fornecer Metadados SP ao Seu IdP
Seu administrador de IdP precisa registrar o EK como uma aplicação SAML no seu IdP antes que você possa carregar quaisquer metadados do IdP. O EK torna isso simples publicando seus metadados SP por meio de um endpoint público e bem conhecido — sem necessidade de cópia manual de campos.O Endpoint de Metadados SP
O backend EK publica seus metadados SP em:EntityDescriptor SAML 2.0 compatível com padrões, contendo o Entity ID da sua instância, URL ACS, formato NameID exigido e certificado de assinatura SP (quando configurado). O endpoint é não autenticado por design para que seu IdP possa buscá-lo diretamente.
Como Compartilhar os Metadados SP
Opção A — Fornecer a URL
Opção A — Fornecer a URL
Se seu IdP puder acessar o host do backend EK, envie a URL bem conhecida diretamente ao seu administrador de IdP:A maioria dos IdPs modernos (Okta, Entra ID, Ping, OneLogin, Auth0, etc.) pode importar metadados SP de uma URL e preencherá automaticamente a configuração SP — Entity ID, URL ACS, formato NameID e certificado de assinatura — a partir dele.
Opção B — Baixar e Entregar o Arquivo
Opção B — Baixar e Entregar o Arquivo
Se seu IdP não puder acessar o host do backend diretamente — comum em redes segmentadas, ambientes isolados ou quando seu IdP é um SaaS fora do perímetro corporativo — baixe o XML e passe-o ao seu administrador de IdP por canal alternativo:Seu administrador de IdP carrega
ek_sp_metadata.xml na tela de configuração da aplicação SAML do IdP. Você só precisa reexportar e recarregar quando a configuração SP mudar — tipicamente uma alteração de hostname do backend, rotação de certificado de assinatura SP ou alteração de override do Entity ID.Configuração Manual (Quando o IdP Não Pode Consumir Metadados)
Se seu IdP exigir que os campos sejam inseridos manualmente, use os valores do XML de metadados SP. Os campos mais comumente exigidos são:| Campo | Valor |
|---|---|
| Entity ID / Audience | O atributo entityID no <md:EntityDescriptor> na resposta de metadados SP. Padrão para a URL ACS; pode ser sobrescrito no momento da implantação via CUSTOM_ENTITY_ID_FOR_GENERIC_SSO. |
| ACS URL / Reply URL / Single Sign-On URL | https://<your-backend-host>/user/generic/sso/saml/acs/admin — sempre o host do backend, nunca o frontend. |
| Binding | HTTP-POST |
| Formato NameID | urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress |
| Sign AuthnRequests | true se sua implantação EK tiver um certificado SP configurado (anunciado nos metadados como AuthnRequestsSigned); caso contrário, false. |
| Want Assertions Signed | true — sempre. O EK requer assinatura de asserções. |
O Que Seu Administrador de IdP Precisa Devolver
Depois que a aplicação SAML for criada no seu IdP, peça ao seu administrador de IdP os metadados XML do IdP SAML. Este é o arquivo que você carregará na Parte 2. Quase todo IdP pode produzir este arquivo. Nomes comuns para ele nas interfaces do IdP:| IdP | Onde Encontrar |
|---|---|
| Okta | Link “Identity Provider metadata” na aba Sign On da aplicação |
| Entra ID / Azure AD | Download “Federation Metadata XML” na aba SSO |
| Ping / OneLogin / Auth0 / ADFS / Keycloak | Geralmente rotulado como “Metadata” ou “SAML Metadata”, disponível para download como XML |
EntityDescriptor SAML 2.0 válido contendo um IDPSSODescriptor com pelo menos o entityID do IdP, um local e ligação SingleSignOnService, e o certificado de assinatura do IdP para que o EK possa verificar as asserções.
Parte 2 — Carregar os Metadados do IdP
Com o XML de metadados do IdP em mãos, você pode agora registrá-lo contra um domínio de e-mail na sua instância EK.Abrir a Aba de Metadados SSO
Abrir o Painel do Super Admin
Vá para o menu da sua conta no canto superior direito e clique em Super Admin Dashboard.
Ir para a aba de Metadados SSO
Mude para a aba SSO Metadata. Você verá uma tabela de mapeamentos existentes domínio → metadados com três colunas:
- SSO Domain — o domínio de e-mail para o qual os metadados estão registrados (por exemplo,
acme.com). - Updated — a última vez que os metadados para aquele domínio foram carregados ou substituídos.
- Actions — controles para baixar, atualizar ou excluir os metadados armazenados para aquela linha.
Adicionar Metadados para um Novo Domínio
Abrir o diálogo de Adicionar Metadados
Clique em Add Metadata no canto superior direito da aba SSO Metadata. Se nenhum domínio estiver configurado ainda, você também pode clicar nele no cartão de estado vazio.
Inserir o domínio de e-mail
No campo SSO Team Email Domain, insira o domínio ao qual o SSO deve se aplicar — por exemplo,
acme.com. Use apenas a porção do domínio do endereço de e-mail: sem @, sem caminho, sem esquema. O valor é normalizado para minúsculas ao salvar.Escolher o método de upload e fornecer o XML
- Upload de Arquivo
- Colar Conteúdo XML
Selecione o arquivo
.xml fornecido pelo seu administrador de IdP. Apenas arquivos com extensão .xml são aceitos.Cada domínio pode ter no máximo um documento de metadados do IdP ativo por vez. Recarregar para o mesmo domínio substitui os metadados existentes — consulte Atualizar Metadados para um Domínio Existente abaixo.
Atualizar Metadados para um Domínio Existente
Os IdPs rodam certificados de assinatura e ocasionalmente alteram endpoints. Quando isso acontecer, coordene com seu administrador de IdP para que o novo XML seja carregado no EK antes que o IdP comece a assinar asserções com a nova chave.Fornecer o novo XML
O diálogo Update SSO Metadata é aberto com o domínio pré-preenchido e bloqueado. Você não pode alterar o domínio em uma atualização — se precisar reaproveitar a entrada, exclua-a e adicione novamente. Escolha seu método de upload e forneça o novo XML como faria para um novo domínio.
Baixar os Metadados Atualmente Armazenados
Clique no ícone de download na coluna Actions da linha. O arquivo é salvo como<dominio>_saml_metadata.xml.
Útil para:
- Confirmar quais metadados do IdP estão ativos nesta instância EK.
- Fornecer uma cópia para sua equipe de segurança ou conformidade para auditoria.
- Fazer um backup antes de realizar uma atualização.
Excluir Metadados de um Domínio
A exclusão é irreversível. Depois de excluir:
- O EK não possui mais metadados do IdP arquivados para aquele domínio.
- Quaisquer novas tentativas de login SSO de usuários
@<domínio>falharão. - Contas existentes — e-mail/senha, Google OAuth ou contas provisionadas por logins SSO anteriores — não são excluídas, mas esses usuários não poderão mais fazer login via SSO.
Lista de Verificação de Ponta a Ponta
Use isso como um roteiro ao habilitar o SAML SSO para um novo domínio de e-mail na sua instância EK on-premise.Compartilhar metadados SP do EK com seu administrador de IdP
Forneça ao seu administrador de IdP os metadados SP do seu backend EK — não do host do frontend.
- Se seu IdP puder acessar o backend diretamente, aponte-o para:
- Caso contrário, baixe o XML e passe-o por canal alternativo:
Seu administrador de IdP cria a aplicação SAML
Uma vez que ele tenha os metadados SP, seu administrador de IdP registra o EK como uma aplicação SAML no seu IdP. Confirme com ele que:
- O NameID está definido para o endereço de e-mail do usuário.
- As asserções são assinadas.
- A audiência / Entity ID corresponde ao valor nos metadados SP do EK.
Receber os metadados XML do IdP
Peça ao seu administrador de IdP os metadados XML do IdP assim que a aplicação for criada. Este é o arquivo que você carregará no próximo passo.
Carregar os metadados do IdP no EK
Faça login no EK como Super Admin, abra Super Admin Dashboard → SSO Metadata e clique em Add Metadata. Insira o domínio de e-mail e carregue o XML.
Testar o login
Teste com um usuário real
@<domínio>. Se o usuário autenticar com sucesso, mas tiver o acesso negado, verifique sua configuração de Controles de Acesso SAML — consulte o guia Controles de Acesso SAML.Documentar a alteração
Registre o seguinte no seu sistema interno de gestão de alterações: o domínio, o tipo do IdP, a data do upload e qual Super Admin realizou o upload.
Encontrando problemas? Consulte o guia Solução de Problemas e Referência SSO.