Differences

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

--- solution_for_authentication_authorization [2026/01/23 10:19] – Imported from DOCX sonali
+++ solution_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**.
-\\
-\\
-\\
-\\
-\\
-\\
-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
-\\
-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.
-\\
-\\
-\\
-On success, Keycloak generates a JWT access token.\\
-\\
-\\
-\\
-\\
-For every API request, React sends the JWT token in the request header:
-\\
-\\
-\\
-\\
-\\
-\\
-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.