Alcance no Jitterbit App Builder

Alcance é uma finalidade de regra que implementa Segurança em Nível de Linha (RLS) no App Builder, restringindo quais linhas de dados estão disponíveis para cada usuário. Pode impedir que um representante de vendas veja contas fora de seu território atribuído, evitar que um funcionário veja dados fora de sua região ou divisão, ou impedir que um cliente em uma aplicação multi-tenant veja os registros de outro.

Muitos Sistemas de Gerenciamento de Banco de Dados Relacional (RDBMS) oferecem suporte nativo para segurança em nível de linha, mas Alcance não é construído como um wrapper em torno desse suporte. É implementado diretamente pelo mecanismo de negócios do App Builder, portanto funciona da mesma forma independentemente de qual banco de dados está por baixo.

Esta página define como o recurso funciona, incluindo etapas para criar e registrar uma regra de Alcance. Em seguida, há práticas recomendadas, alguns exemplos práticos e uma lista das limitações atuais do recurso.

Um passo a passo completo que constrói uma regra de Alcance com dados de demonstração e a registra em um objeto de negócio está disponível na seção Alcance de Introdução ao App Builder - Apêndice D: Segurança.

Definição

Para usar o recurso de Alcance, três etapas são necessárias: criar uma regra de Alcance, definir qual token ela retornará e registrar essa regra em um objeto de dados.

• Criar uma regra de Alcance: Uma regra de Alcance é uma regra de negócio criada com a finalidade de Alcance. Como outros tipos de regra, como Padrão ou Validação, as regras de Alcance são fundamentalmente consultas mvSQL por baixo. O trabalho de uma regra de Alcance é determinar quais segmentos de dados um usuário específico pode acessar, geralmente chamando as funções mvSQL who() ou session() para vincular esse acesso de volta a quem está atualmente conectado. Veja como Criar uma regra de Alcance abaixo.

• Definir o token da regra de Alcance: Toda regra de Alcance seleciona exatamente uma coluna para atuar como seu Token de Alcance. Isso é definido através do campo Tipo de Uso de Coluna dessa coluna. Cada linha retornada pela regra é um segmento de dados que o usuário atual pode alcançar. Se nenhuma linha for retornada, significa que o usuário não tem acesso algum. Veja como Definir o token da regra de Alcance abaixo.

  Os tokens geralmente identificam um grupo amplo (por exemplo, uma região geográfica), em vez de um único registro, porque verificar o acesso segmento por segmento é muito mais barato do que linha por linha. O token de um gerente de vendas pode ser o ID de sua região, permitindo que ele puxe relatórios para cada cliente naquele território em vez de apenas um. Aplicações multi-tenant são uma exceção comum: lá, o token pode apontar para a própria linha de cliente do usuário, já que o cliente em si é o segmento sendo restringido.

  O token não precisa estar na própria tabela de destino da regra de Alcance. Pode ser obtido de mais acima em uma cadeia de relacionamento, através de uma junção, desde que ainda identifique um segmento ao qual o objeto de dados restringido possa ser vinculado.

• Registrar uma regra de Alcance em um objeto de dados: Uma regra de Alcance não tem efeito até ser registrada em um objeto de dados. Um objeto de dados pode ter mais de um registro, caso em que um usuário só vê linhas que satisfazem todos eles simultaneamente. Veja Registrar uma regra de Alcance abaixo para obter instruções.

Criar uma regra de Alcance

Para construir uma nova regra de Alcance do zero:

1. Em App Workbench > Regras, clique em + Regra. O Construtor de Regras abre.

2. Seguindo as convenções de nomenclatura do App Builder, nomeie a regra usando o padrão NomeDaTabela (Alcance) Descritor.

3. No campo Purpose, role para baixo até Reach em Edge Case e selecione-o.

4. No campo Target, selecione a tabela que a regra deve consultar.

5. Clique em Create.

Definir o token da regra Reach

Após criar uma regra Reach, é necessário definir seu token. O token identifica os segmentos de dados que um usuário visualiza.

