Embedded Multi-Tenant User Management in Bold Reports
When implementing embedded reporting in a multi-tenant application, one of the most important architectural decisions is determining where user accounts, permissions, and access control should be managed.
Most embedded applications already have an established authentication and authorization system. As a result, organizations must decide whether:
- Users and permissions should remain managed within the application.
- Users should be synchronized and managed within Bold Reports.
This article explains the two common user management approaches available for embedded reporting and helps you determine which model best fits your architecture.
Related Articles
Multi-Tenant Database Connectivity Using Custom Attributes
Explains how tenant-specific database connectivity and configuration can be managed using Custom Attributes.
Multi-Tenant Content Organization in Bold Reports
Explains how tenant-specific content can be organized using either a One Site per Tenant approach or a Single Master Site with Categories.
https://support.boldreports.com/kb/article/24858/multi-tenant-content-organization-in-bold-reports
Quick Comparison
| Capability | Application-Managed Access | Bold Reports Managed Access |
|---|---|---|
| Embedded Reporting | ✅ | ✅ |
| Application as Source of Truth | ✅ | ❌ |
| User Synchronization Required | ❌ | ✅ |
| Bold Reports User Management | ❌ | ✅ |
| Bold Reports Group Management | ❌ | ✅ |
| Bold Reports Permission Management | ❌ | ✅ |
| Direct Portal Access | ❌ | ✅ |
| Existing Application RBAC Reuse | ✅ | ⚠️ |
| Multi-Tenant SaaS Applications | ✅ | ✅ |
| Large User Base | ✅ | ✅ |
| Authentication Token-Based Embedding | ✅ | ✅ |
Understanding Embedded Access Control
In embedded reporting solutions, there are two separate responsibilities that should be considered.
Authentication
Authentication determines who the user is.
Common examples include:
- Microsoft Entra ID
- Active Directory
- Okta
- Auth0
- Keycloak
- Custom Identity Providers
Authorization
Authorization determines:
- Which reports users can access.
- Which reporting resources users can access.
- Which actions users can perform.
The primary architectural decision is determining where authorization should be managed.
Option 1: Application-Managed Access
In this model, the application remains the source of truth for authentication, authorization, user management, and tenant database selection.
Application users are not required to exist within Bold Reports.
Architecture
User
│
▼
Identity Provider (Optional)
│
▼
Application Authentication
│
▼
Application Authorization
│
▼
Determine Tenant Database
│
▼
Generate Embed Token
│
▼
Bold Reports
│
▼
Embedded Report
How It Works
- Users authenticate to the application.
- The application validates the user’s identity.
- The application evaluates roles, permissions, and business rules.
- The application determines which reports the user can access.
- The application determines the tenant database to be used.
- The application generates the embed token.
- The database information is passed during token generation.
- Bold Reports executes and renders the report.
Passing Database Information Through Embed Tokens
Since application users are not managed within Bold Reports, the application can determine which tenant database should be used and pass the database information during token generation.
Example:
DatabaseName = Company1DB
This approach is commonly used when:
- The application manages tenant mapping.
- Each tenant has a dedicated database.
- Database selection is determined by application business logic.
- Custom Attributes are used to dynamically resolve the target database.
For implementation details, refer to:
Generate Embed Token Using Embed Secret and Pass User Context to Reports
For database configuration using Custom Attributes, refer to:
Multi-Tenant Database Connectivity Using Custom Attributes
Benefits
- No user synchronization required.
- Existing application authentication can be reused.
- Existing application authorization and RBAC implementations can be reused.
- Database information can be dynamically supplied during token generation.
- Reduced administrative overhead.
- Application remains the source of truth.
- Ideal for SaaS and customer-facing applications.
- Scales efficiently for large user populations.
Best Fit For
Choose Application-Managed Access when:
- Reports are accessed exclusively through embedding.
- The application already manages users and permissions.
- Existing authorization logic should be reused.
- You operate a multi-tenant SaaS platform.
- Each tenant has its own database.
- The application should remain the primary source of truth for security decisions.
Option 2: Bold Reports Managed Access
In this model, users are synchronized or created within Bold Reports, and reporting permissions are managed directly through Bold Reports.
Architecture
User
│
▼
Identity Provider (Optional)
│
▼
Application Authentication
│
▼
Generate Embed Token
│
▼
Bold Reports
│
├── Bold Reports Users
├── Bold Reports Groups
└── Bold Reports Permissions
│
▼
Embedded Report
How It Works
- Users are imported or created within Bold Reports.
- Users can be assigned to Bold Reports Groups.
- Permissions are managed through Bold Reports.
- Tenant-specific database configuration is maintained through Site, User, or Group-level Custom Attributes.
- Users authenticate through the application.
- The application generates an embed token for the authenticated Bold Reports user.
- Bold Reports evaluates the configured users, groups, and permissions.
- Bold Reports resolves the required database configuration.
- The report is rendered within the application.
Embed Token Generation
Embedded reporting still requires embed token generation when using Bold Reports Managed Access.
For implementation details, refer to:
Generate Embed Token Using Embed Secret
Unlike Application-Managed Access, the tenant database configuration can already exist within Bold Reports. As a result, the database name typically does not need to be passed during token generation.
Database Configuration Management
Tenant-specific database configuration can be maintained directly within Bold Reports.
Example:
Company1 User/Group/Site
└── DatabaseName = Company1DB
Company2 User/Group/Site
└── DatabaseName = Company2DB
Because the configuration already exists within Bold Reports, Bold Reports can resolve the required database information during report execution.
For more information, refer to:
Multi-Tenant Database Connectivity Using Custom Attributes
Benefits
- Bold Reports User Management.
- Bold Reports Group Management.
- Bold Reports Permission Management.
- Centralized reporting administration.
- Group-based permission management.
- Direct portal access support.
- Tenant database configuration can be maintained within Bold Reports.
- Supports both embedded reporting and direct portal access.
User Synchronization
Users can be synchronized from external identity providers such as:
- Microsoft Entra ID
- Active Directory
- SAML-based Identity Providers
Once synchronized, users and groups can be managed through Bold Reports and used for report-level access control.
Best Fit For
Choose Bold Reports Managed Access when:
- Users require direct access to the Bold Reports portal.
- Reporting administrators manage permissions within Bold Reports.
- Users and groups should be maintained within Bold Reports.
- Database configuration should be managed within Bold Reports.
- A unified permission model is preferred for both embedded and portal access.
Choosing the Right Approach
Use Application-Managed Access When
- Your application already manages authentication and authorization.
- Existing RBAC should be reused.
- Reports are accessed exclusively through embedding.
- You operate a multi-tenant SaaS platform.
- Database selection should be driven by application business logic.
- Bold Reports is primarily used for report execution and rendering.
Use Bold Reports Managed Access When
- Users require direct access to the Bold Reports portal.
- Reporting administrators manage permissions within Bold Reports.
- Bold Reports User Management should be used.
- Bold Reports Group Management should be used.
- Bold Reports Permission Management should be used.
- Users are synchronized from an external identity provider.
- Database configuration should be maintained within Bold Reports.
- A unified permission model is preferred for both embedded and portal access.
Relationship with Other Multi-Tenant Architectures
User management is only one aspect of a multi-tenant reporting architecture.
A complete multi-tenant implementation typically includes the following architectural decisions.
Content Organization
Determines:
- How reports are organized.
- How tenants are separated.
- Whether Sites or Categories are used.
For more information, refer to:
Multi-Tenant Content Organization in Bold Reports
https://support.boldreports.com/kb/article/24858/multi-tenant-content-organization-in-bold-reports
Tenant Configuration and Database Connectivity
Determines:
- How tenant-specific database connections are managed.
- How tenant configuration is maintained.
- How shared reports connect to tenant-specific databases.
For more information, refer to:
Multi-Tenant Database Connectivity Using Custom Attributes
These architectural decisions are independent and can be combined based on your application’s requirements.
Recommendation
For most embedded multi-tenant SaaS applications, we recommend Application-Managed Access.
In this model:
- The application remains the source of truth for users, roles, permissions, and database selection.
- Existing authentication and authorization systems can be reused.
- Database information can be supplied dynamically during embed token generation.
- Bold Reports focuses on report execution and rendering.
Bold Reports Managed Access is recommended when organizations want Bold Reports to manage users, groups, permissions, and database configuration while supporting both embedded reporting and direct portal access.
By selecting the approach that aligns with your architecture, you can implement a scalable multi-tenant embedded reporting solution while maintaining a clear separation between application security, tenant management, and reporting functionality.
