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:49] – 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.1773031795.txt.gz · Last modified: by sonali