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



terça-feira, 10 de novembro de 2015

Como aproveitar uma excelente oportunidade

Oportunidades não aparecem todos os dias, melhor sempre estar preparado para aproveitá-las quando surgem, então vou aqui te dar algumas dicas:

1) Primeiro a preparação, pois quando a oportunidade aparece você deve estar pronto.


2) Obtendo uma certificação profissional para te destacar no mercado, pois nada como ter estampado em seu curriculum uma Certificação Analista Sênior Genexus, não? No site training você encontra as provas teste para que possa identificar quais são os pontos que lhe faltam estudar.


3) Encontrando as oportunidades, e aqui a grande novidade, a própria Genexus acaba de nos presentear com um portal de oportunidades.


4) E sabe de uma coisa, tem muitas fora do Brasil, que tal estudar Espanhol também.


Boa preparação!

segunda-feira, 9 de novembro de 2015

Single Sign On


Que tal este cenário: Um usuário, digamos o Zezinho, abre uma aplicação sua chamada Solução1 e trabalha normalmente, isso após ter realizado o login corretamente.  Posteriormente, no mesmo navegador o Zezinho abre uma segunda aplicação, Solucao2, e digamos que de forma automática, a Solução 2 já identifica que o Zezinho já se encontra autenticado e o libera de realizar o login novamente.

De forma bem clara, o Single Sign On - SSO, prove um mecanismo para centralizar a autenticação de seus usuários a partir de um ponto único para todas as suas aplicações e o GAM é um recurso de proteção de um projeto Genexus construído com um protocolo que possibilita desenvolver sistemas de autenticação no formato do SSO.  Então que tal estudarmos um pouco a respeito deste assunto e melhorar a qualidade do serviço que prestamos a nossos usuários?


O nome disso? 
Single Sign On ou SSO, e se quiser uma definição mais formal olhe aqui.

Quem utiliza isso? 
Praticamente todos os fornecedores de aplicações que se prezem a realizar um trabalho com foco no conforto do usuário, como por exemplo o Google, Facebook. Lembre-se, por exemplo, do Gmail que uma vez realizado o login para ler seus emails, libera o acesso do Google Drive sem que se tenha de realizar a operação novamente.

Podemos programar isso em Genexus?
Sim, aplicando o GAM na nossa Kb e criando o chamado Identity Provider, um provedor de identidade. E não precisa programar nada, o próprio GAM se encarrega de controlar tudo para você, logo após uma pequena porção de configuração.


Como o GAM implementa o SSO?
O GAM é construído baseado na OAUTH, um protocolo que permite que Aplicações Clientes possam se conectar a aplicações Web, Desktop, Smartdevice e Living Room Device, provendo controle sobre a autenticação e autorização de usuários,


O que é Identity Provider?
É um tipo de aplicação que fornece um serviço de autenticar usuários remotamente.  Como resposta este sistema devolve se houve sucesso ao autenticar um usuário e senha fornecidos.  Um protocolo padrão na Web define os procedimentos necessários para implementar este tipo de ação, o OAUTH, o mesmo usado no GAM e em praticamente todos os demais Identity Provider (Facebook, Google. ...)


Como Fazer?
Primeiramente utilizando o GAM, seguindo os passos que já foram extensamente documentados no Wiki, que estarei incluindo aqui, mas como sou inxerido, resolvi adicionar um pouco mais de clareza neste tema, então neste artigo estaremos:
  1. Configurando um Identity Provider para gerar um SSO com Genexus
  2. Discorrendo sobre esta funcionalidade sob o ponto de vista da aplicabilidade no mundo real

Configurando o Identity Provider

Identity Provider é definido como sendo um provedor de identificação, e se algum dia você realizou uma conexão entre seu sistema e o Facebook, por exemplo, utilizou o provedor de identificação deste sistema. Este provedor, basicamente fornece um serviço que avalia se certo usuário e senha são os que se encontram registrados em seu repositório, devolvendo o resultado para a aplicação cliente.

O modelo Single Sign On proposto aqui basicamente define uma de nossas KBs como sendo um Identity Provider, por meio de um recurso que o GAM passou a implementar a partir da EV3.  E em seguida, outra KB cliente se conectará ao nosso Identity Provider para confrontar se certo usuário já se encontra logado, basicamente, o que o sistema analisa é se existe alguma sessão válida no navegador e se o usuário desta sessão pode utilizar os recursos disponíveis.

