Privilégios e permissões no Jitterbit App Builder
Visão geral
O modelo de autorização do App Builder se baseia em dois conceitos relacionados, mas distintos. Um privilégio determina se um grupo consegue acessar uma aplicação ou fonte de dados, enquanto uma permissão determina o que os membros desse grupo podem realmente fazer com os dados uma vez dentro. O acesso de cada usuário é na verdade apenas a soma dos privilégios e permissões concedidos aos grupos aos quais pertencem.
Esta página explica ambas as partes desse modelo em sequência:
- Privilégios: Aprenda como administradores concedem a um grupo acesso a uma aplicação ou fonte de dados, e como esse acesso se relaciona entre os dois.
- Permissões: Saiba o que cada permissão permite um usuário fazer e como isso, por sua vez, define quais páginas, links de menu e controles de página um usuário consegue visualizar.
Privilégios
Um privilégio é uma concessão sim-ou-não que controla se um grupo tem acesso a uma determinada aplicação ou fonte de dados. Administradores concedem privilégios diretamente a grupos, nunca a usuários individuais, portanto cada membro de um grupo compartilha os privilégios que o grupo possui. Esta seção aborda como os privilégios funcionam para grupos em geral e a relação específica entre o privilégio de uma aplicação e os privilégios das fontes de dados que ela usa.
Grupos e privilégios
Grupos organizam usuários para que administradores possam gerenciar seu acesso coletivamente, em vez de um usuário por vez. Para dar a um grupo acesso a parte do App Builder, um administrador de segurança concede a ele privilégio para uma aplicação ou fonte de dados específica, usando as etapas em Conceder a um grupo acesso a uma aplicação ou fonte de dados.
Conceder a um grupo privilégio para uma aplicação normalmente estende esse privilégio às fontes de dados que a aplicação usa. Essa extensão flui apenas em uma direção. Veja Autorização de aplicação para as exceções a essa regra.
Autorização de aplicação
Uma aplicação normalmente usa uma ou mais fontes de dados para armazenar e recuperar seus registros. Quando um administrador de segurança concede a um grupo privilégio para uma aplicação, o App Builder estende automaticamente esse privilégio para cada fonte de dados que a aplicação referencia, portanto o grupo não precisa de uma segunda concessão separada para usar a aplicação normalmente.
Nota
Alguns recursos são uma exceção a essa extensão, exigindo que um grupo tenha privilégio explícito para uma fonte de dados mesmo tendo privilégio para uma aplicação que a usa. Por exemplo, IA Conversacional requer privilégio explícito para a fonte de dados de um agente registrado antes que os membros de um grupo possam conversar com esse agente.
O inverso não é verdadeiro: conceder a um grupo privilégio para uma fonte de dados não concede a ele privilégio para nenhuma aplicação que aconteça usar essa fonte de dados. Privilégio para uma fonte de dados apenas permite que um grupo trabalhe com essa fonte de dados diretamente, por exemplo através de um relatório ou uma integração, não através de qualquer aplicação em particular.
Por exemplo, suponha que uma fonte de dados customer seja usada por duas aplicações diferentes, Customer Reports e Customer Lookup. Um grupo com privilégio concedido para Customer Reports consegue usar a fonte de dados customer através dessa aplicação, mas o mesmo grupo não consegue abrir Customer Lookup a menos que tenha privilégio concedido para essa aplicação separadamente, mesmo que ambas as aplicações dependam dos mesmos dados.
Nota
Ter privilégio para uma fonte de dados é necessário para usá-la, mas nem sempre é suficiente. Se a fonte de dados define papéis, o grupo também precisa ser membro de um ou mais desses papéis.
Permissões
Após um grupo obter privilégio em uma fonte de dados, as permissões determinam exatamente o que seus membros podem fazer com os objetos de dados nela, como consultar, inserir, atualizar ou excluir registros. Nem toda fonte de dados concede permissões com a mesma granularidade; consulte Funções para saber como o App Builder decide entre conceder a um grupo permissão total em uma fonte de dados de uma vez ou conceder permissões de forma mais precisa por meio de funções. O App Builder também usa permissões para decidir quais páginas, links de menu e controles de página um usuário pode realmente ver, abordado em Autorização de página abaixo.
Permissões são a unidade mais específica de controle de acesso no App Builder. Cada uma concede um único tipo de ação em um objeto de dados:
| Permissão | Descrição |
|---|---|
| Leitura | Permite que os usuários consultem o objeto de dados. |
| Inserção | Permite que os usuários insiram registros no objeto de dados. |
| Atualização | Permite que os usuários atualizem registros no objeto de dados e executem eventos definidos pelo usuário. |
| Exclusão | Permite que os usuários excluam registros do objeto de dados. |
Consulte Funções para saber como essas permissões individuais se combinam na concessão geral de uma função.
Autorização de página
Os usuários são autorizados a ver e interagir com páginas específicas com base em seu acesso aos objetos de dados. Isso ocorre porque o App Builder não protege as páginas diretamente; em vez disso, ele protege os objetos de dados nos quais uma página é construída e deriva o acesso do usuário à própria página a partir de suas permissões nesses objetos. Existem tipos de painéis (como Grade, Formulário e Gráfico) e controles (como Lista) vinculados a objetos de dados, sendo assim sujeitos a essa verificação de permissão subjacente.
Um usuário tem permissão para uma página se e somente se tiver acesso de Leitura a cada objeto de dados que a página usa. Essa regra se aplica até mesmo a uma página construída diretamente em uma fonte de dados, como uma página de upload de arquivo construída em um sistema de arquivos local: o grupo do usuário precisa de privilégio explícito nessa fonte de dados, separado de qualquer privilégio que tenha por meio de uma aplicação, antes que a página se torne acessível.
Se um usuário solicitar uma página para a qual não tem permissão, receberá um erro "Acesso Negado". Na prática, isso é incomum, pois o App Builder oculta ou desabilita links e entradas de menu para páginas que um usuário não pode acessar; ocorre principalmente se a segurança está configurada incorretamente ou se um usuário navega diretamente para a URL de uma página, por exemplo, clicando em um link desatualizado em um email.
O App Builder ajusta links de menu, links de página e controles de página com base nas permissões de um usuário.
Links de menu
Ao construir links de menu, o App Builder verifica se o usuário tem acesso de Leitura à página de destino de cada link. Se tiver, o link aparece no menu; caso contrário, o App Builder o oculta, para que os usuários nunca vejam entradas de menu para páginas que não conseguem abrir.
Links de página
Da mesma forma, ao renderizar uma página, o App Builder verifica se o usuário tem acesso de Leitura à página de destino de cada link de página incorporado. Se tiver, a página é renderizada conforme projetada. Caso contrário, o App Builder ajusta a página da seguinte forma:
- Oculta o ícone de link do painel Grade (chevron ou pop-up) e desabilita sua ação de duplo clique.
- Oculta colunas do painel Grade definidas por controles que não são vinculados a dados (como Botões).
- Renderiza controles vinculados a dados em painéis Grade ou Formulário (como controles Texto ou Lista) como não clicáveis.
Controles de página
Além de simplesmente ocultar um link, o App Builder também oculta ou desabilita os controles específicos que uma página oferece, com base em quais permissões o grupo do usuário tem para o objeto de dados subjacente:
| Direito de Acesso | Afeta |
|---|---|
| Insert | Oculta o botão Adicionar do painel Grid. |
| Update |
|
| Delete |
|