Ir para o conteúdo

Provedores e identidades no Jitterbit App Builder

Visão geral

Toda aplicação do App Builder, fonte de dados e serviço web precisa de uma forma de confirmar quem ou o quê está fazendo uma solicitação, e controlar o que esse solicitante pode fazer. O App Builder trata ambas as situações através de provedores de segurança, que são módulos configuráveis independentemente que você ativa e configura para corresponder ao seu ambiente, em vez de um único sistema de login integrado. Por exemplo, um provedor de segurança pode verificar um nome de usuário e senha na própria tabela de usuários do App Builder, outro pode validar uma chave de API enviada por um sistema externo, e um terceiro pode delegar a decisão inteiramente a um serviço de identidade terceirizado, como Salesforce ou um provedor de SSO.

Alguns provedores de segurança também suportam identidades: registros que vinculam uma conta de usuário ou grupo definido por um sistema externo, como um provedor de identidade terceirizado ou uma fonte de dados externa, ao seu usuário ou grupo de segurança correspondente do App Builder. Uma identidade permite que o App Builder reconheça um usuário que entra por meio de um provedor externo como um usuário específico do App Builder já existente, em vez de tratar cada entrada externa como desconhecida.

Esta página aborda:

Provedores

Nem todo provedor de segurança faz o mesmo trabalho. Dependendo do seu tipo, um provedor de segurança pode desempenhar um ou mais dos seguintes papéis:

  • Autenticação de usuário: Confirma a identidade de uma pessoa entrando em uma aplicação do App Builder.
  • Autenticação de fonte de dados: Confirma a identidade que o próprio App Builder apresenta quando se conecta a uma fonte de dados externa, como um banco de dados ou uma API terceirizada.
  • Segurança no nível de conexão: Protege a conexão subjacente entre o App Builder e uma fonte de dados, independentemente da identidade usada para autenticar.
  • Políticas de autorização: Governa o que um usuário ou conexão já autenticado tem permissão para fazer, distinto de confirmar quem são.

Cada provedor de segurança que você configura define seu próprio conjunto de parâmetros, que o administrador do site define para corresponder ao seu ambiente. O App Builder é fornecido com uma configuração padrão que já ativa um conjunto inicial de provedores de segurança, então a autenticação geralmente funciona pronta para uso; os administradores podem ajustar, desativar ou adicionar a esses conforme necessário. Você também pode importar e exportar configurações de provedor de segurança.

Tipos de provedor padrão

O App Builder é fornecido com os seguintes tipos de provedor padrão, cada um cobrindo um esquema específico de autenticação ou autorização. Selecione o nome de um provedor para seu guia de configuração.

Tipo de provedor Descrição
Active Directory (AD) Provedor de autenticação baseado em formulários.
Chave de API Provedor de autenticação da API REST.
Servidor de autorização Permite que o App Builder funcione como um servidor de autorização OAuth 2.0 e OpenID Connect (OIDC).
HTTP Autentica solicitações de cliente HTTP para APIs REST.
Autenticação integrada do Windows (IWA) Esquema de SSO para domínios do Active Directory.
Jitterbit Harmony Autentica solicitações HTTP para pontos de extremidade do Jitterbit API Manager.
JWT SSO Protocolo de logon único (SSO) personalizado.
Usuário local Provedor de autenticação baseado em formulários.
OAuth Provedor de autorização OAuth.
OData Esquemas de autenticação de fonte de dados OData.
OpenID Connect Ativa suporte para OpenID Connect 1.0.
Reescrever URL Restaura uma URL reescrita por um proxy reverso.
Salesforce Autenticação e autorização do Salesforce usando OAuth2.
SAML SAML Single Sign-On (SSO).
Provedor de identidade SAML Autenticação SAML Single Sign-On (SSO).
Serviços OData do SAP Esquemas de autenticação do SAP NetWeaver Gateway OData Service.
SuccessFactors OData Esquemas de autenticação do serviço web SuccessFactors OData.
Senha do Successfactors Provedor de autenticação de usuário baseado em formulários.
Provisionamento de usuário Registro programático de usuário.
Gerenciamento de acesso web (WAM) Esquema de SSO para sistemas herdados de gerenciamento de acesso web.
WS-Federation WS-Federation SSO.

Associações de serviço web

