sábado, 21 de novembro de 2015

Permissions

Presenciamos recentemente o Trick or Treat aqui no Brasil, nada mais natural para nós que vivemos em um pais de língua predominantemente inglesa e cuja tradição histórica tem tudo a ver com o assunto em questão.  Mas fazer o que, brasileiro gosta de 'importar coisas americanas`.  E por incrível que pareça, ainda bem que eu tinha alguns docinhos (claro que não proposital), não é que fui surpreendido com algumas crianças vestidinhas de caveirinha na porta de casa! Só que, claro, ainda não familiarizados com a frasezinha - trick or treat, iam direto ao assunto: queremos doces... rs

Então já que é pra falar de coisas esquisitas, vou eleger um tema que para mim representa um capitulo completo de esquisitices: GAM Permissions.  Falo isso não apenas com relação ao modelo que se determinou para se dizer que um certo objeto Genexus terá um nome diferente no GAM, mas também o trabalho que dá defini-las na produção, principalmente para os objetos novos que forem criados posteriormente a publicação inicial do sistema.

Então se é pra matar o bixo no ninho, vamos atacar, claro munidos das nossas abobrinhas...

Permissions?

De forma simplista, GAM Permission significa um registro de um certo programa com suas diversas funcionalidades, que vinculado a um perfil determinará se certo usuário terá acesso (Allow) ou não (Deny|Restricted) ao mesmo.  Se quiser algo mais formal busque a documentação no Wiki, pra mim isso ai basta.

O GAM determina automaticamente os tais GAM Permissions a partir dos objetos da kb, gerando um ou mais registros de funcionalidades identificados por um Permission Name. O tal Permission Name é importante e tem uma particularidade que é um nome composto formado pelo objeto (transação, procedure, ...)  acrescido de um sufixo (_Execute, _Insert, ...)

Posteriormente, na existência do Permission Name, será possível vincular a permissão (Alow ou Deny) ao objeto para um certo perfil (Role).

Se criamos uma transação Cliente, por exemplo, uma série de novos GAM Permissions serão criadas no momento da especificação/geração da aplicação.

========== GAM Permissions Creation started ==========
Reading KB Applications ...
Processing Permissions ...
Generating Permission Cliente (1 of 32)
...

E as permissões resultantes serão:

TransaçõesExemploFuncionalidade
<objeto>_FullControlcliente_FullControlPermissão para executar, inserir, atualizar e apagar o cliente, sendo que este agrupamento que define todas as permissões de uma única vez
<objeto>_Executecliente_ExecutePermissão para executar o programa e apresentar o registro do cliente
<objeto>_Insertcliente_InsertPermissão para inserir cliente
<objeto>_Updatecliente_UpdatePermissão para atualizar cliente
<objeto>_Deletecliente_DeletePermissão para apagar cliente

Uma observação sobre a cliente_FullControl, é que ao designar esta permissão as demais (execute, insert, update e delete) serão designadas com a propriedade inherited (herdada) marcada.

Existem outros sufixos para determinar as permissões, maiores informações:

Vale a pena consultar esse wiki pois temos também os sufixos específicos para webservices, business components, ..., que não apresentamos exemplos aqui.

Acesso com Allow, Deny, Restricted?

Para designar certa permissão é necessário vincular o GAM Permission ao nível de acesso, que pode ser determinado de três maneiras possíveis:

AcessoSignificado
AllowNível de acesso liberado para o perfil
DenyNível de acesso negado para o perfil
RestrictedInicialmente o nível de acesso é negado ao perfil do usuário, a menos que outro perfil libere para o mesmo. Considere, por exemplo, uma pessoa com mais de um perfil designado, o acesso restricted será negado se no outro perfil estiver deny ou restricted, ou liberado se no outro perfil estiver allow.

O GAM trata de forma o conceito de permissões em forma de cascata, ou seja, soma-se as permissões que o usuário tem em todos os perfis que tem designado certo objeto para determinar se o mesmo possui ou não autorização sobre o mesmo.

Por exemplo, se certo usuário possui os perfis Role1 e Role2, e para certo objeto qualquer o Role1 define allow e o Role2 define deny, a permissão resultante será deny.  A tabela abaixo apresenta um resumo desta lógica.



Esta situação é explicada em detalhes na documentação do wiki. Maiores informações em:
Não esta muito claro a necessidade do Restricted, posteriormente poderemos retomar este assunto para abordar melhores estratégias de uso com esse recurso.

Criando as Permissões na Produção

Para facilitar um pouco nossa vida de desenvolvedor, o proprio Genexus/GAM criam automaticamente as permissões aos novos objetos incluídos na KB no momento em que executamos o programa.  Uma observação importante é que essas permissões são criadas localmente, ou seja, enquanto estamos construindo a aplicação.

Desta forma quando publicarmos no servidor de produção essas definições já estarão disponíveis. A pergunta que fica na gargante é o que fazer com o GAM da produção, quando o sistema já estiver funcionando e tivermos alguns novos objetos incluídos na aplicação? como ficam as permissões para esses novos objetos?

A resposta é não ficam...

De forma mais clara, as permissões serão criadas localmente na maquina do desenvolvedor mas não serão publicadas automaticamente no GAM na produção.  Precisaremos de alguma forma levar essas permissões para lá.