O processo de configuração é meio confuso, mas vamos 'tentar' explicar de forma mais simples.

Maiores informações a respeito do Single Sign On com o GAM pode ser alcançado daqui.

1. Crie Duas Kb: Provedor e Cliente

Vamos começar definindo duas kbs que estaremos configurando o GAM. Uma chamaremos de GAM.PROVIDER e outra de GAM.CLIENT, sendo que na GAM.PROVIDER definiremos posteriormente como sendo nosso Identity Provider, ou seja o GAM que será chamado pela aplicação GAM.CLIENT para autenticar remotamente um usuário qualquer.

Após criar as duas KBs acesse a propriedade Enabled Integrated Security (em Preferences - Kb) e a defina como YES. para aplicar o GAM em ambas.  (GAM Getting Started)  Tenha um pouco de paciência neste momento e espere ate que o Genexus volte a funcionar, pois esta operação realizará uma série de importações e pode parecer que a ferramenta ficará indisponível por alguns segundos.

Execute as duas Kbs, configurando os Datastores de ambas, cada qual com um banco de dados separado. O Datastore GAM de ambas as kbs pode ser o mesmo que o definido em Default.


O Genexus levará um tempo para executar as duas kbs, visto que muitos objetos foram criados com a aplicação do GAM.

2. Configurando o GAM

Um resumo do que faremos é registrarmos na GAM.PROVIDER a aplicação da KB GAM.CLIENT, e na GAM.CLIENT definir a autenticação remota.


2.1. Client Id e Secret
Quando ambas as kbs estiverem em funcionamento no navegador de internet, você deverá ingressar no GAMHome (User: admin, Senha: admin123), para ler as configurações que foram geradas.  Para isso acesse o Applications e abra o registro de GAM.PROVIDER e GAM.CLIENT.


Para facilitar as coisas anotei os dois Client Ids e Secrets que utilizaremos para configurar o Identity Provider.  Observe que os valores de Clent Id Secret de ambas as Kbs são distintos e estaremos os valores de GAM.CLIENT para configurar a operação de Single Sign On. Os valores da GAM.PROVIDER não serão utilizados.



2.2. Adicionando a Kb Client no GAM.PROVIDER
A primeira operação a caminho do Single Sign On é adicionar em GAM.PROVIDER um registro de uma aplicação cliente, nossa GAM.CLIENT. Isso é feito em GAM.PROVIDER - Applications, e em seguida uma operação ADD para adicione o registro com as seguintes informações.


Observe que o Client Id e Client Secret são os mesmos da GAM.CLIENT, e novas propriedades devem ser informadas:

Local Login URL deve apontar para o programa gamremotelogin.aspx da kb GAM.PROVIDER, portanto, http://localhost/GAMPROVIDER.NetEnvironment/gamremotelogin.aspx, e Callback URL o endereço da GAM.CLIENT, http://localhost/GAMCLIENT.NetEnvironment.

Após a inclusão da aplicação teremos o registro do GAM.CLIENT como uma segunda aplicação gerenciada pelo GAM de GAM.PROVIDER

Em outras palavras, estamos dizendo que o GAM localizado na kb GAM.PROVIDER será um dos provedores de identidade para os clientes de GAM.CLIENT.  Desta forma, para se executar o GAM.CLIENT será necessário realizar uma operação de login, e esta poderá ser disparada no provedor de identidade (GAM.PROVIDER).


2.3.Configurando o GAM.CLIENT
Para realizarmos o login no GAM.PROVIDER teremos que registrar um método de autenticação do tipo acesso remoto (GAM.REMOTE)  na GAM.CLIENT, Desta forma disparamos uma autenticação em outro GAM, que não o definido na aplicação cliente.

Ao adicionar este novo Authentication Type, teremos novamente que utilizar os valores de ClientId e ClientSecret e Private encryption key , que foram previamente registrados no GAM do provedor de identidade (GAM.PROVIDER), e para os valores de Local site URL = http://localhost/GAMCLIENT.NetEnvironment/ e Remote server URL = http://localhost/GAMPROVIDER.NetEnvironment/


Maiores informações em:


Logando uma Unica Vez

Para testar o modelo basta criar um usuário qualquer na kb GAM.PROVIDER, e em seguida realizar o login remoto a partir da kb GAM.CLIENT.

