Multi-Tenant Access Control and Resource Management in Bold Reports
When implementing a multi-tenant reporting solution, organizations often need to control which tenants a user can access.
A user may:
- Access a single tenant.
- Access multiple tenants.
- Access all tenants.
- Switch between tenants within the application.
This article explains common approaches for managing tenant access and resource visibility in Bold Reports for both embedded and portal-based deployments.
Related Articles
Multi-Tenant Database Connectivity Using Custom Attributes
Explains how tenant-specific databases can be selected dynamically.
Multi-Tenant Content Organization in Bold Reports
Explains how tenant content can be organized using Sites or Categories.
https://support.boldreports.com/kb/article/24858/multi-tenant-content-organization-in-bold-reports
Embedded Multi-Tenant User Management in Bold Reports
Explains Application-Managed Access and Bold Reports Managed Access.
Automating Multi-Tenant Management Using Bold Reports REST APIs
Explains how Sites, Categories, Users, Groups, and Attributes can be managed programmatically.
Understanding Tenant Access
In a typical SaaS application, users may belong to one or more tenants.
Example:
User A
└── Company1
User B
├── Company1
└── Company2
User C
├── Company1
├── Company2
└── Company3
The application determines which tenants a user can access.
Bold Reports is then used to expose the reporting resources associated with the selected tenant.
Separating Application Access and Reporting Resources
It is important to separate application authorization from reporting resource organization.
Application Responsibilities
The application typically determines:
- Authentication
- Authorization
- Tenant assignments
- Which tenants a user can access
- Tenant switching
- Create permissions
- Edit permissions
- Delete permissions
- Business-specific security rules
Example:
User B
├── Company1
└── Company2
The application determines this relationship and controls what the user is allowed to access.
For embedded SaaS applications, create, edit, update, and delete permissions are typically controlled by the application. The application decides which operations a user can perform within a tenant and exposes the appropriate reporting functionality accordingly.
Bold Reports Responsibilities
Bold Reports is typically responsible for organizing and exposing reporting resources such as:
- Sites
- Categories
- Reports
- Data Sources
- Shared Resources
This allows tenant reporting resources to remain isolated while the application continues to manage user authorization.
Option 1: One Site per Tenant
In this architecture, each tenant is provisioned in a separate site.
Site: Company1
Site: Company2
Site: Company3
How Access Works
When a user selects a tenant:
User
│
▼
Application
│
▼
Company1 Selected
│
▼
Company1 Site
The application routes the user to the corresponding tenant site.
Only resources within that site are available.
Benefits
- Strong tenant isolation.
- Separate administration.
- Separate report catalogs.
- Independent tenant environments.
- Simplified tenant separation.
Best Fit
- Strong isolation requirements.
- Tenant-specific administrators.
- Independent tenant environments.
- Site-level customization requirements.
Option 2: Single Site with Categories
In this architecture, all tenants are maintained within a single site.
Master Site
│
├── Company1
│ └── Reports
│
├── Company2
│ └── Reports
│
└── Company3
└── Reports
How Access Works
When a user selects a tenant:
User
│
▼
Application
│
▼
Company1 Selected
│
▼
Company1 Category
The application determines the active tenant and displays the appropriate reporting resources.
Benefits
- Centralized administration.
- Easier onboarding.
- Reduced content duplication.
- Shared reporting infrastructure.
- Scales well for large SaaS deployments.
Best Fit
- Large tenant counts.
- Centralized administration.
- Shared reporting infrastructure.
- Common report designs across tenants.
Users with Access to Multiple Tenants
A user may have access to multiple tenants.
Example:
User B
├── Company1
└── Company2
In this scenario:
- The application determines the available tenants.
- The user selects a tenant.
- The application applies the selected tenant context.
- Reporting resources associated with that tenant are displayed.
Example:
Available Companies
✓ Company1
✓ Company2
Current Selection:
Company1
The user can switch between available tenants without requiring separate accounts.
Tenant Context in Embedded Reporting
For embedded reporting deployments, the application typically remains the source of truth for tenant access.
Example:
User A
├── Company1
└── Company2
When the user signs in:
- The application determines the tenants available to the user.
- The user selects the tenant they want to work with.
- The application applies the selected tenant context.
- The application generates the embed token.
- Bold Reports renders the resources associated with the selected tenant.
One Site per Tenant
User
│
▼
Application
│
▼
Select Company1
│
▼
Generate Embed Token
│
▼
Company1 Site
The application selects the appropriate site before rendering reports.
Single Site with Categories
User
│
▼
Application
│
▼
Select Company1
│
▼
Generate Embed Token
│
▼
Company1 Category
The application remains within the same site while exposing resources associated with the selected tenant category.
For implementation details on embed token generation, refer to:
Generate Embed Token Using Embed Secret and Pass User Context to Reports
Typical SaaS Architecture
A common architecture is:
Application
│
├── Authentication
├── Authorization
├── User Management
├── Tenant Assignment
└── Tenant Switching
Bold Reports
│
├── Sites or Categories
├── Reports
├── Data Sources
└── Reporting Resources
In this model:
- The application remains the source of truth for users.
- The application determines tenant access.
- Users may access one or more tenants.
- Bold Reports exposes tenant-specific reporting resources.
- Tenant reporting content remains logically isolated.
