wiki

User Tools

Site Tools

Trace:
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/03/09 04:52] – sonalisolution_for_authentication_authorization [2026/03/09 05:33] (current) – sonali
Line 1: Line 1:
-[[ldap_keycloak_details|LDAP vs Keycloak Details]]+[[:ldap_vs_keycloak|LDAP vs Keycloak Details]]
  
-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.+[[:send_email_through_keyclock|Send Email]]
  
-**Entity Management Tool – LDAP vs Keycloak** +[[Authentication:send_sms|SMS OTP Login Using Exotel]]
-===== 1. LDAP ===== +
- +
-==== 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 +
- +
-{ +
-<code> +
- +
-"roles": ["ROLE_SPOC"], +
- +
-</code> +
- +
-<code> +
-"permissions": ["CREATE_BOOKING",”VIEW_BOOKING”] +
- +
-</code> +
- +
-} +
- +
-Example: Employee Token +
- +
-{ +
- +
-<code> +
-"roles": ["ROLE_EMPLOYEE"], +
- +
-</code> +
- +
-<code> +
-"permissions": ["CREATE_BOOKING"] +
- +
-</code> +
- +
-} +
- +
-Then our system will check if there is an option create booking then show create booking option. +
- +
-if (userHasPermission('CREATE_BOOKING')) { +
- +
-<code> +
-  showCreateBookingButton(); +
- +
-</code> +
- +
-} +
- +
-**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.1773031955.txt.gz · Last modified: by sonali