Apesar de não existir o usuário na kb GAM.CLIENT, o acesso será permitido porque a autenticação do mesmo acontecerá na kb GAM.PROVIDER. Na primeira vez que isso ocorrer, uma tela se abrirá para que o usuário seja criado também na GAM.CLIENT (sem a senha, que ficará na GAM.PROVIDER).

Desta forma, após o login ter sido realizado, o usuário passa a existir em ambos os GAMs. E se selecionar um objeto em ambas as kbs o mesmo será aberto sem que haja a necessidade de realizar novamente a operação de autenticação.

Um detalhe importante é que a operação de autenticação é realizada remotamente, ou seja, um objeto GAMRemoteAccess localizado na GAM.PROVIDER deverá ser aberto para que se ingresse com o usuário e a senha.



Sessão & Logout

Uma vez autenticado remotamente, uma sessão valida será aberta também no GAM.CLIENT, ou seja, a autenticação já havia criado uma sessão valida anteriormente no GAM.PROVIDER. E as duas sessões já liberam o acesso a ambos os sistemas.

Todo o processo de validação da sessão é realizado mediante o definido no protocolo da OAUTH, e tratado pelo GAM sem que seja necessário programar nenhuma linha de código.

Para encerrar a sessão é necessário realizar o logout no GAM.CLIENT, mas isso não encerrará a sessão no GAM.PROVIDER.  Isso causará um efeito, no minimo interessante, pois mesmo se fechar a aba do navegador do cliente, e abrir uma nova no mesmo navegador, o login no GAM.PROVIDER estará ativo e não será necessário autenticar novamente, pois uma nova chamada ao GAMRemoteLogin abrirá novamente a sessão.

Event 'Logout'
GAMRepository.Logout(&gamerrors)
for &gamerror in &gamerrors
msg(&gamerror.Message)
endfor
Endevent

Um logout definitivo somente ocorrerá se a sessão no GAM.PROVIDER for encerrada, como por exemplo, pelo fechamento do navegador.

Maiores informações em:


Tratando o Perfil do Usuário

Para que tudo funcione corretamente no sistema, precisamos ainda tratar da questão do perfil do usuário (Role), isso porque o acesso aos objetos são definidos no próprio Role.

Uma nota importante aqui é que as definições de permissões são sempre no CLIENTE, mediante as definições de Allow e Deny que foram definidas para cada objeto a um certo Role. A autenticação (Authentication) determinará se o cliente pode ingressar no sistema e a autorização (Authorization), determinará quais objetos podem ser acessados, e qual o privilégio de acesso.  Desta forma as definições do PROVIDER não contribuirá no acesso do cliente.

Por outro lado, um detalhe importante é a transferência dos Roles do usuário para a aplicação cliente, que pode ocorrer no processo de login.  Ou seja, quando uma pessoa realiza o login remoto, os Roles definidos na aplicação PROVIDER podem ser replicadas na aplicação CLIENT.

Para que isso ocorra é necessário mapear os perfis utilizando-se a propriedade ExternalId, isso ocorre porque os nomes dos perfis podem até serem iguais, mas como o GAM somente leva em conta o GUID dos perfis, e como estes sempre serão diferentes, precisaremos definir um código próprio para estabelecer a correspondência, sendo aceito números, letras, para definir uma palavra que crie a associação. Por exemplo:


Ao fazer isso, quando realizar a autenticação de um usuário, os perfis (Roles) definidos no PROVIDER serão replicados no CLIENT.

Maiores informações:



Criticas a OAUTH

Finalmente, o GAM é baseado especificamente no protocolo da OAUTH, e como existem similares no mercado que se propõe a realizar a mesma coisa, existem criticas e elogios aos modelos propostos, e fica sempre a duvida a respeito da robustez do GAM para atender as nossas aplicações.

Separei dois artigos interessantes a respeito desta novela para que você tire suas próprias conclusões.


Conclusão 

Antes de finalizar, vamos destacar o excelente trabalho feito pela Genexus para nos disponibilizar este grande recurso, e principalmente pelo farto material disponibilizado na Wiki que foi uma base excepcional para que chegássemos a este artigo, que em muitos detalhes reproduziu a mesma linha de raciocínio dos desenvolvedores. (Atualmente a Wiki possui 405 artigos sobre GAM!)

Este tema é muito interessante para ficar em um único artigo, acredito que logo voltaremos ao tema, para mostrar detalhes mais práticos a respeito do SSO em multiplas kbs Genexus.