Um serviço web, neste contexto, é um endpoint que sistemas externos chamam programaticamente, em oposição a uma página que uma pessoa navega. Desde o App Builder 4.67, três tipos de serviço web devem ser explicitamente associados a provedores específicos e individualmente configurados permitidos para autenticar suas solicitações. Anteriormente, qualquer provedor habilitado de um tipo elegível poderia autenticar solicitações para qualquer serviço web, independentemente do tipo.

Serviço web Caminho Tipos de provedor elegíveis Configurar autenticação
REST API /rest/v1 Chave de API, HTTP, Servidor de Autorização Publicar um aplicativo Jitterbit App Builder como endpoint da REST API
Webhook /webhook/v1 Chave de API, HTTP, Servidor de Autorização Webhooks no Jitterbit App Builder
Conector do App Builder /connect/v1 Chave de API, HTTP, Servidor de Autorização Conector do App Builder no Jitterbit App Builder

Cada instância de serviço web (cada endpoint REST individual, endpoint Webhook ou aplicação Remote Connector) é associada a provedores específicos e individualmente configurados desses tipos, não apenas ao tipo em geral; as páginas vinculadas descrevem como fazer essa associação. Ao fazer upgrade de uma versão anterior do App Builder, uma migração associa automaticamente cada provedor existente de um tipo elegível a cada serviço web existente do tipo correspondente, para que as integrações existentes continuem a autenticar sem reconfiguração manual. Um serviço web criado após fazer upgrade para o App Builder 4.67 não é automaticamente associado a nenhum provedor e não autenticará nenhuma solicitação até que você associe explicitamente um.

As etapas de Configurar autenticação vinculadas acima são realizadas de dentro do próprio aplicativo, o que funciona apenas para um aplicativo que você ainda pode editar. Para um aplicativo lacrado, que não pode ser alterado de dentro do app, veja Serviços web de aplicação lacrada abaixo.

Serviços web de aplicação lacrada

Lacrar um aplicativo, como acontece quando é enviado para um ambiente de QA ou produção, bloqueia todas as alterações nele de dentro do app, incluindo as associações de serviço web por endpoint acima.

Para um aplicativo lacrado que expõe um serviço web, associe seus provedores de segurança de fora do app, usando Gerenciar Aplicativos. Vá para IDE > Provedores de Segurança, depois, em Autenticação de Usuário, selecione Mais > Gerenciar Aplicativos e clique no ícone na coluna Serviço Web do aplicativo. Isso abre o mesmo diálogo Provedores de Autenticação descrito acima.

A partir do App Builder 4.68, este ícone também aparece para o aplicativo Vinyl - Release Management, o aplicativo do sistema integrado que expõe a REST API que a implantação em um clique usa no sistema de destino (QA ou produção).

Autenticação padrão

Cada aplicativo, seja criado pelo usuário ou um aplicativo de sistema integrado, tem um provedor de Autenticação Padrão: o provedor usado, quando combinado com a opção Redirecionar ao Desafio desse provedor, para redirecionar um usuário não autenticado a um provedor de login quando tenta acessar uma página protegida. Vá para IDE > Provedores de Segurança, depois, em Autenticação de Usuário, selecione Mais > Gerenciar Aplicativos, clique no ícone Editar do aplicativo, selecione um provedor no campo Autenticação Padrão e clique em Prosseguir.

Gerenciamento de identidades

Quando um provedor de segurança delega autenticação a um sistema externo, seja um provedor de identidade de terceiros como Salesforce ou SAML SSO, ou uma fonte de dados externa, o App Builder precisa de uma maneira de traduzir o que esse sistema externo relata sobre o usuário em seus próprios termos: uma conta de usuário específica do App Builder e, opcionalmente, os grupos de segurança do App Builder dos quais as permissões do usuário devem vir. Esta seção aborda os dois mecanismos que o App Builder usa para fazer essa tradução:

  • Identidades, que mapeiam uma conta de usuário externa para um usuário do App Builder.
  • Grupos de provedor, que mapeiam um grupo, função ou escopo externo para um grupo de segurança do App Builder, de modo que as permissões de um usuário possam ser derivadas de sua associação a grupos externos, em vez de serem atribuídas individualmente a cada usuário.

Identidades

Uma identidade vincula uma conta de usuário externa, conforme relatado por um provedor de segurança específico, a um usuário do App Builder. Sempre que esse provedor autentica uma solicitação em nome de uma conta externa, o App Builder precisa de uma identidade correspondente para saber qual dos seus próprios usuários a conta representa. Sem uma, o App Builder não tem como saber qual usuário do App Builder a conta externa representa. Um usuário pode ter apenas uma identidade por provedor de segurança, mas pode ter identidades separadas para diferentes provedores, por exemplo, se a mesma pessoa conseguir fazer login tanto pelo Salesforce quanto pelo SAML SSO.

