RadarCOVID Verification Service
Verification Service in terms of the Radar COVID project enables:
- Autonomous Communities are able to request verification codes so then they can give them to COVID-19 patients.
- Once COVID-19 patients have the verification code, they can use
the mobile application to send this verification code so
Verification Service can:
- Check if the verification code is correct, exists in database, is not redeemed and is not expired.
- Once verified, Verification Service returns a JSON Web Token (JWT) so mobile application can send the exposition keys to the DP3T service.
These are the frameworks and tools used to develop the solution:
- Java 11.
- Spring Boot version 2.3.
- Lombok, to help programmer. Developers have to include the IDE plugin to support Lombok features (ie, for Eclipse based IDE, go here).
- ArchUnit is used to check Java architecture.
Installation and Getting Started
Before you continue reading, let us let you know that there is sample code:
CheckSumUtil. Both methods (
validateChecksum) are not real in order to avoid Production requests, since some people is sending incorrect verification codes.
JwtAuthorizationFilter. These properties are not real in order to avoid illegal requests:
Building from Source
To build the project, you need to run this command:
mvn clean package -P<environment>
<environment> has these possible
local-env. To run the application from local (eg, from IDE o from Maven using
mvn spring-boot:run). It is the default profile, using
docker-env. To run the application in a Docker container with
pre-env. To run the application in the Preproduction environment, using
pro-env. To run the application in the Production environment, using
All profiles will load the default configuration file.
Running the Project
Depends on the environment you selected when you built the project, you can run the project:
- From the IDE, if you selected
local-envenvironment (or you didn't select any Maven profile).
- From Docker. Once you build the project, you will have in
verification-server-boot/target/dockerthe files you would need to run the application from a container (
Dockerfileand the Spring Boot fat-jar).
If you want to run the application inside a docker in local, once you built it, you should run:
docker-compose up -d postgres docker-compose up -d backend
This project doesn't use either Liquibase or Flyway because:
- DB-Admins should only have database privileges to maintain the database model (DDL).
- Applications should only have privileges to maintain the data (DML).
Because of this, there are two scripts:
01-VERIFICATION-DDL.sql. Script to create the model.
02-VERIFICATION-DML.sql. Script with inserts. This file (and also
data.sql) contains sample data for record
Along with the application there comes with OpenAPI Specification, which you can access in your web browser when the Verification Service is running (unless in Production environment, where it is inactive by default):
If running in local, you can get the OpenAPI accessing http://localhost:8080/openapi/api-docs. You can
download the YAML version in
You can get a copy here.
||Verify provided code|
When an Autonomous Community (CCAA) asks for generating
n codes to the Verification Service, firstly the CCAA
needs to generate a private key to create the JSON Web Token (JWT) and sends
the corresponding public key to the Verification Service.
This service uses Elliptic Curve (EC) keys to allow Autonomous Communities to request verification codes and to sign the given response.
To generate the keys you can use these commands (OpenSSL tool is required):
- Generate private key:
openssl ecparam -name secp521r1 -genkey -noout -out generated_private.pem
- Converse private key to new PEM format:
openssl pkcs8 -topk8 -inform pem -in generated_private.pem -outform pem -nocrypt -out generated_private_new.pem
- Get Base64 from private key:
openssl base64 -in generated_private_new.pem > generated_private_base64.pem
- Generate public key:
openssl ec -in generated_private_new.pem -pubout -out generated_pub.pem
- Get Base64 from public key:
openssl base64 -in generated_pub.pem > generated_pub_base64.pem
Creating JWT from CCAA
Once CCAA has generated its private/public keys, CCAA has to
send the public key to the Verification Service. The Verification
Service will save this public key in the
VERIFICATION.CCAA table, with the record that
corresponds with the code (
DE_CCAA_ID) for that
The CCAA will create a JWT code (ie,
use it to invoke to
/generate endpoint. The JWT token
has to be in the
(NOTE: the name of this header is an example; in Production
environment, it is different).
Generation codes signature
generate response has a
so client applications can verify if the response is valid.
Verification Service will provide his public key to the CCAA so
then they are able to check the signature.
GenerationControllerTestSpec is a
good example that shows how it works.
Verification Service has four modules:
verification-server-parent. Parent Maven project to define dependencies and plugins.
verification-server-api. DTOs exposed.
verification-server-boot. Main application, global configurations and properties. This module also has integration tests and Java architecture tests with ArchUnit:
verification-server-service. Business and data layers.
Support and Feedback
The following channels are available for discussions, feedback, and support requests:
If you want to contribute with this exciting project follow the steps in How to create a Pull Request in GitHub.
More details in CONTRIBUTING.md.
This Source Code Form is subject to the terms of the Mozilla Public License, v. 2.0.