Ir para o conteúdo

Aplicação Remota das Políticas de Acesso

O Autoriza pode atuar como um provedor de serviços para autorização remota de acesso.

O controle da autorização fica de fato com o Autoriza, a aplicação parceira apenas demanda a aplicação das políticas de acesso.

Nesse cenário, o sistema utilizará os serviços da API de validação, conforme detalhado no exemplo de uso.

Conforme falado no início, o sistema precisa resolver a autenticação do usuário antes de acionar o Autoriza. Ou seja, se o usuário ainda não fez o login, ele precisa fazer.

O fluxo de troca de mensagens de controle de acesso para um usuário ainda não logado na aplicação está representado no diagrama a seguir.

Autoriza como serviço de aplicação remota das políticas de acesso para um usuário ainda não autenticado

Caso o usuário já esteja logado na aplicação, ela já pode acionar diretamente os serviços do Autoriza.

O fluxo de troca de mensagens de controle de acesso para um usuário já logado na aplicação está representado no diagrama a seguir.

Autoriza como serviço de aplicação remota das políticas de acesso para um usuário já autenticado

O que é preciso cadastrar no Autoriza?

Para possibilitar essa integração, é preciso que seja realizado, para o sistema, o cadastro das seguintes entidades no Autoriza:

  • Sistema
  • Perfis
  • Políticas de acesso
  • Transações (opcional)
  • Atribuições de perfis a usuários
  • Features e características do usuário (opcional)

Benefícios

👉 Possibilita ao gestor a administração centralizada da criação de perfis e transações, atribuição desses aos usuários, e definição das políticas de acesso
👉 Possibilita ao gestor o rastreamento das mudanças realizadas nos cadastros de perfis, transações, políticas de acesso e atribuições, bem como das autorizações de acesso realizadas, através da auditoria
👉 Possibilita ao gestor um completa governança da autorização. Mudanças nas políticas de acesso da aplicação não precisam de um novo release
👉 Delega para o Autoriza a manutenção, evolução e suporte dos cadastros relacionados à autorização, bem como da lógica necessária para aplicação das políticas de acesso, possibilitando à aplicação parceira um maior foco nas demandas diretamente relacionadas aos seus fluxos de negócio

Limitações

✋ Maior granularidade de chamadas remotas entre os modelos de integração, onerando a performance da aplicação parceira
✋ Menor flexibilidade em relação a adoção de lógicas específicas do negócio durante o controle de acesso

Cenários indicados para uso

O uso desse modelo de integração, por ser o de que mais demanda chamadas remotas ao Autoriza, é recomendado apenas para aplicações com uma única persona, ou para um controle mais restrito a alguma funcionalidade aplicação.

Por exemplo, sua aplicação só precisa validar o acesso do usuário uma vez, quando ele loga, para verificar se ele possui um determinado perfil de acesso. Após essa validação, o usuário terá acesso total à aplicação.

Outro exemplo, você tem uma aplicação com várias telas e componentes de tela, mas tem uma funcionalidade chamada "Limpar Base de Dados", a ser usada com bastante parcimônia, que é acessível apenas para usuários com uma determinada transação. Você decide adotar esse modelo de integração exclusivamente para a funcionalidade "Limpar Base de Dados".

Utilizar apenas em fluxos que possuem um número de validações de autorização bem restrito

A adoção desse modelo não é sustentável por uma típica aplicação de governo, com um bom número de personas, casos de uso e componentes de tela, uma vez que cada interação do usuário aciona uma chamada remota ao Autoriza, inviabilizando uma boa performance da aplicação.