Para facilitar vamos chamar de GAM Produção e GAM Local, para identificar dois GAMs, um que esta publicado no servidor de produção e serve para que seus usuários sejam autenticados e autorizados para utilizar seu sistema, e o outro GAM que está na máquina do desenvolvedor da aplicação em sua empresa (local)

Existem três maneiras de realizar a operação de geração da permissão no GAM Produção:

1) Criando a Permissão Manualmente

Nesta opção basicamente você terá que reproduzir manualmente no GAM Produção a configuração que foi automaticamente gerada no GAM Local, situação não muito confortável mas também não muito complexa de fazer. Através do GAM Web BackOffice, é possível realizar esta operação na produção.

O maior trabalho aqui é controlar administrativamente os objetos que foram criados a partir do momento em que o sistema entrou em produção.

Para criar, você deve acessar o Backoffice com o usuário admin e em seguida na aba Applciations - Permissions, pressionar ADD para incluir uma nova permissão.

No formulário inserir o objeto e o sufixo responsável pelo acesso, que no caso de um WebPanel, por exemplo, colocar _Execute como o apresentado a seguir.


Esta operação vai incluir o WebPanel3 na lista de permissões.
Em seguida basta definir os perfis (Roles) que terão acesso ao recurso, como por exemplo, o Administrador recebendo o Allow para executar o tal webpanel.

Neste modelo o trabalho é grande devido a necessidade de para cada novo objeto ter que:
  1. Identificar os objetos que não possuem permissões criadas
  2. Criar a permissão manualmente para o objeto, e dependendo do tipo do objeto, ter que criar várias permissões
  3. Definir o acesso nos diversos Roles que terão acesso ou negação ao objeto.
Uma alternativa é utilizar a GAM API para programar um recurso para criar via programação as novas permissões e também a designação aos diversos perfis. 

2) Programando as Permissões

Neste modelo utilizamos a GAM API para produzir um programa para criar as permissões, para que em seguida possam ser designadas aos Roles.

Bom, lembre-se que estamos aqui falando de esquisitices, então não vai agora começar a ter chiliques, pois a programação que estamos propondo é pra lá de esquisita. De fato para compreender bem este tipo de programação recomendo a você que gaste um pouco de tempo lendo os programas exemplos do GAM Web Backoffice.  Este trecho de código foi adaptado do código apresentado no programa GAMExampleAppPermissionSelect.

Event 'Add'
 &GAMApplications = GAMRepository.GetApplications(&GAMApplicationFilter, &GAMErrors)

 &GAMApplication.Load(&GAMApplications.Item(1).Id)
 &GAMApplicationPermission.Name = &Name
 &GAMApplicationPermission.Description  = &GAMDescriptionLong
 &GAMApplicationPermission.AccessType =  &GAMPermissionAccessTypeDefault
 &isOK = &GAMApplication.AddPermission(&GAMApplicationPermission, &GAMErrors)
 if &isOK
commit
 endif
Endevent

Basicamente o que ele faz é o seguinte:
  1. Pega a aplicação corrente que se encontra registrado no GAM. Se houver mais que uma aplicação a linha &GAMApplications.Item(1).Id deverá pegar a aplicação correta da lista.
  2. Carrega esta aplicação com LOAD (muito parecido com o que fazemos com Business Components)
  3. Adicionar uma nova &GAMApplicationPermission nesta aplicação
  4. Commit se tudo ok
Basta criar um botão Add num Webpanel qualquer com um formulário que permita ingressar &Name&GAMDescriptionLong&GAMPermissionAccessTypeDefault. Variáveis que foram criadas segundo as seguintes definições.

O código cria a nova GAMPermission nas tabelas do GAM, em seguida basta aplica-la aos Roles desejados.  Não se esqueça de incluir os sufixos, como o _Execute, _Insert, _Update, ..., que devem ser incluídos na propriedade Name.  Por exemplo, para um webpanel chamado Teste a permisson deve ser teste_Execute.

Já produzimos um artigo para auxiliar na programação dos Roles e Permissions:


2) GAM Deply Tool

Finalmente, o GAM possui um recurso bastante interessante chamado GAM Deploy Tool que é uma ferramenta para ser utilizada para publicar e atualizar o GAM na produção.  Este recurso é muito importante para deixar o banco de produção com as mesmas características que o GAM Local.

Uma das características desta ferramenta é a possibilidade de se levar permissões de novos objetos, para atualizar o sistema em produção. Portanto, vale a pena gastar uns minutos para entender a ferramenta que está bem documentada.

Maiores informações:

Conclusão

Muita coisa importante num unico artigo, mas o tema é importante, pois sem dominar o conceito de Permissões e Acesso dificilmente haverá sucesso no uso do GAM. Nossa proposta de programação da permissão não é tão maluca assim, pois, devido a necessidade de se gerenciar os grupos, menus, melhor se houver uma forma programável para tratar disso tudo, e o recurso no GAM Web Backoffice, no meu ponto de vista não é tão legal assim.

Enfim, o que não podemos negar é que brasileiro também gosta de uma confusãozinha sobrenatural, veja nossas lendas, nossas musiquinhas de ninar, coisas de arrepiar o cangote. Nem precisa de uma abóbora esculpida com uma carinha de mal para assustar, basta cantar pra criança o nana nenê que a cuca vem pegar.... que já da certo, dorme na hora, rs