Ir para o conteúdo

Métodos de autenticação de usuário no Jitterbit App Builder

Visão geral

A autenticação de usuário é o processo de verificação da identidade de alguém que tenta acessar um aplicativo. Ela determina quem pode fazer login, sob quais condições e com qual nível de confiança. Escolher o método de autenticação certo para seu aplicativo determina os detalhes de como o processo de login ocorre, quais capacidades vêm integradas e quanto desenvolvimento personalizado sua equipe é responsável.

O App Builder suporta esses seis métodos de autenticação de usuário:

Além dos métodos de autenticação em si, esta página também apresenta os conceitos relacionados de provisionamento de usuários, que diz respeito a como criar contas de usuário programaticamente, e grupos de segurança de provedores, que envolve mapear grupos definidos por um provedor de identidade externo para grupos de segurança do App Builder.

Métodos de autenticação de usuário

Single sign-on

O Single sign-on (SSO) permite que os usuários se autentiquem no App Builder usando credenciais que já gerenciam em um provedor de identidade de terceiros, como Microsoft Entra ID ou Okta. Em vez de manter uma senha separada do App Builder, os usuários se autenticam através do provedor de identidade, que então confirma sua identidade para o App Builder. O SSO também suporta o provisionamento de usuários e grupos: funções ou reivindicações de grupo do provedor de identidade podem ser mapeadas para grupos de segurança do App Builder, de modo que as permissões sejam aplicadas automaticamente no login.

O App Builder suporta SSO através dos seguintes protocolos, cada um com um guia de configuração dedicado:

Provedores de identidade compatíveis incluem Microsoft Entra ID, Okta, Salesforce, Symantec SiteMinder (anteriormente CA SiteMinder) e outros provedores compatíveis com OAuth2.

Autenticação de usuário local

A autenticação local é o método de autenticação integrado do App Builder. Os usuários fazem login com um nome de usuário e senha que são armazenados e gerenciados diretamente dentro do App Builder. Este método de autenticação não envolve nenhum provedor de identidade externo ou serviços de diretório.

Quando você usa a autenticação local, o App Builder gerencia todas as etapas do processo de autenticação: criação de contas de usuário, armazenamento seguro de senhas, aplicação de políticas de senha e fornecimento de opções de recuperação de senha. É uma escolha adequada para cenários onde um provedor de identidade centralizado não está disponível ou não é necessário.

Para um guia detalhado sobre como gerenciar usuários e grupos com autenticação local, veja Gerenciamento de usuários e grupos: autenticação local.

Autenticação integrada do Windows

A autenticação integrada do Windows (WIA) permite que usuários em um domínio do Windows façam login no App Builder sem inserir credenciais explicitamente. Quando um usuário já está logado em seu domínio do Windows, o navegador passa automaticamente suas credenciais de sessão para o servidor web. O servidor web valida essas credenciais contra o domínio e mapeia a identidade do Windows para uma conta de usuário do App Builder.

Como a autenticação depende da sessão ativa do Windows do usuário, não há um formulário de login. Este método é adequado para ambientes de intranet onde todos os usuários estão em máquinas unidas ao domínio.

Para instruções de configuração, veja Configurar autenticação integrada do Windows.

Active Directory

A autenticação do Active Directory permite que os usuários façam login no App Builder usando suas credenciais de domínio existentes (nome de usuário e senha). Ao contrário da autenticação integrada do Windows, que depende da sessão ativa do Windows do usuário, este método utiliza um formulário de login padrão onde os usuários inserem suas credenciais explicitamente. O servidor web valida essas credenciais contra o domínio do Active Directory e mapeia a identidade para uma conta de usuário do App Builder.

Esse método funciona em ambientes onde os usuários não estão em máquinas unidas ao domínio ou onde um formulário de login explícito é necessário.

Para detalhes de configuração, veja Provedor de segurança - Active Directory.

Autenticação de aplicativo (personalizada)

A autenticação de aplicativo é um método de autenticação personalizado no qual o desenvolvedor constrói e controla todo o processo de login. Em vez de redirecionar os usuários para um provedor de identidade de terceiros, o App Builder os redireciona para uma página dentro do próprio aplicativo.

Ao contrário da autenticação local e do SSO, a autenticação de aplicativo não fornece capacidades integradas. O desenvolvedor é responsável por todos os aspectos do fluxo, incluindo:

  • Capturar e validar as credenciais do usuário.

  • Implementar autenticação multifator (MFA), se necessário.

  • Criar e provisionar contas de usuário.

  • Atribuir usuários a grupos e configurar as permissões associadas.

  • Construir fluxos de redefinição de senha e recuperação de conta.

  • Impor políticas de senha.

Essa abordagem é adequada quando as credenciais precisam ser validadas contra uma fonte de dados externa, quando o acesso semi-anônimo é necessário ou quando a lógica de autenticação não pode ser tratada por um provedor padrão. Essa abordagem requer significativamente mais trabalho de desenvolvimento do que os outros métodos de autenticação.

Para um guia detalhado sobre como configurar a autenticação de aplicativos, consulte Provedor de segurança - autenticação de aplicativos.

Acesso anônimo

O acesso anônimo permite que os usuários acessem um aplicativo sem autenticação. No App Builder, qualquer solicitação que não esteja associada a um usuário autenticado é automaticamente tratada sob a conta de usuário "anônimo". Os desenvolvedores podem atribuir permissões específicas a essa conta para controlar quais conteúdos são acessíveis publicamente.

A autenticação anônima é habilitada por padrão. É útil para cenários como páginas voltadas para o público, páginas de destino ou telas de login personalizadas que devem ser acessíveis antes que um usuário faça login.

Para configurar quais partes do seu aplicativo os usuários anônimos podem acessar, consulte Acesso anônimo. Para configurar uma fonte de dados para permitir conexões não autenticadas, consulte Autenticação HTTP anônima.

Gerenciamento de identidade

Provisionamento de usuários

O provisionamento de usuários é um mecanismo para criar contas de usuário do App Builder programaticamente, sem exigir a criação manual através do IDE. Não é um método de autenticação, mas é comumente usado juntamente com fluxos de autenticação para criar contas sob demanda.

Como o App Builder não permite que regras CRUD escrevam diretamente em suas tabelas de usuários e grupos, ele expõe um objeto de dados público chamado User_Create para esse propósito. Os desenvolvedores podem construir regras CRUD XP que inserem registros em User_Create para criar novas contas de usuário.

Cada inserção em User_Create requer um ProviderId, que identifica a configuração do provedor de segurança a ser usada para a nova conta. Isso permite que os administradores de segurança definam as políticas de autorização aplicadas a novas contas independentemente de como o desenvolvedor implementa a lógica de criação de contas.

Para mais detalhes, consulte Provisionamento de usuários e grupos.

Grupos de segurança do provedor

Muitos provedores de autenticação externos definem seus próprios grupos de segurança, às vezes chamados de funções ou escopos. O App Builder permite que os administradores de segurança mapeiem esses grupos definidos pelo provedor para grupos de segurança do App Builder, de modo que as permissões de um usuário dentro do App Builder reflitam sua associação a grupos no provedor externo.

Cada mapeamento de grupo de segurança do provedor possui as seguintes propriedades:

  • Provedor: O provedor de segurança (usuário ou fonte de dados) ao qual o grupo pertence.

  • Identificador: O nome exclusivo atribuído ao grupo pelo provedor de segurança.

  • Grupo: O grupo de segurança do App Builder ao qual o grupo do provedor está mapeado.