Bacularis in organizations
Part 1: Authentication and access control
Bacularis is a multi-user application that provides control over how users authenticate and how they access the web interface, API hosts, and Bacula resources. In this article, we present Bacularis features related to authentication and access control, together with examples of how they can be used in an organizational environment.
These mechanisms determine who can access Bacularis and which API hosts, interface areas, and Bacula resources a user is allowed to access.
This article is intended for system administrators considering integrating Bacularis with their organization's backup infrastructure.
Key capabilities
Below are some selected features that are useful when configuring multi-user access to Bacularis.
Authentication
| Capability | Typical use |
|---|---|
| Local Bacularis users | Centrally manage users directly in the web interface |
| LDAP authentication | Use existing user accounts from an LDAP directory |
| OpenID Connect and Identity Providers | Use authentication provided by an external IAM system |
| User provisioning | Automatically create Bacularis accounts with default permissions for new users |
| MFA (Multi-Factor Authentication) with TOTP and FIDO/U2F | Strengthen authentication with software or hardware authentication methods |
Authorization and access control
| Capability | Typical use |
|---|---|
| User / identity role mapping | Use existing IAM roles and map them to roles in Bacularis |
| RBAC (Role-Based Access Control) | Assign access through custom roles and assign those roles to users |
| API host access | Give users access only to selected Bacularis API hosts |
| Access to selected Bacula resources | Allow users to access only the Bacula resources assigned to them |
| Separation of administrators and backup operators | Divide permissions according to user responsibilities |
| Monitoring-only accounts | Provide read-only access to the interface without allowing configuration changes |
Usage examples
Local users
An organization can use local Bacularis accounts without integrating Bacularis with an external identity system. In this scenario, local accounts are managed and used entirely within the Bacularis interface, without any external integration.
This is the default configuration after a new Bacularis installation. User roles, API host permissions, and access to Bacula resources can be assigned to local users and managed directly from the Bacularis web interface.
| User | Role | API hosts |
|---|---|---|
| Administrator | Admin | Main, Storage XYZ |
| Backup operator | Operator | Main |
| Regular user | Normal, JobsOnly | Host ABC |
Details: Local user documentation
LDAP authentication
An organization that already uses an LDAP directory can allow users to log in to Bacularis with their existing organizational accounts.
LDAP accounts can be imported into Bacularis. For users who do not yet have a corresponding local Bacularis account, the administrator can define the behavior: deny access, use default permissions, or automatically create an account.
Details: LDAP users documentation
OpenID Connect and SSO
Bacularis can be integrated with user authentication systems that support the OpenID Connect (OIDC) protocol. These may include IAM systems and other identity providers that support OIDC.
This allows users to sign in to Bacularis using their existing organizational identity. With Single Sign-On support, users can authenticate once and then access Bacularis together with other organizational applications configured to use the same SSO environment.
Details: SSO OIDC documentation
User provisioning
User provisioning is useful for organizations that want to provide Bacularis access to many users defined in an external identity management system. This removes the need for an administrator to create each Bacularis account manually.
When a user signs in and their Bacularis account does not yet exist, the account can be created automatically with default permissions defined by the administrator. These settings can include assignment to a Bacularis organization, selected roles, and API hosts.
The administrator can later adjust individual accounts as needed.
Details: User provisioning documentation
Multi-Factor Authentication
Bacularis supports Multi-Factor Authentication (MFA), including time-based authentication methods such as TOTP and hardware U2F security keys.
Each user with access to Bacularis can configure an additional authentication factor in their account settings using an authenticator application for TOTP or a hardware U2F key.
| MFA method | Authentication tool |
|---|---|
| TOTP | Desktop or mobile authenticator applications, such as Google Authenticator, Authy, and others |
| U2F | Hardware FIDO/U2F security keys |
Details: MFA documentation
Mapping IAM roles to Bacularis roles
IAM systems typically define different roles assigned to users. When configuring integration between such a system and Bacularis, the administrator can decide whether to use roles from the IAM system or local Bacularis roles.
When IAM roles are used, the administrator can create mappings between IAM roles and Bacularis roles. The mapping can be one-to-one or one-to-many.
This allows changes to user roles in the IAM system to be reflected in the permissions assigned to users in Bacularis.
| IAM role | Bacularis roles |
|---|---|
| Administrator | Admin |
| Manager | mgnt |
| User | normal, regular |
| Operator | op, sysop |
Details: Role mapping documentation
Role-Based Access Control
Bacularis uses roles to determine which areas of the web interface a user can access. Administrators can create roles and assign permissions to specific areas of Bacularis.
For example, a backup administrator role can provide full access to Bacula-related pages while excluding areas responsible for Bacularis configuration.
A backup storage operator role can provide access to Pools and Storage while excluding Jobs, Clients, and other areas.
For regular users, an administrator can create a role that provides access only to Bacula jobs and restore functionality.
Roles make it possible to manage access to individual areas of the interface in a flexible way. When a user is removed from a role, they lose access to the areas granted by that role. A user can have one or multiple roles assigned.
| Pages | Role | User |
|---|---|---|
| Job list, Job view | JobsOnly | john |
| Dashboard, Client list, Client view | Clients | megan |
| Pool list, Storage list | TapeOperator | bill |
Details: Role-Based Accses Control documentation
Access to selected Bacula resources
An organization may want to allow employees to restore data from their own computers.
For example, if an employee loses data by accidentally deleting a file, they can sign in to Bacularis and quickly restore a selected version of the lost file directly to their workstation.
In Bacularis, this can be configured using Bacula Console ACL resources. This means that Bacula's native access-control mechanisms determine which Bacula resources each user is allowed to access.
Users can therefore be given access to selected Jobs, Clients, Pools, Storage resources, and other Bacula resources.
| API host | Bacula resources | Account |
|---|---|---|
| Main | Job ABC, Job DEF, Client serverxx-fd | trevor |
| XYZ | Job DEF, Client serverxx-fd, FileSet BBB | sara |
| ServerB | Storage XXX, Pool YYY, Pool ZZZ | greg |
Details: Bacula resource access documentation
Monitoring-only accounts
In some organizations, certain users should have read-only access to Bacularis.
These may include operators, monitoring staff, auditors, or other users who need visibility into the backup environment without being allowed to modify Bacula configuration.
Bacularis can configure configuration access as read-only, read-write, or no access. These permissions can be defined for individual Bacula resource types, such as Pools, Jobs, or Storage, or more broadly for entire Bacula components.
This allows selected users to sign in to Bacularis and safely view or retrieve the information they need without being able to make unauthorized configuration changes.
| User | Resource | Mode |
|---|---|---|
| albert | Job, Client, Storage, Pool, FileSet, Schedule | read-only |
| frank | Job, Client | read-write |
| frank | Storage, Pool | read-only |
| frank | Schedule | no access |
Details: Resource access documentation
Access control levels summary
| Access level | Controls |
|---|---|
| Bacularis roles | Areas and functions of the web interface |
| API host access | Bacularis API hosts available to the user |
| Bacula Console ACL | Bacula resources visible to the user |
| Resource permissions | Read-only, read-write, or no configuration access |
Summary
Access control mechanisms in Bacularis operate at several levels.
An organization can choose how users authenticate, assign roles to them, limit their access to selected API hosts, and control access to specific Bacula resources.
In addition, configuration permissions can be set to read-only, read-write, or no access.
This makes it possible to adapt Bacularis access to different groups of users and different areas of responsibility within an organization.
