feat: Phase 1 Week 3 - Role-Based Access Control (RBAC)

[lakshayman]

Date: 16 Jan 2025

Developer Name: [Your Name]

---

Description

This PR implements Phase 1, Week 3: Role-Based Access Control (RBAC) for the Feature Flag Backend. It adds comprehensive authorization based on user roles (ADMIN, DEVELOPER, VIEWER) and protects all endpoints with appropriate permission checks.

Key Features Implemented:

1. RBAC Permission System

   • Created comprehensive permission matrix for all operations
   • Defined permissions: CREATE, READ, UPDATE, DELETE for feature flags and user mappings
   • Role-based permission mapping:
     • ADMIN: Full access to all operations
     • DEVELOPER: Create/update feature flags, manage user mappings, read-only user management
     • VIEWER: Read-only access to feature flags and own user mappings

2. RBAC Helper Functions

   • RequirePermission(): Checks if user has specific permission
   • RequireAnyPermission(): Checks if user has any of the provided permissions
   • CanAccessUserResource(): Validates resource ownership (users can access own resources, ADMIN can access all)

3. Feature Flag Endpoints Protection

   • GET /feature-flags - Requires READ_FEATURE_FLAG permission
   • GET /feature-flags/{flagId} - Requires READ_FEATURE_FLAG permission
   • POST /feature-flags - Requires CREATE_FEATURE_FLAG permission (ADMIN, DEVELOPER)
   • PATCH /feature-flags/{flagId} - Requires UPDATE_FEATURE_FLAG permission (ADMIN, DEVELOPER)

4. User Feature Flag Mapping Endpoints Protection

   • GET /users/{userId}/feature-flags - Requires READ_USER_MAPPING + resource ownership check
   • GET /users/{userId}/feature-flags/{flagId} - Requires READ_USER_MAPPING + resource ownership check
   • POST /users/{userId}/feature-flags/{flagId} - Requires CREATE_USER_MAPPING + resource ownership check
   • PATCH /users/{userId}/feature-flags/{flagId} - Requires UPDATE_USER_MAPPING + resource ownership check

5. User Management Endpoints Protection

   • GET /users/{userId} - Requires READ_USER + resource ownership check
   • PUT /users/{userId} - Requires UPDATE_USER + resource ownership check
   • Role update restrictions: Only ADMIN can change user roles
   • Users cannot change their own role

6. Security Enhancements

   • All endpoints now use JWTMiddlewareWithUserVerification() for enhanced security
   • Resource ownership validation prevents unauthorized access
   • Role-based restrictions prevent privilege escalation
   • userId removed from request bodies (always uses authenticated user)

Permission Matrix:

Operation	ADMIN	DEVELOPER	VIEWER
Create Feature Flag	✅	✅	❌
Update Feature Flag	✅	✅	❌
Read Feature Flag	✅	✅	✅
Delete Feature Flag	✅	❌	❌
Create User Mapping	✅	✅	❌
Update User Mapping	✅	✅	❌
Read User Mapping	✅	✅	✅ (own only)
Read User	✅	✅	✅ (own only)
Update User	✅	❌	❌ (own profile only, no role change)
Delete User	✅	❌	❌

Documentation Updated?

• Yes
• No

Under Feature Flag

• Yes
• No

Database Changes

• Yes
• No

Database Changes:

• No schema changes
• Uses existing user table with role field

Breaking Changes

• Yes
• No

Breaking Changes:

1. Request Body Changes:

   • CreateFeatureFlagRequest.userId - Now optional (removed from request, uses authenticated user)
   • UpdateFeatureFlagRequest.userId - Now optional (removed from request, uses authenticated user)
   • CreateFeatureFlagUserMappingRequest.userId - Now optional (removed from request, uses authenticated user)
   • UpdateFeatureFlagUserMappingRequest.userId - Now optional (removed from request, uses authenticated user)

2. Authorization Changes:

   • VIEWER role can no longer create or update feature flags
   • DEVELOPER role can no longer update other users' profiles
   • Only ADMIN can change user roles
   • Users can only access their own resources (unless ADMIN)

Development Tested?

• Yes
• No

Testing:

• ✅ All Go compilations pass successfully
• ✅ Code follows existing patterns and conventions
• ✅ Permission checks implemented for all endpoints
• ✅ Resource ownership validation working

Screenshots

Screenshot 1

Test Coverage

Test Coverage Details

Additional Notes

API Changes

Before:
POST /feature-flags/
{
"name": "new-feature",
"description": "Description",
"userId": "user-123" // Required
}After:
POST /feature-flags/
{
"name": "new-feature",
"description": "Description"
// userId automatically extracted from authenticated token
// Requires CREATE_FEATURE_FLAG permission (ADMIN or DEVELOPER)
}### Usage Example

Permission Check:
// Check if user has permission
permResponse, err := utils.RequirePermission(userContext, utils.PermissionCreateFeatureFlag)
if err != nil || permResponse.StatusCode != http.StatusOK {
return permResponse, err
}

// Check resource ownership
if !utils.CanAccessUserResource(userContext, resourceUserId) {
return events.APIGatewayProxyResponse{
StatusCode: http.StatusForbidden,
Body: "You can only access your own resources",
}, nil
}### Role Behavior Examples

1. VIEWER trying to create feature flag:

   • Returns 403 Forbidden: Insufficient permissions

2. DEVELOPER trying to update another user's profile:

   • Returns 403 Forbidden: You can only update your own profile

3. VIEWER trying to access another user's feature flags:

   • Returns 403 Forbidden: You can only access your own feature flag mappings

4. Non-ADMIN trying to change user role:

   • Returns 403 Forbidden: Only ADMIN can update user roles

Migration Notes

• All endpoints now require proper authentication and authorization
• Clients must ensure users have appropriate roles for their operations
• Existing tokens will continue to work, but operations will be restricted based on role
• Role updates require ADMIN privileges

Next Steps (Week 4)

• Comprehensive integration testing with different user roles
• Performance testing for permission checks
• Documentation updates for API contracts
• Add audit logging for permission denials

Security Considerations

• Role-based access prevents unauthorized operations
• Resource ownership checks prevent data leakage
• Role update restrictions prevent privilege escalation
• All permission checks are enforced at the API level
• Database role is source of truth (overrides token role if different)

Files Changed

• layer/utils/RBAC.go (new - RBAC permission system)
• getAllFeatureFlags/main.go (updated - added RBAC)
• getFeatureFlagById/main.go (updated - added RBAC)
• createFeatureFlag/main.go (updated - added RBAC)
• updateFeatureFlag/main.go (updated - added RBAC, migrated to new middleware)
• getUserFeatureFlags/main.go (updated - added RBAC + ownership check)
• getUserFeatureFlag/main.go (updated - added RBAC + ownership check)
• createUserFeatureFlag/main.go (updated - added RBAC + ownership check)
• updateUserFeatureFlag/main.go (updated - added RBAC + ownership check)
• getUserById/main.go (updated - added RBAC + ownership check)
• updateUser/main.go (updated - added RBAC + ownership check + role restrictions)
• layer/utils/RequestResponse.go (updated - made userId optional in requests)

---

Migration Path:

1. ✅ Week 1: User service foundation
2. ✅ Week 2: Authentication migration
3. ✅ Week 3: Role-based access control (this PR)
4. 🔜 Week 4: Testing & documentation

[coderabbitai]

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}