[Gov.Doc] Identificar servidor atráves do E-Estado

Objetivo

O Objetivo desse estudo é analisar o impacto dentro do sistema Gov.Doc e encontrar uma solução no tocante a alteração de identificação de servidores através do E-Estado.

O sistema Gov.Doc não possui responsáveis designados cabendo a própria SETIC gerir o sistema e atribuir perfis a usuários que necessitarem de acesso. Verificando a expansão de uso em outros sistemas, já sendo adotado no Regulariza Já, SOLAR, PPE, SUSIE e SID sentiu-se a necessidade de remover a responsabilidade de ação humana para atribuir perfis e verificar se é servidor ou não, além da impossibilidade de acompanhar se um usuário deixou de ser servidor e trocar o perfil de acesso manualmente. Sendo o objetivo desse estudo analisar a possibilidade de automatizar os cenários de atribuir perfil e verificar se é servidor ou não.

Análise dos Impactos

Atualmente, o Gov.Doc identifica quem é usuário externo e servidor através de um perfil no Sauron, porém, isso precisa ser alterado dentro do sistema para que seja consumido do e-estado para saber quem é servidor e quem não é, mantendo apenas um perfil único para os usuários, assim, ao invés de identificar através do Sauron como é feito atualmente, removeremos os perfis "Usuário Externo" e "Servidor" unificando para um único perfil chamado "Usuário".

Em razão disso, foram analisados os impactos dentro do Gov.Doc na identificação e na alteração dos perfis, e seriam necessárias apenas alterações nas Controllers onde são feitas as validações de políticas de acesso do sistema, além disso, é possível que tenham de ser feitas as mesmas validações na API do Gov.Doc.

Soluções Propostas

Para atingir o objetivo descrito, foram encontradas duas soluções as quais resolvem  o problema da identificação, onde remove-se os perfis de "Usuário Externo" e "Servidor" e adiciona um perfil novo chamado "Usuário" onde todo e qualquer usuário terá esse perfil, exceto administradores do sistema que utilizam o perfil "Administrador", além disso, a identificação de servidores deverá ficar por conta do E-Estado através da sua API ou através de uma Claim do SAURON que serão descritas abaixo. Com isso, é possível identificar as Histórias de Usuário para que seja factível implementar as alterações das soluções.

Solução 1: Consumir Claim do Sauron

Para essa solução, é necessário a implementação da verificação se o usuário é servidor ou não dentro da funcionalidade de login do SAURON, uma verificação parecida com a que já é feita hoje para o Portal do Servidor, com isso, o Gov.Doc consegue gerenciar através das politicas de acesso do sistema utilizando a Claim retornada do SAURON. Para a implementação dessa solução é possível levantar as seguintes histórias de usuário.

- Como Setic, preciso criar um perfil chamado "Usuário" (1 ponto);

- Como Setic, preciso que os perfis de "Usuário Externo" e "Servidor" sejam excluídos (1 ponto);

- Como Setic preciso atribuir o perfil "Usuário" para as pessoas que tinham os perfis "Usuário Externo" e "Servidor" os quais foram excluídos (3 pontos);

- Como Setic, preciso criar Claim de identificação de servidor dentro do SAURON (2 pontos);

- Como Setic, preciso identificar os servidores através da Claim do Sauron (3 pontos);

- Como Setic, preciso autorizar o acesso de acordo com as politicas de acesso definidas pelas Claims (2 pontos);

- Como cidadão eu preciso acessar o Gov.Doc para assinar um documento (5 pontos) - Tela de login e cadastro.

Prevendo 17 pontos

Solução 2: Consumir do E-Estado

Para essa solução, é necessário consumir a API do E-Estado para verificar se o usuário é servidor ou não, em toda funcionalidade que exigir que o usuário seja servidor, sendo cada verificação uma requisição para a API do E-Estado. Para a implementação dessa solução é possível levantar as seguintes histórias de usuário.

- Como Setic, preciso criar um perfil chamado "Usuário" (1 ponto);

- Como Setic, preciso que os perfis de "Usuário Externo" e "Servidor" sejam excluídos (1 ponto);

- Como Setic preciso atribuir o perfil "Usuário" para as pessoas que tinham os perfis "Usuário Externo" e "Servidor" os quais foram excluídos (3 pontos);

- Como Setic, preciso identificar os servidores através da API do E-estado (5 pontos);

- Como Setic, preciso autorizar o acesso de acordo com a requisição enviada para o E-Estado (2 pontos);

- Como cidadão eu preciso acessar o Gov.Doc para assinar um documento (5 pontos) - Tela de login e cadastro.

Prevendo 17 pontos

Riscos

Após a formulação das soluções, identificamos alguns riscos nas soluções propostas, que serão definidos abaixo.

- Nana solução 2, oconforme descrito abaixo:

- O uso da API do E-Estado será menos performática, pois a cada funcionalidade e tela que o usuário acessar será enviada uma requisição para a API, isso irá causar um número grande de requisições.

- Na solução 1, entende-se que o uso de verificação de servidor na Claim de sessão do Sauron é temporário, até que outra forma de verificação melhor exista.

Conclusão

Através das soluções descritas acima, bem como, toda a problemática explanada, identificamos como melhor opção para atender o objetivo do estudo, a solução 1, pois não foram identificados riscos relevantes nem problemas de performance, dos sistemas inclusos nesse estudo.

Glossário

Gov.Doc - Sistema de Documentos do Estado de Rondônia

API -  É um conjunto de definições e protocolos usado no desenvolvimento e na integração de software de aplicações

Superintendente
Delner Freire

Diretor
Maico Moreira da SIlva

Gerente de Desenvolvimento
Janderson de Castro Thomaz

Product Owner
Adriano Bonazoni Sol Sol de Oliveira

Scrum Master
Wagner Moreira Melo

Time de Desenvolvimento
Tambaquis