As identidades possuem as seguintes propriedades:

  • Provedor: O provedor de segurança (usuário ou fonte de dados) proprietário da identidade.
  • Nome: O nome de usuário único atribuído pelo provedor de segurança. Durante a autenticação, um provedor de identidade externo normalmente retorna um conjunto de declarações, pedaços de informações sobre o usuário, como seu nome ou uma ID única, transmitidas no token de autenticação ou na asserção; essa propriedade corresponde à declaração Name.
  • Identificador: Um identificador único e imutável atribuído pelo provedor de segurança, correspondendo à declaração NameIdentifier. Ao contrário de Name, esse parâmetro é opcional, mas recomendado quando o provedor o suporta, pois não muda mesmo que o nome ou nome de usuário do usuário mude posteriormente.

As identidades são necessárias ao delegar a autenticação do usuário a provedores de segurança externos, como Salesforce ou SAML Single Sign-On (SSO). Para concluir o login, o App Builder pega as declarações fornecidas pelo provedor e procura por uma identidade correspondente, verificando primeiro a declaração NameIdentifier e recorrendo à declaração Name se nenhuma correspondência for encontrada.

As identidades também entram em jogo para a autenticação da fonte de dados. A maioria das conexões de fonte de dados autentica como uma única conta de serviço compartilhada, o que significa que cada usuário do App Builder acessa a fonte de dados com a mesma credencial. Algumas fontes de dados, porém, suportam autenticação restrita ao usuário, onde a conexão autentica como o usuário específico do App Builder conectado. Para essas, o provedor de segurança usa o Name da identidade, se um for definido para o usuário, recorrendo ao nome de usuário do App Builder se não estiver; o Identifier da identidade não é usado para esse fim.

Grupos de provedor

Além de identidades individuais, um provedor externo também pode definir seus próprios grupos de segurança, às vezes chamados de funções ou escopos, que agrupam vários usuários juntos, por exemplo, uma função "Gerentes de Vendas" do Salesforce ou um grupo "Finanças" de um IdP SAML. Em vez de atribuir permissões a cada usuário individualmente através de sua identidade, um administrador de segurança pode mapear cada um desses grupos externos para um único grupo de segurança do App Builder, de modo que cada usuário pertencente ao grupo externo herde automaticamente as permissões concedidas ao grupo de segurança do App Builder correspondente.

Os grupos do provedor de segurança possuem as seguintes propriedades:

  • Provedor: O provedor de segurança (usuário ou fonte de dados) ao qual o grupo pertence.
  • Identificador: O nome único atribuído ao grupo pelo provedor de segurança.
  • Grupo: O grupo de segurança do App Builder para o qual o grupo do provedor de segurança é mapeado.

Registro

Antes de um grupo do provedor de segurança poder ser mapeado, ele deve primeiro existir no App Builder como um registro. Os grupos do provedor de segurança podem ser registrados de duas maneiras:

  • Manual: Os administradores fazem login no App Builder e adicionam grupos do provedor de segurança diretamente. Isso geralmente é necessário para provedores de segurança de fonte de dados, que não têm como relatar seus grupos ao App Builder por conta própria.
  • Automático: O App Builder registra novos grupos do provedor de segurança dinamicamente, durante o processo de autenticação do usuário, atualizando a associação do usuário a grupos ao mesmo tempo. Os provedores de segurança SAML e WS-Federation suportam isso, mas apenas uma vez que explicitamente ativado usando a flag Supplies Group Membership do provedor.

Mapeamento

Independentemente de como um grupo de provedor de segurança é registrado, ele pode ser mapeado para um grupo de segurança do App Builder. Cada grupo de provedor de segurança pode ser mapeado para um, e apenas um, grupo de segurança do App Builder; porém, múltiplos grupos de provedor de segurança podem ser mapeados para o mesmo grupo de segurança do App Builder.

Associação

Um grupo de provedor de segurança estende a associação de grupo de segurança do App Builder de um usuário em vez de substituí-la. Ao calcular os direitos de acesso de um usuário, o App Builder leva em conta tanto os grupos de segurança aos quais o usuário pertence diretamente quanto os grupos de segurança aos quais o usuário pertence por meio de um grupo de provedor de segurança mapeado.