Role-Based Access Control & Security

Relevant source files

The following files were used as context for generating this wiki page:

• src/App.tsx
• src/components/OptimizedProtectedRoute.tsx
• src/components/EnhancedRoleBasedDashboard.tsx
• supabase/migrations/20250827131610_01b0a8e4-bdc6-4561-a1be-1f6ddff22f8b.sql
• supabase/migrations/20251211200310_83416cf1-7905-4d2a-b5ea-36c2b29d32b8.sql
• supabase/migrations/20251207072505_f3695a16-ad4e-4c78-b1b2-8691e95e95cc.sql
• supabase/migrations/20260116004859_97400f69-288b-44fa-a287-77800aa15d05.sql
• DEPLOYMENT_GUIDE.md

The Role-Based Access Control (RBAC) and Security system in this project provides a multi-layered defense architecture. It ensures that users—including Admins, Vendors, Property Managers, and Tenants—can only access resources and perform actions appropriate to their assigned roles. This is achieved through a combination of frontend route protection, backend Row Level Security (RLS) policies, and database-level security functions.

The scope of this system covers authentication verification, role-based authorization for UI components, and strict data isolation at the database layer. Backend security hardening includes performance-indexed RLS policies and tenant-aware security functions to prevent unauthorized data exposure.
Sources: DEPLOYMENT_GUIDE.md:12-21, supabase/migrations/20250827131610_01b0a8e4-bdc6-4561-a1be-1f6ddff22f8b.sql:5-10

User Roles and Permissions

The system defines four primary roles, each with distinct access levels and dashboard metrics.

Role	Description	Access Level
Admin	Full platform administration	Global visibility, user management, system settings, and security monitoring.
Property Manager	Real estate operations	Property management, tenant oversight, and RFQ creation.
Vendor	Service providers	Bid submission, project management, and payout settings.
Tenant	Property residents	Maintenance requests, rent payments, and lease documentation.

Sources: src/components/EnhancedRoleBasedDashboard.tsx:64-88, src/components/auth/AuthHeroSection.tsx:11-55, src/App.tsx:135-180

Frontend Security Architecture

Frontend security is managed through higher-order components and optimized providers that enforce role requirements before rendering views.

Protected Routing

The OptimizedProtectedRoute component acts as the primary gatekeeper for the application's routes. It checks the user's authentication state and matches their assigned role against the requiredRole prop defined in the routing configuration.

Role-Based UI Elements

Components like EnhancedRoleBasedDashboard dynamically adjust their content based on the user.role property from the authentication context. This includes switching metric palettes, action buttons, and navigation links.
Sources: src/components/EnhancedRoleBasedDashboard.tsx:61-90

Backend Security Hardening

The database layer utilizes Supabase's PostgreSQL engine to enforce security through Functions and Row Level Security (RLS).

Security Definer Functions

Several helper functions are created with the SECURITY DEFINER attribute. This allows them to run with the privileges of the function creator (owner) rather than the current user, enabling secure checks against restricted tables like user_roles.

• is_admin_user(user_uuid): Checks if a specific user possesses the 'admin' role.
• user_has_role(user_uuid, role_name): Validates if a user has a specific role assigned.
• is_staff_or_admin(): A stable check for users holding either 'admin' or 'property_manager' roles.
• is_tenant_admin(user_uuid, tenant_id): (Referenced in logic) Validates administrative rights within a specific tenant context.

Sources: supabase/migrations/20250825194017_116127d8-7afa-40cc-84c9-f3c83c8d2351.sql:4-16, supabase/migrations/20260116004859_97400f69-288b-44fa-a287-77800aa15d05.sql:5-18

Row Level Security (RLS) Policies

RLS policies are strictly applied to all sensitive tables. Policies are generally categorized into "Own Access" (users seeing their own data), "Staff/Admin Access" (global management), and "Restricted Public Access" (masked data for the marketplace).

RLS Enforcement Examples

Table	Policy Name	Logic
profiles	users_view_own_profile	auth.uid() = id
vendor_profiles	authenticated_view_vendor_basic_info	auth.role() = 'authenticated'
bid_scores	bid_scores_select_staff	is_admin_user(auth.uid()) OR EXISTS property_manager role
vendor_payout_settings	vendor_payout_settings_select_own	vendor_id IN user's vendor record OR is_admin_user

Sources: supabase/migrations/20250827131610_01b0a8e4-bdc6-4561-a1be-1f6ddff22f8b.sql:15-54, supabase/migrations/20251211200310_83416cf1-7905-4d2a-b5ea-36c2b29d32b8.sql:28-50, supabase/migrations/20251214014738_aa958a0d-1930-4e55-a78f-fe9134b736dc.sql:85-95

Multi-Tenant Isolation

The system implements multi-tenant context to ensure data isolation between different property management organizations. Security functions and audit logs are "tenant-aware," checking for tenant_id matches during access attempts.

Performance Optimization

Security hardening is balanced with performance through targeted indexing. RLS policies often cause performance bottlenecks if the columns used in USING clauses are not indexed.

Security-Critical Indexes

To prevent RLS slowdowns, the following composite and single-column indexes are implemented:

• idx_user_roles_user_id_role: Optimized for role verification.
• idx_profiles_id_role: Speeds up profile and role lookups.
• idx_vendor_profiles_user_id_verified: Facilitates marketplace queries.
• idx_realtime_messages_topic: Optimized for secure chat/messaging.

Sources: supabase/migrations/20250827131610_01b0a8e4-bdc6-4561-a1be-1f6ddff22f8b.sql:63-70, scripts/verify_deployment.sql:13-30

Conclusion

The Role-Based Access Control & Security module ensures a secure environment for all property management stakeholders. By combining frontend route guards with backend RLS policies and tenant-aware security functions, the platform maintains strict data integrity and privacy. Continuous auditing and performance indexing ensure these security measures remain efficient as the system scales.