GSoC 2021 with SCoRe Lab — Week 9
tl;dr — This is the tenth article of my journey into the Google Summer of Code 2021 with SCoRe Lab. Here I discuss week nine (19th of July to 25th of July) of my GSoC experience.
Life after the evaluations,
After the evaluations week, I resumed my work on the DNS-Tool-Middleware project. As I mentioned in my previous post, my mentor and I discussed the authentication flow on how to grant authorization to the users who need to download resources from Google Cloud Storage. So according to our user authentication flow, first, we need to generate a unique service account for that specific user and for that specific scan. To create this service account I decided to follow the best practices used by Google itself. The following article is a good read if you need to learn about how the Google Service Account JSON files work.
The following is a sample Google service account JSON file.
{
"type": "service_account",
"project_id": "demo-project",
"private_key_id": "f871b60d0617be19393bb66ea142887fc9621360",
"private_key": "-----BEGIN RSA PRIVATE KEY-----.....",
"client_email": "look-no-keys@demo-project.iam.gserviceaccount.com",
"client_id": "102234449335144000000",
"auth_uri": "https://accounts.google.com/o/oauth2/auth",
"token_uri": "https://oauth2.googleapis.com/token",
"auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
"client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/look-no-keys%40demo-project.iam.gserviceaccount.com"
}The keys in the above JSON object has the following meaning,
So, what I did was, I created my own service account file with the same above fields 😁.
The following is a sample service account JSON file of DNS-Tool-Middleware.
The private_key_id is a special unique key to identify a specific service account JSON file and it resembles the functionality of a Google service account JSON file. The private_key_id is used to check if the certain service account file is used by the user and it is also used to check if the authentication token sent by the user is valid. The private_key_id is actually a string with random 16 bytes hashed using the SHA256 hashing algorithm. So it remains considerably unique 😂. I used the following wonderful Python library to generate this random bytes string.
The private_key is a 2048 bit RSA private key in PEM encoded format. It is generated using the above mentioned Python library. The client_email is the email of the user who obtained the service key, the client_id is the Firebase UID of the user who obtained the service key, the scan_id is the ID of the scan that the user wants to download resources from Google Cloud Storage, and the scans is the scans related to the specific scan_id.
By using this service account file, the user requests can be authenticated and checked against the server for validity. Special thanks to the following article for opening my mind 🙏.
With these implementations, I submitted a PR,
and it got merged into the main repository.
So in the coming weeks, I will be working further on the authentication workflow, and until we meet again, happy coding…
