PC: Created page with "650px In multitenant SaaS applications, isolating data access per tenant (e.g. client, company, or organization) is crucial. This article explores how to implement client-based access control in Django, ensuring users can only access data belonging to their organization. We will walk through real-world modeling, query restrictions, permission enforcement, middleware, and role-based layering with practical examples to sec..."

2025-12-13T22:55:53Z

Created page with "650px In multitenant SaaS applications, isolating data access per tenant (e.g. client, company, or organization) is crucial. This article explores how to implement client-based access control in Django, ensuring users can only access data belonging to their organization. We will walk through real-world modeling, query restrictions, permission enforcement, middleware, and role-based layering with practical examples to sec..."

New page

[[file:Multitenant_Permissions_in_Django.jpg|650px]]

In multitenant SaaS applications, isolating data access per tenant (e.g. client, company, or organization) is crucial. This article explores how to implement client-based access control in Django, ensuring users can only access data belonging to their organization.

We will walk through real-world modeling, query restrictions, permission enforcement, middleware, and role-based layering with practical examples to secure your SaaS platform.

Use Case: SaaS with Multiple Clients
Imagine a platform where companies (clients) sign up, and each company has multiple users. These users should only access data owned by their respective companies.
Example:
* Company A and Company B both use your SaaS.
* A user from Company A should not see Company B’s resources, even if they share the same resource type.
Multitenancy in Django can be achieved in two major ways:
* Shared Database with Discriminator Field (e.g. client_id) — simpler and widely used.
* Separate schemas or databases per tenant — more isolation is used in advanced setups.
This article focuses on the shared database pattern for its simplicity and ease of maintenance.
Core Concepts
* Tenant Isolation Every model must be scoped by a foreign key to Client, which serves as the tenant identifier. This prevents cross-client data leakage.
* Request Context Awareness Every request is associated with an authenticated user, and all data access should be scoped to request.user.client.
* Role-Based Access Permissions can be fine-tuned by assigning roles within a tenant, e.g. Admin, Manager, Staff. Roles determine the scope of access within the tenant’s data.
* Security-First Validation Do not rely on frontend submissions for client IDs. Enforce permissions and data ownership at the backend.
* Scalability through Middleware and Reusability Encapsulate tenant extraction logic in middleware, and permission logic in reusable classes.
Step-by-Step Implementation

1. Define the Models
At the core of a multitenant system is the relationship between Client, User, and domain models such as Project, Invoice, Report, etc.
<pre>
class Client(models.Model):
name = models.CharField(max_length=255)
created_at = models.DateTimeField(auto_now_add=True)

class User(AbstractUser):
client = models.ForeignKey(Client, on_delete=models.CASCADE)
role = models.CharField(
max_length=20,
choices=[('admin', 'Admin'), ('manager', 'Manager'), ('staff', 'Staff')],
default='staff'
)

class Project(models.Model):
client = models.ForeignKey(Client, on_delete=models.CASCADE)
name = models.CharField(max_length=255)
owner = models.ForeignKey(User, on_delete=models.CASCADE)
created_at = models.DateTimeField(auto_now_add=True)
</pre>

Add client to every critical model to tie them to their owner organization.

2. Use Custom Permissions
Start by creating a basic permission class that ensures the object being accessed belongs to the same client as the requesting user.
<pre>
from rest_framework.permissions import BasePermission

class IsSameClient(BasePermission):
def has_object_permission(self, request, view, obj):
return hasattr(obj, 'client') and obj.client == request.user.client
</pre>

Apply this permission class to views or override the queryset in viewsets to restrict access:
<pre>
class ProjectViewSet(viewsets.ModelViewSet):
serializer_class = ProjectSerializer
permission_classes = [IsAuthenticated, IsSameClient]

def get_queryset(self):
return Project.objects.filter(client=self.request.user.client)

def perform_create(self, serializer):
serializer.save(client=self.request.user.client, owner=self.request.user)
</pre>

3. Admin and Role Logic
Use roles to control privilege within the same tenant.
<pre>
class UserRole(models.TextChoices):
ADMIN = 'admin', 'Admin'
MANAGER = 'manager', 'Manager'
STAFF = 'staff', 'Staff'

class User(AbstractUser):
client = models.ForeignKey(Client, on_delete=models.CASCADE)
role = models.CharField(max_length=20, choices=UserRole.choices, default=UserRole.STAFF)
</pre>

Create a compound permission class:
<pre>
class IsClientAdminOrOwner(BasePermission):
def has_object_permission(self, request, view, obj):
return (
obj.client == request.user.client and (
request.user.role == UserRole.ADMIN or
obj.owner == request.user
)
)
</pre>

Use role checks in serializers to allow certain fields to be modified only by admins:
<pre>
class ProjectSerializer(serializers.ModelSerializer):
class Meta:
model = Project
fields = ['id', 'name', 'owner', 'created_at']
read_only_fields = ['owner']

def validate(self, attrs):
if self.context['request'].user.role != UserRole.ADMIN:
raise serializers.ValidationError("Only admins can create projects.")
return super().validate(attrs)
</pre>

Middleware for Tenant Access
For large applications, separating out the logic to determine tenant context improves code clarity.
<pre>
class ClientMiddleware:
def __init__(self, get_response):
self.get_response = get_response

def __call__(self, request):
if request.user.is_authenticated:
request.tenant = request.user.client
return self.get_response(request)
</pre>

Serializers: Injecting Context
Avoid exposing client in the serializer:
<pre>
class ProjectSerializer(serializers.ModelSerializer):
class Meta:
model = Project
fields = ['id', 'name', 'created_at']

def create(self, validated_data):
validated_data['client'] = self.context['request'].user.client
validated_data['owner'] = self.context['request'].user
return super().create(validated_data)
</pre>

Best Practices
* Never trust user-submitted client_id — always derive it from the authenticated user.
* Centralize permission logic — avoid duplicating access checks across views.
* Write shared mixins and base viewsets to encapsulate multitenant behavior.
* Document your permission model for better team collaboration.
Common Mistakes
* ❌ Forgetting to filter queryset by client.
* ❌ Accepting client_id in POST bodies.
* ❌ Missing role-based logic where needed (e.g. staff modifying others’ resources).
* ❌ Not testing cross-tenant access violations.
Testing Access Control
Example test cases:
<pre>
def test_user_cannot_access_others_project(api_client, user_a, project_b):
api_client.force_authenticate(user=user_a)
response = api_client.get(f'/api/projects/{project_b.id}/')
assert response.status_code == 404

def test_admin_can_create_project(api_client, admin_user):
api_client.force_authenticate(user=admin_user)
data = {'name': 'New Project'}
response = api_client.post('/api/projects/', data)
assert response.status_code == 201
</pre>

Also, consider integration tests using tenant fixtures.
Multitenant permission management in Django ensures strong data isolation and secure access control across client organizations. Implementing it correctly requires:
* Consistent tenant-scoping of all data models
* Permission classes that validate client ownership
* Role-based access is layered on top of tenant logic
* Middleware and reusable patterns to reduce repetition
* Strong testing to verify proper isolation
With these patterns, you can confidently scale your SaaS platform across multiple clients while maintaining privacy, security, and compliance.

Read the full article here: https://medium.com/django-unleashed/multitenant-permissions-in-django-client-based-access-control-3af2fec01ebb

Multitenant Permissions in Django: Client-Based Access Control - Revision history