Problem

The user management system is a key part of any organization. As organizations grow, their services and internal tools continue to grow in number accordingly. Not having an efficient user management system can lead to serious security issues or difficulties in operation. One such case is having separate user management for each of the internal services. Imagine you have joined a company and you get five different usernames and passwords for each of the five services. You have to remember your username and password for each service. If someone leaves, their accounts need to be disabled on each of the 5 services. This task becomes tedious very easily. This is not just an example I have seen such a scenario.

The above diagram roughly summarizes what I am trying to say. As you can see not only end users had the tedious task of maintaining usernames and passwords but also developers needed to repeat authentication and authorization on multiple services. Carrot, Onion and Cucumber services all had the same repetitive code. There should be a better way.

Solution

After some research, I came up with a slightly different but more efficient approach. Since our organization had already been using Google Workspace I thought it would be a nice idea to integrate the authentication with Google so that all the users can be managed in place.

The idea is to have a gateway service that handles authentication and authorization every time a request comes in. The SSO Gateway service integrates with a third-party IdP Provider(here Google) but it doesn't have to be an IdP service. The Gateway routes only authenticated requests to downstream services. The architecture has a few advantages. First, we don't force users to remember separate login credentials for each service. Second, if anyone quits no need to disable users on multiple services but only on Google Workspace. Third, new services can easily be added without concerns about authentication and authorization. The SSO Gateway routes only authenticated requests to downstream services. Let's develop a new service called Tomato. In this case, we just deploy the Tomato service behind the SSO Gateway without exposing it to the public and update routing configurations in our gateway service.

In the next articles, we will implement the above architecture with Spring Cloud Gateway and Spring Security OAuth2.0 client.