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

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.

2.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.

3.2. Desenvolvimento

3.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.

3.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

3.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

3.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.

4.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.

5. 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.