| Data de elaboração | 19/09/2021 |
| Responsável pelo estudo | Gabriel Santi Binda (Assessor), Raissa de Sousa Stolduski (Assessor), Taillon Miguel Gonçalves (Assessor) |
| Equipe do estudo | Tambaqui |
| Alvo | Gov.Doc |
| Origem | Objetivo estratégico: 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. |
| 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. |
| Observações |
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.
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.
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.
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
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
Após a formulação das soluções, identificamos riscos na solução 2, conforme descrito abaixo:
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.