Software And Architecture

Why a Vault? The reason for having a vault is to have the secrets for the application stored in a very "safe" / "secure" location so that only trusted clients of the Vault (Web Apps / Services etc ) can get access to the secrets. When we do not use a vault, the dev team will check-in the secrets like Database Credentials, AWS credentials etc to the source control, which leaves it open to be accessible to anyone that gets access to source code. There are a lot of Vaults out there in AWS, Azure etc, but this system is opensource and we have full control of the installation and security, which piqued my interest and hence I started exploration. Dangers of exposing Secrets In the hands of wrong person, it could be disastrous, especially if the secret has more privileges, more the depth of the damage Developers might get to try out changes with these credentials. In recent years, a colleague of mine forgot to append the where clause in the production

User Authentication in Multi-Tenant SaaS Apps Introduction We will cover few scenarios that we can follow to perform the user authentication in a Multi-Tenant SaaS application. Scenario 1 - Global Users Authentication with Tenancy and Tenant forwarding In this scheme, we have the SaaS Provider Authentication gateway that takes care of Authentication of the users by performing the following steps Tenant Identification User Authentication User Authorization Forwarding the user to the tenant application / tenant pages in the SaaS App This demands that the SaaS provider authentication gateway be a scalable microservice that can take care of the load across all tenants. The database partitioning (horizontal or other means) is left upto the SaaS provider Service. Scenario 2 - Global Tenant Identification and User Authentication forwarding   In the above scenario, the tenant identification happens on part of the SaaS provider Tenant Identification gateway. Post which, the

Migrating from Springfox to OpenAPI 3 in Spring Boot Application This blogpost, I would like to share about the migration to OpenAPI 3 in my project application that is built using Java 8 and Spring boot.  I was working in a project that had a very old framework support and JDK. I was taking my free time whenever I find one and then did some upgrade to the core so as to get the application to be on the latest frameworks and get support if any issues. Why Upgrade? The reason for upgrade is to facilitate the following The application dependencies are up-to-date, meaning that when we face any issue or require any help, people will be able to help (Community support). Though we have support for the deprecated frameworks also from the vibrant community like Stackoverflow.com, better to be with the upgrades There might be limitations hindering in building new functionality or extending existing ones with the older versions, so a version upgrade to the latest will be always handy