[Gov.Doc] Identificar servidor atráves do E-Estado
| Data de elaboração | 19/09/2021 |
|---|---|
| Responsável pelo estudo |
|
| 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.
1. Introdução
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.
2. Desenvolvimento
2.1 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.
2.2 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
2.3 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
2.4 Riscos
Após a formulação das soluções, identificamos riscos na solução 2, conforme 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.
3. 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.
Nenhum comentário