From a401be001cf5b35be404e838e4d42b3d73ca5e55 Mon Sep 17 00:00:00 2001 From: Idhibhat Pankam Date: Fri, 16 Aug 2024 15:57:25 +0700 Subject: [PATCH] a --- README.md | 25 ++++++++++++++++++++++--- 1 file changed, 22 insertions(+), 3 deletions(-) diff --git a/README.md b/README.md index 94b5899..abfa3d9 100644 --- a/README.md +++ b/README.md @@ -4,10 +4,29 @@ Single Sign-On (SSO) is a user authentication process that allows a user to access multiple applications with one set of login credentials. This is a common practice in the enterprise, where a user can log in to their computer and, with a single login, gain access to all of the applications they need to do their job. This project is a very simple implementation of SSO. -## Services involed +## Services ### CAS (Central Authentication Service) -This is the main service that handles the authentication of the user. It is responsible for generating the token and validating the token. It also has a user management system. -- TGT (Ticket Granting Ticket) +This is the main service that handles the authentication of the user and also has a user management system. In real world, this would be something like the SSO part of [Okta](https://www.okta.com) or [HENNGE One](https://hennge.com/global/henngeone) service. +#### Components +#### 1. TGT (Ticket Granting Ticket) aka Session +ds +#### 2. ST (Service Ticket) +Every time a user uses a service, if they are already logged in to SSO, they need to prove it to that service. To do so, the user is redirected to CAS to get a new ST and then redirected back to that service. The user then presents the ST to the service so that the service can send the ST back to CAS. + +#### 3. Database +The main database that stores the user information and sessions. Here are some tables: +- `users`: Stores the main user information. For this project, other services don't duplicate data from this table, so they would have to make a request to this service to get the common user information e.g. email, names. For service-specific information, they would be stored in their services' databases. +- `sessions`: Contains TGT token of each session, expiry time and payload e.g. email, user_id, roles, etc. +- `service_tickets`: Stores ST token, the session it corresponds to, the service it was issued to, user_id, and the expiry time. + +#### 4. Google OAuth +Used for Google login. You can use any other OAuth provider like Facebook, Github, etc. or even your own OAuth provider. + +### Sample Service (Consumers of CAS SSO) + +## SSO Login Flow +1. The user attempts to access a resource or application that is protected by CAS e.g. internal tools. +1. User goes to CAS to login via Google OAuth. If they started from other services, they would be redirected to CAS to do Google login. ## Setting up ### Stack