What is SSO ?

A user can sign in with a single ID to any number of connected but independent software systems using the single sign-on authentication scheme. True single sign-on enables users to log in just once and access services without having to enter their authentication details again.

The need to remember and input several passwords is gone thanks to single sign-on, and the hassle of having to reset lost passwords is also gone.
Additionally, users don’t need to log in each time to access a variety of platforms and apps.

 

Why do we need SSO?

Without a Centralized System

In an organization, there are many applications that a user needs to access to perform day to day business. Suppose an organization has a separate database/user store for each individual application to store user credentials. In such scenarios, IT departments have to create, update, or delete users in each location, which is a lot of work.

With a centralized system

Without having separate DBs for applications they might have a centralized system where all the users are stores.

In this case, it is easy to manage users but still, they need to think about security, federation options, how to provision a user and etc. This will be a burden for an organization because managing, authenticating and providing authorization to a user is not their main business objective. Yet they need to spend a huge amount of time and effort in the identity domain.

So the solution is to use an Identity Server which has the capability to manage identity requirements in a company.
The benefits of using an Identity provider to manage identity and access management in an organization are it enables SSO, easy to manage users, do not need to put lots of effort into identity requirements and much more.

How SSO Works ?

The foundation of SSO is a trust relationship established between a service provider—a program—and an identity provider.

A certificate that is exchanged between the identity provider and the service provider frequently serves as the foundation for this trust relationship.

This certificate can be used to sign identity information that is being sent from the identity provider to the service provider so that the service provider knows it is coming from a trusted source. In SSO, this identity data takes the form of tokens which contain identifying bits of information about the user like a user’s email address or a username.

1. A user navigates to the service provider, often known as the programme or website they want access to.

2. As part of a request to authenticate the user, the Service Provider sends an authentication token to the SSO system, also known as the Identity Provider, that includes certain user information, such as the user’s email address.

3. If the user has previously been authenticated, the Identity Provider will first determine whether to allow access to the Service Provider application and move on to step 5.

4. The user will be requested to log in if they haven’t already by supplying the Identity Provider’s needed credentials.
This may just require a login and password, or it may also require another type of authentication, such as a One-Time Password.

5. The Identity Provider will send a token back to the Service Provider verifying a successful authentication once it has verified the submitted credentials.The user’s browser transmits this token to the service provider.

6. The trust relationship that was established between the Service Provider and the Identity Provider during the initial configuration is used to validate the token that is received by the Service Provider.

7. The service provider allows the user access.

The new website would need to have a similar trust connection setup with the SSO solution and the authentication flow would follow the same procedures when the user tries to visit a different website.

How to implement SSO in django

How Django SSO works for multiple applications?

User → application → SSO Server → application

1. When a user logs into an application, the client sends a request with the following GET parameter, which has a redirect URL after successful login

2. Request details (application details: public key, private key, redirect URL) will be authenticated on the server

3. It returns the user request token that will be generated for the first login

4. To check user authorization, we are sending a request to the server using the request token.
The user security token will be returned upon successful authorization.If the user is not logged in, they must input their login information.

5. To verify the user access token, the client will submit a post request to the server.

6. The server provides a serialised Django User object if the user access token is legitimate.

7. Using the Django User it received from the server, the application logs the user in.

Server Side

1. Install django-simple-sso using the following command:

2. Create (public key, private key) in the server side consumer model from django admin and save it in client setting.py .

3. Add the following url patterns to base urls.py file

Client Side

1. Install django-simple-sso using the following command:

2. Add Public key, private key, server url to application settings

3. Add the following to client base urls.py:

Visits your applications http://yourapp.com:8000/client/, it’ll ask for user credentials if not logged in already. After successful login, visits other application http://yourapp.com:8001/client/, user’ll be logged in already.