1. Acesse o Rule Builder da regra Reach.

2. Na aba Where, adicione uma cláusula que vincule o usuário atual aos dados que ele pode acessar, normalmente com a função who(). Se a tabela ainda não tiver uma coluna vinculando uma linha a um usuário do App Builder, adicione uma, junto com um controle para que possa ser definida pela interface.

3. Na aba Columns, adicione a coluna que identifica o segmento acessível, clique duas vezes nela e defina seu Column Usage Type como Reach Token.

4. Clique em Results no painel Rule para confirmar que a regra retorna os segmentos esperados.

Registrar uma regra Reach

Após a regra existir, anexe-a a qualquer objeto de dados que deseje restringir:

1. Navegue até o painel Rule do objeto de negócio que deseja restringir.

   Nota

   Uma regra Reach só pode ser registrada em um objeto de negócio construído na mesma tabela física ou visualização que ela tem como alvo, não diretamente em uma tabela. Consulte Best practices and recommendations abaixo para um padrão que aplica uma regra Reach a uma tabela inteira.

2. Clique em More > Edge Case. A caixa de diálogo Edge Case Settings é aberta.

3. Clique em Reach. A caixa de diálogo Reach Registration é aberta.

4. Clique em Create. A caixa de diálogo agora exibe um formulário com os seguintes campos:

   

   • Em Reach Information:

     • Rule: Selecione a regra Reach que você criou.

     • Binding Column: Selecione a coluna que corresponde ao Reach Token.

     • Role: (Opcional) Selecione a função à qual a restrição deve se aplicar ou deixe em branco para aplicar a restrição a todos enquanto você confirma que a regra funciona conforme esperado. Consulte Best practices and recommendations abaixo.

   • Em Position:

     • Index: (Opcional) Digite um número para definir a ordem desta regra em relação a outras regras Reach registradas no mesmo objeto.

     • Active: Deixe marcado para aplicar a regra ou desmarque para desativar a restrição sem excluir o registro.

     • Technical Help: (Opcional) Digite informações descritivas para auxiliar outros desenvolvedores.

5. Clique em Save.

Atualize a página para ver a restrição entrar em vigor.

Após um objeto de negócio ter pelo menos uma regra Reach registrada, um botão Reach também aparece diretamente em seu painel Rule, ao lado de Events e Roles, com um crachá mostrando quantas regras Reach estão registradas. Clique nele para visualizar, editar ou adicionar outros registros sem passar por More > Edge Case novamente.

Melhores práticas e recomendações

As seguintes melhores práticas podem ajudar a economizar tempo ao criar regras Reach:

• Ao registrar uma nova regra Reach, deixe o campo Role em branco até confirmar que funciona. Após verificação, vincule-a à função que se destina a restringir, para que funções administrativas, como Superuser, mantenham acesso total.

• Registre a regra em todos os objetos de negócio que expõem os dados que você está restringindo. Um registro afeta apenas o objeto específico ao qual está anexado, não todas as outras regras construídas na mesma tabela subjacente, portanto restringir Customer (Source) não tem efeito em um objeto Customer (List) separado construído na mesma tabela Customer a menos que você registre a regra lá também.

• Prefira um token que identifique um segmento de linhas, como uma região ou tipo de conta, em vez de um que identifique linhas individuais. Uma regra com escopo tão amplo tem muito menos linhas para verificar a cada evento Filter.

• Para ver quais regras em um app já têm Reach aplicado, acesse App Workbench > Rules e verifique a coluna Reach, ou clique na aba With Reach para filtrar a grade apenas para essas regras.

• Para ver quais páginas são restritas por Reach para uma determinada função, acesse App Workbench > Roles e selecione essa função. Seu diagrama de página marca cada página restrita com um ícone de mão .

