User Tools

Site Tools


solution_for_authentication_authorization

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
solution_for_authentication_authorization [2026/01/23 12:25] – Imported from DOCX sonalisolution_for_authentication_authorization [2026/03/09 05:33] (current) sonali
Line 1: Line 1:
-LDAP only verifies users, but it is not sufficient for modern security requirements. Keycloak is a complete open-source SSO solution that can integrate with LDAP and provides secure APIs through JWT tokens.+[[:ldap_vs_keycloak|LDAP vs Keycloak Details]]
  
-**Entity Management Tool – LDAP vs Keycloak**+[[:send_email_through_keyclock|Send Email]]
  
-===== 1. LDAP =====+[[Authentication:send_sms|SMS OTP Login Using Exotel]]
  
-==== Best for ==== 
- 
-Internal company logins 
- 
-Simple username/password authentication 
- 
-==== What LDAP does (Simple terms) ==== 
- 
-LDAP (Lightweight Directory Access Protocol) is a **central user directory** 
- 
-It only verifies **username and password** 
- 
-It tells the application **YES / NO** (valid user or not) 
- 
-==== How LDAP login works ==== 
- 
-User enters username & password 
- 
-Application sends credentials to LDAP 
- 
-LDAP verifies user 
- 
-LDAP returns YES / NO 
- 
-Application creates its own session 
- 
-==== Limitations of LDAP ==== 
- 
-No social login 
- 
-No JWT / access tokens 
- 
-No Single Sign-On (SSO) 
- 
-Hard to manage roles & permissions dynamically 
- 
-Old technology 
- 
-Weak for modern APIs and mobile applications 
- 
-Not provide any public api for authentication or user management 
- 
-===== 2. Keycloak ===== 
- 
-==== What is Keycloak? ==== 
- 
-Keycloak is an **open‑source identity and access management server** developed by **Red Hat**.Keycloak is OpenID Connect–based. 
- 
-==== Main responsibilities ==== 
- 
-User login 
- 
-Roles & permissions management 
- 
-JWT token generation 
- 
-Single Sign-On (SSO) 
- 
-==== How Keycloak works ==== 
- 
-Application → redirects to Keycloak → user logs in → application receives JWT token 
- 
-We can customize the Keycloak login page using our own theme. We can also manage users through the Keycloak admin interface or by calling Keycloak APIs from our system. 
- 
-==== Key benefits ==== 
- 
-Language independent (works with any backend) 
- 
-Open-source 
- 
-GUI‑based role & user management 
- 
-No role & permission stored in application DB 
- 
-No role & permission hardcoded in code 
- 
-SSO ready 
- 
-Highly scalable 
- 
-Provide public apis. 
- 
-===== Public APIs ===== 
- 
-===== Authentication ===== 
- 
-Login API 
- 
-Token generation 
- 
-Token validation 
- 
-==== User Management ==== 
- 
-Create user 
- 
-Assign role 
- 
-Update user 
- 
-Disable user 
- 
-===== 3. Keycloak Login Flow ===== 
- 
-User clicks Login on application 
- 
-User is redirected to Keycloak login page 
- 
-User enters credentials 
- 
-Keycloak verifies user 
- 
-Keycloak generates JWT token 
- 
-User is logged into the application 
- 
-===== 4. Keycloak with LDAP Integration ===== 
- 
-==== Keycloak works with LDAP. ==== 
- 
-==== Flow ==== 
- 
-User data stored in **LDAP** 
- 
-Login handled by **Keycloak** 
- 
-Keycloak validates user from LDAP 
- 
-Keycloak issues **JWT token** to application 
- 
-==== Advantages ==== 
- 
-No user database in application 
- 
-No passwords stored in application 
- 
-Centralized authentication & authorization 
- 
-But for Keyclock we need to install a keyclock in our server & need to run on another port. 
- 
-We can install under Same domain 
- 
-Step : install → run → connect with PHP 
- 
-**User & Role Hierarchy – Keycloak Integration** 
- 
-**Keycloak can fully support our existing role and permission structure without any limitation.** 
- 
-==== Existing Roles in Current System ==== 
- 
-Our application currently has the following user roles, each with different permissions: 
- 
-Super Admin 
- 
-Our Agents 
- 
-Admin 
- 
-SPOC 
- 
-Approver 
- 
-Employee 
- 
-**How Roles Will Be Managed in Keycloak** 
- 
-Each existing role will be created in Keycloak as a **Realm Role**: 
- 
-ROLE_SUPER_ADMIN 
- 
-ROLE_TAXIVAXI_AGENTS 
- 
-ROLE_ADMIN 
- 
-ROLE_SPOC 
- 
-ROLE_APPROVER 
- 
-ROLE_EMPLOYEE 
- 
-Each user will be assigned **one main role** based on their type. 
- 
-**How Permissions Will Be Managed** 
- 
-Permissions (what a user can do) will be managed separately using **Client Roles**. 
- 
-Create booking 
- 
-View booking 
- 
-Approve booking 
- 
-View invoices 
- 
-Access admin panel 
- 
-View reports 
- 
-This allows flexibility without changing application code. 
- 
-Role & Permission mapping 
- 
-==== Roles and Permissions ==== 
- 
-**SPOC** 
- 
-CREATE_BOOKING 
- 
-\\  
- 
-**EMPLOYEE** 
- 
-CREATE_BOOKING 
- 
-===== JWT Token After Login ===== 
- 
-After successful login, the system receives a **JWT token** from Keycloak containing the user’s roles and permissions. 
- 
-Example: SPOC Token 
- 
-{ 
- 
-  "roles": ["ROLE_SPOC"], 
- 
-  "permissions": ["CREATE_BOOKING",”VIEW_BOOKING”] 
- 
- 
- 
-Example: Employee Token 
- 
-{ 
- 
-  "roles": ["ROLE_EMPLOYEE"], 
- 
-  "permissions": ["CREATE_BOOKING"] 
- 
-} 
- 
-Then our system will check if there is an option create booking then show create booking option. 
- 
-if (userHasPermission('CREATE_BOOKING')) { 
- 
-    showCreateBookingButton(); 
- 
-} 
- 
-**If One user has multiple roles:** 
- 
-So **permissions should depend on the selected role at login time**, not on all roles together. 
- 
-How it works 
- 
-User logs in 
- 
-The system asks: “Login as which role?” 
- 
-Approver 
- 
-Employee 
- 
-SPOC 
- 
-User selects one role 
- 
-Keycloak issues JWT token **only with permissions of the selected role** 
- 
-Application uses that token 
- 
-**Authentication & Authorization for Microservices** 
- 
-**Keycloak fits very well for microservices.Keycloak acts as a central authentication & authorization server.** 
- 
-User logs in via Keycloak 
- 
-Keycloak verifies credentials 
- 
-Keycloak issues JWT token 
- 
-Token is sent with every API request 
- 
-**Each microservice:** 
- 
-**Reads permissions from JWT** 
- 
-**Allows or denies access** 
- 
-**Keycloak with Multiple Microservices** 
- 
-One login for all services (SSO) 
- 
-Same token works across services 
- 
-No duplicate user DBs 
- 
-**Operational Complexity (Learning & Adoption Effort)** 
- 
-**For developer** 
- 
-Basic Keycloak concepts (Realm, Client, Roles) 
- 
-JWT token structure 
- 
-Token validation in services 
- 
-==== For Operations / Admin Team ==== 
- 
-GUI-based user & role management 
- 
-==== Initial Setup (One-time) ==== 
- 
-Keycloak installation 
- 
-LDAP / DB integration 
- 
-Role & permission setup 
- 
-Token configuration 
- 
-**End-to-End Authentication & Authorization Flow** 
- 
-User authentication and token generation are handled by Keycloak, token validation is done at the gateway, and each backend service authorizes requests by checking permissions from the JWT token 
- 
-**Flow** 
- 
-User opens the application and initiates login.\\ React application redirects the user to Keycloak for authentication. 
- 
-**Keycloak (Login + Token)** 
- 
-User enters credentials. 
- 
-Keycloak verifies the user (via DB / LDAP). 
- 
-On success, Keycloak generates a JWT access token.\\  
- 
-**React UI (Receives JWT)** 
- 
-React receives the JWT token. 
- 
-\\  
- 
-**React UI → API Call** 
- 
-For every API request, React sends the JWT token in the request header: 
- 
-**API Gateway (Token Validation)** 
- 
-Gateway intercepts the request. 
- 
-Validates the JWT token: 
- 
-If the token is invalid → request is rejected. 
- 
-\\  
- 
-**Node Microservice (Permission Check)** 
- 
-Backend service reads roles/permissions from the JWT payload. 
- 
-Checks whether the user has the required permission for the API. 
- 
-If permission is missing → access denied (403). 
- 
-\\  
- 
-**Response** 
- 
-Node microservice sends the response back to the client through the gateway. 
- 
-React UI displays the result to the user. 
  
solution_for_authentication_authorization.1769171156.txt.gz · Last modified: by sonali