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.
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-specific configuration.
Application users are not required to exist within Bold Reports.
Architecture
User
│
▼
Identity Provider (Optional)
│
▼
Application Authentication
│
▼
Application Authorization
│
▼
Determine Tenant/User Context
│
▼
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 and user context required for report execution.
- The application generates the embed token.
- Tenant-specific and user-specific information is passed during token generation.
- Bold Reports executes and renders the report.
Passing Tenant and User Context Through Embed Tokens
Since application users are not managed within Bold Reports, the application can determine the tenant-specific and user-specific information required during report execution and pass it during embed token generation.
Depending on the application’s architecture, the contextual information may represent:
- Tenant ID
- Customer ID
- Employee ID
- Department ID
- Region
- Branch ID
- Database Name
- API Authentication Token
- Organization Code
- Business Unit
Examples:
TenantId = TENANT001
CustomerId = CUSTOMER1001
Region = North
DatabaseName = Company1DB
ApiAuthenticationToken = generated-api-token
This information can be consumed by reports, datasets, stored procedures, expressions, or API-based data sources to retrieve, filter, secure, or route data appropriately for the current user or tenant.
This approach is commonly used when:
- The application manages tenant mapping.
- The application manages authorization.
- Contextual information is maintained outside of Bold Reports.
- Each tenant has a dedicated database.
- Business rules determine how reports retrieve data.
- Custom Attributes are used to dynamically resolve runtime configuration.
Implementation Guide
Application-Managed Access is commonly used when users, permissions, tenant mapping, and business-specific configuration are maintained within the host application.
For detailed implementation guidance on generating embed tokens and passing tenant-specific or user-specific context through Custom Attributes and Report Parameters, refer to:
Embedding Reports Using Embed Tokens with Custom Attributes and Report Parameters in Bold Reports
Explains how to pass contextual information such as:
- Tenant ID
- Customer ID
- Employee ID
- Department ID
- Region
- Branch ID
- Database Name
- API Authentication Token
- Organization Code
- Business Unit
during embed token generation and consume those values during report execution.
Benefits
- No user synchronization required.
- Existing application authentication can be reused.
- Existing application authorization and RBAC implementations can be reused.
- Tenant-specific and user-specific context can be supplied dynamically during token generation.
- Supports row-level security and tenant isolation scenarios.
- Supports API authentication and API-based data source integration.
- 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.
- Tenant-specific or user-specific context must be supplied at runtime.
- Reports require dynamic filtering, row-level security, API authentication, or custom business logic.
- 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 configuration can be 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 configuration.
- The report is rendered within the application.
Embed Token Generation
Embedded reporting still requires embed token generation when using Bold Reports Managed Access.
Unlike Application-Managed Access, tenant-specific and user-specific configuration can already exist within Bold Reports. As a result, values such as Database Name, Tenant ID, Customer ID, API Authentication Token, Region, Branch ID, or other contextual information may already be configured through Site, User, or Group-level Custom Attributes and therefore may not need to be supplied during token generation.
Implementation Guide
Bold Reports Managed Access is commonly used when users, groups, permissions, and reporting security are managed directly within Bold Reports.
For detailed implementation guidance on generating embed tokens for users that already exist in Bold Reports Report Server, refer to:
Embedding Reports Using Embed Tokens for Users in Bold Reports Report Server
Explains how to:
- Generate embed tokens using Embed Secret Authentication.
- Embed reports for existing Bold Reports users.
- Embed reports for synchronized users.
- Leverage Bold Reports User Management.
- Leverage Bold Reports Group Management.
- Leverage Bold Reports Permission Management.
- Allow Bold Reports to enforce authorization during report execution.
Database Configuration Management
Tenant-specific 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 tenant-specific or user-specific information during report execution. Depending on the implementation, this information may represent Database Name, Tenant ID, Customer ID, API Authentication Token, Business Unit, Region, Branch ID, or other contextual values used by reports and datasets.
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 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.
- Tenant 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.
- Contextual information should be supplied dynamically at runtime.
- 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.
- Tenant-specific 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:
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:
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 contextual information.
- Existing authentication and authorization systems can be reused.
- Tenant-specific and user-specific 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 tenant 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.
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
Embedding Reports Using Embed Tokens with Custom Attributes and Report Parameters in Bold Reports
Explains how applications can generate embed tokens and pass tenant-specific or user-specific context such as Tenant ID, Customer ID, Employee ID, Department ID, Region, Branch ID, Database Name, API Authentication Token, Organization Code, and Business Unit through Custom Attributes and Report Parameters during report execution.
Embedding Reports Using Embed Tokens for Users in Bold Reports Report Server
Explains how applications can generate embed tokens for users that already exist in Bold Reports Report Server, allowing Bold Reports to manage users, groups, permissions, and report access.