• Como uma regra Reach não pode ser registrada diretamente em uma tabela, crie um objeto de negócio que selecione todas as colunas da tabela, seguindo o padrão de nomenclatura TableName (With Reach), e registre a regra Reach nele. Depois, sempre que outra regra faria referência à tabela subjacente, faça referência a TableName (With Reach): como Reach é herdado dos objetos que uma consulta referencia, isso aplica a restrição em todos os lugares onde esse objeto de negócio é usado, sem precisar registrá-lo repetidamente.

Exemplos

Acesso baseado em região

Imagine um app com o seguinte esquema de tabela:

Neste modelo, funcionários e clientes pertencem a uma região, e cada funcionário está vinculado a um usuário do App Builder.

A seguinte regra restringe os usuários para que vejam apenas clientes em sua própria região:

SELECT RegionId
FROM Employee
WHERE UserId = who('userid')

Como essa regra tem como alvo a tabela Customer, ela pode ser registrada no objeto de dados Customer (Source), e a partir daí se aplica a cada painel construído nesse objeto de dados.

No entanto, as regras Reach geralmente não devem se aplicar a todos. Em vez disso, use-as em conjunto com segurança baseada em funções. Por exemplo, suponha que a fonte de dados defina uma função Administrator que pode ver todos os clientes e uma função Sales que deve ver apenas clientes em sua própria região. Registrar a regra contra a função Sales mantém os administradores sem afetar, enquanto os usuários de Sales veem apenas os clientes de sua própria região.

Combinando múltiplos atributos com uma tabela de ponte

Um Reach Token não precisa vir de um único relacionamento direto. Quando o acesso depende de uma combinação de atributos, por exemplo, um funcionário que só pode ver clientes em regiões específicas e níveis de cliente específicos, uma tabela de ponte pode resolver essa combinação para os registros individuais que um usuário pode ver.

Adicione uma tabela de ponte, como EmployeeAccess, com uma coluna EmployeeID, RegionID e CustomerTierID, armazenando uma linha para cada combinação de região e nível que um funcionário tem permissão para acessar. A seguinte regra se une através dessa tabela para retornar cada CustomerID que o usuário atual pode ver:

SELECT c.CustomerID
FROM EmployeeAccess ea
JOIN Employee e ON e.EmployeeID = ea.EmployeeID
JOIN Customer c ON c.RegionID = ea.RegionID AND c.CustomerTierID = ea.CustomerTierID
WHERE e.UserID = who('userid')

Aqui, CustomerID é o Reach Token: em vez de identificar um segmento amplo, a regra resolve a interseção de cada região e nível ao qual o usuário tem acesso para os registros de cliente específicos que correspondem. Este padrão lida com relacionamentos muitos-para-muitos, como funcionários atribuídos a mais de uma região ou nível, e exceções por usuário que um token de coluna única mais simples não consegue expressar.

Implementação

Cada regra do App Builder se conecta a um conjunto compartilhado de eventos intrínsecos, e Reach especificamente se vincula ao evento Filter, o responsável por recuperar linhas. Por isso, Reach só entra em vigor onde um evento Filter realmente é executado:

• Painéis: painéis Grid e Form, painéis Chart e Calendar e similares.
• Controles: controles List e Radio.
• CRUD: apenas regras CRUD de negócio, não regras CRUD diretas de banco de dados, pois estas ignoram completamente o mecanismo de negócio.

Limitações

As seguintes restrições se aplicam ao implementar Reach:

• Reach funciona apenas com fontes de dados RDBMS.
• Reach não suporta operações entre plataformas: a regra e o objeto de dados ao qual está registrada devem pertencer à mesma fonte de dados.
• Reach não tem efeito em operações CRUD diretas de banco de dados, pois estas contornam o mecanismo de negócio que a implementa.
• Uma regra Reach pode ter apenas uma coluna Reach Token, portanto um objeto de dados se vincula a ela através de uma única coluna, diferentemente de outros tipos de regra que permitem vinculação em múltiplas colunas.
• Reach não é atualmente suportado junto com o App Builder Connector.
• Copiar um objeto de dados não transfere seus registros Reach, o mesmo que ocorre com regras Default, Validation e Action.