Autorização de usuários#

Na ficha do usuário, escolha o método de login: Local, LDAP ou OpenID. Para LDAP e OpenID, primeiro configure a conexão com o provedor no servidor Orchestrator.

As capturas mostram a interface russa. Os nomes dos elementos neste texto correspondem à interface em inglês. Apenas o método de login é mostrado; os demais parâmetros do Usuário estão descritos no artigo da tela Usuários.

Abaixo estão os nomes das variáveis .env para configuração via Docker. Na instalação local, os parâmetros são definidos em backend/config/config.ini sob os respectivos nomes de configuração; após alterar as configurações, reinicie o aplicativo.

Para aplicar alterações do .env no Docker, recrie o contêiner da aplicação no diretório de instalação. O comando abaixo interrompe temporariamente a aplicação, mas não recria o banco de dados:

docker compose up -d --no-deps --force-recreate orchestrator

Autorização local#

Para entrar com login e senha, selecione "Local".

Exemplo: o campo "Login" contém docs.user e "Password" contém ExamplePassword9!. A senha é exibida como pontos. A opção "Local" está selecionada.

Autenticação LDAP#

Para entrar com uma conta do diretório, selecione "Use LDAP authentication" e escolha o Usuário em "LDAP users". A captura mostra o método selecionado; nenhuma conta do diretório foi escolhida ainda.

Ao instalar via Docker, defina os parâmetros LDAP no .env do servidor Orchestrator: LDAP_SERVER, LDAP_PORT, LDAP_BASE_DN, LDAP_GROUP, LDAP_UID_KEY e credenciais para pesquisa de usuários, se necessário para seu diretório. LDAP_GROUP indica a unidade organizacional dentro de LDAP_BASE_DN; LDAP_FILTER limita os resultados da pesquisa e é aplicado durante o login. O valor de LDAP_UID_KEY deve ser o nome do atributo LDAP, por exemplo, uid.

Para uma conexão segura, escolha LDAP_ENCRYPTION=tls para StartTLS (geralmente porta 389) ou LDAP_ENCRYPTION=ssl para LDAPS (geralmente porta 636). O certificado do servidor LDAP deve ser confiável. Se necessário, defina LDAP_TLS_CACERT, LDAP_NETWORK_TIMEOUT e LDAP_OPERATION_TIMEOUT. Após alterar o .env, aplique os ajustes com o comando de recriação do contêiner no início do artigo.

Autenticação OpenID#

Para entrar por um provedor OpenID, selecione "Use OpenID authentication" e informe em "oAuth id" o valor que identifica o Usuário no provedor.

Exemplo: o valor sub do provedor é docs.user. "Use OpenID authentication" está selecionado e "oAuth id" contém docs.user.

Ao instalar via Docker, configure no .env os parâmetros O_AUTH_CLIENT_ID, O_AUTH_CLIENT_SECRET, O_AUTH_AUTH_URI, O_AUTH_TOKEN_URI e O_AUTH_USER_INFO_URI. Se necessário, defina O_AUTH_SCOPE.

Registre um callback HTTPS fixo no provedor: https://<domínio-orquestrador>/api/v1/system/oauth_hook. Defina isso em O_AUTH_REDIRECT_URI ou deixe essa variável vazia: assim, o endereço será formado a partir de NGINX_DOMAIN_NAME. O domínio e o endereço registrados no provedor devem coincidir.

Por padrão, para vincular o usuário ao provedor, é utilizado o campo imutável sub (O_AUTH_USER_LINK_FIELD=sub). Se já houver um esquema de vinculação diferente ou se o provedor estiver mudando, primeiro coordene a transferência dos logins OpenID existentes: uma simples mudança de variável pode privar os usuários de acesso. A instalação suporta um único provedor configurado.

Diagnóstico de falhas de login com OpenID#

Se o login falhar após o retorno do provedor, um administrador deve abrir "System errors".

A visualização exige "Read" de "Robot Messages" na aba "Access" da Função. A captura mostra essa permissão; as demais permissões são configuradas separadamente.

Localize um registro com canal oauth e nível WARNING. O horário deve corresponder à tentativa de login.

A mensagem OAuth callback failed significa que o login foi interrompido no retorno do provedor. O valor stage indica a etapa que falhou:

• callback — verificação da solicitação e dos ajustes;
• token — obtenção do token do provedor;
• userinfo — obtenção dos dados do Usuário;
• identity — validação do valor que identifica o Usuário;
• session — armazenamento dos dados verificados para concluir o login.

O código da causa aparece em reason. Uma falha de comunicação com o provedor também pode incluir os valores disponíveis http_status, curl_errno ou provider_error.

Exemplo de erro de configuração após o início do login:

OAuth callback failed: stage=callback, reason=not_configured

Para restabelecer o login, é necessário realizar estas etapas:

1. Verificar se o identificador do cliente, os endereços HTTPS de token e de informações do usuário, o campo de vínculo e o callback estão configurados corretamente. Verifique O_AUTH_CLIENT_ID, O_AUTH_TOKEN_URI, O_AUTH_USER_INFO_URI, O_AUTH_USER_LINK_FIELD e O_AUTH_REDIRECT_URI.
2. Se as configurações mudaram durante o login, restaurar uma configuração consistente e aplicá-la pelo procedimento no início do artigo.
3. Iniciar o login novamente pela página de autenticação. Não reabrir o callback anterior: seu estado já foi utilizado.

A causa pending_missing significa que não há uma tentativa de login pendente na sessão atual. Para state_invalid ou pending_expired, também é necessário iniciar o login novamente. Se o erro persistir, o administrador deve verificar a persistência da sessão do navegador e as configurações do provedor.

A mensagem OAuth login failed refere-se à conclusão do login após o callback e contém apenas a etapa. O valor verified_identity indica dados verificados ausentes ou expirados, user_match indica uma falha na correspondência do usuário e session indica uma falha na criação da sessão.

As mensagens de diagnóstico não incluem tokens, código de autorização, segredo do cliente, identificador de sessão nem o valor do campo de vínculo do usuário. Ao entrar em contato com o suporte, basta fornecer o horário do erro e o registro de diagnóstico sem acrescentar esses dados. Um callback bem-sucedido não gera um registro de erro. Para um erro inesperado, pode aparecer apenas o nome da classe da exceção em vez da etapa e da causa.