1. Integration Guide - Introduction
Info
Before continuing with the reference integration guide we recommend going through the documentation in the following order:
This integration guide demonstrates a reference integration of the PyPermission RBAC library in an exemplary backend service layer for a fictive "MeetDown" SaaS application.
The MeetDown application showcases a simplified version of a community event organizing platform where users can join groups and manage events. It illustrates both a theoretical foundation for designing an RBAC system for a SaaS platform like "meetup" and a practical walkthrough of how these concepts are implemented in the accompanying backend Python code.
Features
The MeetDown application structures its features into three core services, each encapsulating a distinct domain of functionality. These services are designed to reflect the underlying data model while also emphasizing the functionality on a feature basis. The following table describes the core service domains:
| Domain | Description |
|---|---|
User |
Represents individual User accounts within the platform. |
Group |
Represents community spaces managed by Users. Groups act as containers for members and events. |
Event |
Represents scheduled activities within a Group. |
RBAC Roles
The following Roles are defined in the RBAC system:
| Role | Description |
|---|---|
guest |
Represents unauthenticated Users (not logged in). Guests can only view public content. |
user |
Authenticated Users who can participate in Groups and Events and manage their own account. |
moderator |
Moderators can manage Users, Groups and Events. They can not participate like normal User. |
admin |
Admins can create, modify, and delete any resource. |
RBAC Policies
The following subsections describe which Roles have access to which service functions, including any potential conditions (not to be confused with ABAC), and therefore also indicate which abstract features each Role is permitted to access.
User service
The following table outlines the Policies for managing User profiles, including email and state updates. Only admins can fully modify or delete a User resource, while the Role moderator and user may update only their own profile.
| Actions | guest | user | moderator | admin |
|---|---|---|---|---|
create() |
✓ | ✓ | ||
get() |
✓ | ✓ | ✓ | |
list() |
✓ | ✓ | ✓ | |
set_username() |
✓ (on own profile) | ✓ (except for other moderator or admin Members) |
✓ | |
set_state() |
✓ (on own profile) | ✓ (except for other moderator or admin Members) |
✓ | |
delete() |
✓ |
Group service
The following table outlines the Policies for Group resources. Authenticated Users are allowed to create and manage their communities. Group owners have full control over Group settings, while moderators can assist in managing content and state.
| Actions | guest | user | moderator | admin |
|---|---|---|---|---|
create() |
✓ | ✓ | ||
get() |
✓ | ✓ | ✓ | ✓ |
list() |
✓ | ✓ | ✓ | ✓ |
set_title() |
✓ (if group owner) | ✓ | ||
set_state() |
✓ (if group owner) | ✓ | ✓ | |
delete() |
✓ (if group owner) | ✓ |
Event service
The following table outlines the Policies for Event resources. Events are managed within Groups and follow access rules similar to Groups. Only owners or admins can make changes to Events, with moderators having additional moderation privileges.
| Actions | guest | user | moderator | admin |
|---|---|---|---|---|
create() |
✓ (if group owner) | ✓ | ||
get() |
✓ | ✓ | ✓ | ✓ |
list() |
✓ | ✓ | ✓ | ✓ |
set_title() |
✓ (if group owner) | ✓ | ||
set_state() |
✓ (if group owner) | ✓ | ✓ | |
delete() |
✓ (if group owner) | ✓ |
This was the first part of the integration guide, which covered which features the fictitious MeetDown application provides and how these are divided into the corresponding service functions, as well as which User Group has access to which functionality.
In the second part, we continue with how to implement these requirements in an RBAC system and specifically - which Roles and Permissions are explicitly required. Continue...