SSO with Goolgle for a SPA using Cellery in Kubernetes

No one likes maintaining several different accounts for all their internal apps. Single sign-on utilises just one set of login credentials to access multiple applications.

But when we are implementing this from scratch, we have to do many things. We should decide which pages we are going to restrict without authentication and we should implement the logic to prevent the users to access those restricted pages without authentication. Hence we may have to implement a separate service to keep checking the status of the user.

How to implement SSO with Google in Kubernetes

Here again you may have to do many things. You may have to create a config map or write a separate service for authentication. But any of these methods will take more time. If you want to implement SSO with Google in Kubernetes from scratch, here is a good article to read. But why should we follow such a long method while there is such a nice way to do this within few minutes.

How easy is it with Cellery

First of all, it is better to have a basic knowledge about Cellery. What and why we should use Cellery. Also it is better to have a knowledge about implementing micro services with Cellery. If you have a bit knowledge about these, it will take only a minute to implement this.

Initiate a project with Google cloud console

First of all let’s have the client id and secret from the Google cloud console. Please follow this to get client id and secret from the cloud console. Note that you may have to add pet-store.com as an authorised domain name and http://pet-store.com/_auth/callback as the callback url. It should be like below,

Let’s implement the cells

Let’s have a simple demo application to explain this.

Here is a sample application called pet-store with Cellery. You can have the source code for this from here.

This is a very simple application with two cells. Every request users will go through the pet-fe cell’s gateway. Now you may see that where we should implement SSO. Yes, obviously in the pet-fe cell. Let’s have a look at the pet-fe cell’s code. You can have the code here.

In the pet-fe.bal file, inside the build method, you will see that there is a cellery component called, portalComponent. There you can see gateway configs of the cell, inside the ingress. You can see that there is a clientId and a clientSecret. You can simply copy paste your client id and secret from the cloud console there. Then remove the runtime configurations from the run method. Finally your pet-fe.bal should be like this,

Let’s dive deeper

Here is a simple diagram to explain the scenario

Let’s go into this step by step (Consider the user has not been logged yet and going to browse a secured path)

1. SPA will be loaded into the web browser. when the user browse a web page, a request will be sent to the web ingress.
2. Ingress will redirect the request to the relevant service.
3. Since this is a non secured path, the gateway will redirect the request to the relevant idp. (since we provided the url and credentials of Google idp to the cell gateway, it will be redirected to the Google idp)
4. Google idp will do the authentication and send the response to the given callback url.
5. Finally, user will be able to browse to the secured web page, fetching necessary data from the back-end.