Two way SSL + JWT (segurança)

[kyriosdata]

Contexto

O acesso à informação em saúde é possível apenas em cenários restritos e bem definidos. Para requisitar qualquer informação à RNDS, por exemplo, primeiro é preciso obter um token de acesso. A obtenção ocorre por meio de serviço específico.

A requisição para este serviço é GET /api/token. O token só será recuperado por esta requisição se o certificado digital empregando por quem efetua esta requisição já estiver devidamente configurado com o serviço. Esta requisição usa Two Way SSL como mecanismo de autenticação. Se o resultado é positivo, então retornará um JWT. Caso contrário, a requisição falha.

Necessidade

Serviço similar ao oferecido pela RNDS.

Requisitos

• R1. Implementação deve ser realizada em Java. Caso faça uso de outro software existente, então este deve ser open source.

• R2. Serviço deve estar em conformidade com Manual de Configuração - Obtenção do token de acesso.

• R3. Serviço deve responder a requisição POST /certificado no qual o payload é o certificado .cer ou .pfx a ser "cadastrado". Este passo simula o processo de credenciamento. Nenhum segredo (chave privada) é mantido. Apenas a chave pública é mantida e associada ao usuário em questão. Adicionalmente, um código inteiro único é retornado para representar este usuário. Este valor inteiro de 5 dígitos, valor maior que 10000 deve ser único por usuário, que é identificado pelo próprio conteúdo do certificado. Observe que, por uma questão de desempenho, melhor é atualizar o SSLContext empregado com o conteúdo do certificado, em vez de armazená-lo em um keystore e ter que reiniciar a aplicação para que o keystore atualizado seja carregado.

• R4. Serviço deve responder a requisição GET /api/token e, se o certificado empregado em uma interação Two Way SSL foi cadastrado anteriormente, conforme requisição acima, então um JWT será fornecido como resposta.

• R5. Deve permitir o cadastro de certificado digital tipo A1 (.cer ou .pfx) (POST /certificado). Dados pertinentes deverão ser coletados do certificado para que possam ser confrontados em requisição posterior. Não é necessário que o certificado seja ICP-Brasil. Um certificado auto-assinado também deverá ser aceito. Observe que, para a RNDS, apenas certificados ICP-Brasil são aceitos. O processo, contudo, é o mesmo, o que não altera o processo de autenticação. Esta funcionalidade, conforme já mencionada, simula o processo de credenciamento.

• R6. Serviço GET /seguro que fornece resposta OK (200) ou não autorizado conforme a validação do token.

• R7. Deve incluir dois clientes, um em JavaScript e outro em Java apenas para ilustrar como as requisições citadas anteriormente podem ser executadas nestas duas plataformas. Ou seja, são clientes dos serviços a serem implementados.

Two Way SSL

• Securing Spring Boot Applications with SSL
• Two way SSL (introdução)
• Two way ssl (spring boot)
• Implementação alternativa de Two Way SSL (aqui)
• Recuperar certificado empregado pelo servidor (baeldung)
  • Via browser use o endereço https://ehr-auth-hmg.saude.gov.br:443 deve permitir clicar no "cadeado" e inspecionar o certificado.
  • Validar o certificado (aqui)
• TLS Setup no Spring (aqui)

JWT

• JWT for java (aqui)
• Criar e verificar JWT in Java:
  • git 8.3
  • oauth 4.7
  • jose

Cliente (execução de chamadas)

Aplicações cliente devem obter acesso ao token e, para tal, precisam adequadamente efetuar a requisição ao servidor.

• https://stackoverflow.com/questions/1666052/java-https-client-certificate-authentication
• https://dzone.com/articles/ssl-in-java
• https://gazelle.ihe.net/HAPI%20AND%20TLS
• https://dzone.com/articles/configuring-ssl-tls-connection-made-easy
• https://arunkrsoam.medium.com/rest-api-https-client-certificate-authentication-net-core-c-dd87f8a9647f
• https://docs.oracle.com/javase/10/security/sample-code-illustrating-secure-socket-connection-client-and-server.htm#JSSEC-GUID-A4D59ABB-62AF-4FC0-900E-A795FDC84E41
• Código em Java preliminar (aqui)

Integração do token

É possível que o serviço a ser construído precise contemplar necessidades do serviço protegido. O serviço protegido não faz parte do projeto, mas pode exigir funcionalidade a ser oferecida pelo serviço a ser construído.

https://www.youtube.com/watch?v=KxqlJblhzfI

[DukeOmni]

Estou tendo dificuldades para realizar testes no passo 1 Post "/certificado", para cadastrar no keystore um certificado auto-assinado. Através da ferrramenta postman a requisição simplesmente não passa quando importa um certificado auto-assinado.

[DukeOmni]

Ainda sobre o passo 1, post "/certificado". Quando é configurado no application.yml a opção client-auth: need, ele necessariamente espera um certificado que já está importado no keystore. A pergunta é como abrir esse endpoint para cadastrar o novo certificado, visto que o serviço sempre espera um

[kyriosdata]

O endpoint /certificado não será protegido. Qualquer um poderá submeter um certificado para o nosso credenciamento, ou seja, para /certificado. De fato, nem tampouco /api/token será protegido. Ou seja, qualquer cliente poderá realizar as duas operações. A primeira tem uma diferença da segunda muito importante. A primeira sempre irá funcionar, enquanto a segunda pode não retornar um token conforme desejado, afinal, se o cadastramento prévio não foi feito previamente, então não poderá ser gerado um token.