Overview
The Portal Self-Service Backend API implements role-based access control (RBAC) to restrict access to certain endpoints based on user roles. After JWT authentication, users are assigned roles that determine their permissions.Available Roles
The system defines three roles insrc/utils/constants/roles.js:1-5:
src/utils/constants/roles.js
Empleado de planta
Employee - Standard user with basic access to personal information and self-service features.
RRHH
Admin - Human Resources staff with elevated permissions to manage employee requests.
Administrador
Super Admin - Full system access with all administrative privileges.
Permission Groups
Permissions are organized into reusable groups defined insrc/utils/constants/roles.js:7-10:
src/utils/constants/roles.js
SOLO_ADMINS
Includes bothRRHH and Administrador roles. Used for administrative endpoints that require elevated privileges.
Use cases:
- Approving/rejecting employee requests
- Viewing all employees’ data
- Managing system-wide settings
- Accessing admin dashboards
TODOS
Includes all roles. Used when an endpoint requires authentication but no specific role. Use cases:- Endpoints accessible to all authenticated users
- General information retrieval
- Personal profile access
The verificarRol Middleware
TheverificarRol middleware enforces role-based access control on protected routes.
Implementation
Fromsrc/middleware/rolMiddleware.js:6-23:
src/middleware/rolMiddleware.js
How It Works
The
verificarRol middleware must be used after both authenticateAndExtract and cargarUsuario middlewares.Middleware Chain
Role-based access control requires a specific middleware order:authenticateAndExtract
Validates the JWT token and extracts
req.userIdentity with email and Azure ID.cargarUsuario
Queries the database using the Azure ID to load the complete user record into
req.empleado, including their role.Usage Examples
Employee Routes
Fromsrc/routes/empleadoRoutes.js:9-17:
src/routes/empleadoRoutes.js
/profile- All authenticated users can access their own profile/search- Only admins (RRHH or Administrador) can search employees/:idEmpleado- Only admins can view other employees’ profiles
Request Routes
Fromsrc/routes/solicitudRoutes.js:10-29:
src/routes/solicitudRoutes.js
GET /- All users can view their own requestsGET /admin/pendientes- Only admins can view pending requestsGET /admin/calendario- Only admins can view the admin calendarPOST /actualizacion-perfil- All users can request profile updatesPOST /crearSolicitudVacaciones- All users can create vacation requestsPUT /:id/aprobar- Only admins can approve requestsPUT /:id/rechazar- Only admins can reject requests
Communication Routes
Fromsrc/routes/comunicadoRoutes.js:11-22:
src/routes/comunicadoRoutes.js
GET /admin- Only admins can view all communications (including inactive)POST /admin- Only admins can create communicationsPUT /admin/:id- Only admins can update communicationsPUT /admin/:id/desactivar- Only admins can deactivate communicationsGET /- All users can view active communicationsGET /:id- All users can view a specific communication
Error Responses
403 - Forbidden (No Role Defined)
Returned when the user record doesn’t have a role:- User exists in Azure AD but not in the database
- User record in database is missing role assignment
cargarUsuariomiddleware failed to load the user
403 - Forbidden (Insufficient Permissions)
Returned when the user’s role doesn’t match the required permissions:- User attempting to access admin-only endpoint
- User role was changed but token wasn’t refreshed
- Incorrect role assignment in database
Implementing Custom Permissions
Define a New Permission Group
Add tosrc/utils/constants/roles.js:
src/utils/constants/roles.js
Use in Routes
Role Assignment
Roles are stored in the database and associated with user records. ThecargarUsuario middleware loads the user’s role from the database.
Typical Flow
Load User from Database
cargarUsuario queries the database using Azure Object ID to get the complete user record, including role.Best Practices
Use Permission Constants
Always use
PERMISOS constants instead of hardcoding role arrays for consistency.Principle of Least Privilege
Grant users only the minimum permissions needed for their job function.
Middleware Order Matters
Always apply middlewares in order: authenticate → load user → verify role.
Document Role Requirements
Clearly document which roles can access which endpoints in your API documentation.
Security Considerations
Role changes take effect immediately upon the next database query by
cargarUsuario. Users don’t need to re-authenticate to receive updated permissions.Troubleshooting
403 - Rol de usuario no definido
403 - Rol de usuario no definido
Possible causes:
- User exists in Azure AD but not in the database
- User record doesn’t have a role assigned
cargarUsuariomiddleware not executed
403 - Acceso denegado (even with correct role)
403 - Acceso denegado (even with correct role)
Possible causes:
- Role name in database doesn’t match
ROLESconstants - Case sensitivity mismatch
- Extra whitespace in role name
roles.js.Middleware order issues
Middleware order issues
Symptom:
req.empleado is undefined in verificarRolSolution:
Ensure cargarUsuario middleware is applied before verificarRol.Next Steps
Azure AD Setup
Configure Azure Active Directory authentication
JWT Tokens
Learn about token structure and verification