Authentication via OpenID Connect/OAuth2.0 and Single Sign-On
BWeb supports delegated authentication by integrating with third-party software that implements the OpenID Connect (OIDC) protocol, which is based on the OAuth 2.0 protocol. When users attempt to access BWeb, they are redirected to an external identity provider (referred to here as the IdP) to verify their identity and permissions.
With this integration, user accounts are managed entirely within the IdP. Roles defined in BWeb can be associated with users via the IdP and are transmitted to BWeb through HTTP headers. BWeb interprets these headers to authorize or deny access to specific actions based on the user’s assigned roles.
Based on this IdP integration, BWeb offers a Single Sign-On experience. Once a user has authenticated with the IdP, they do not need to log in again when accessing BWeb. Many IdP providers services allow BWeb to be listed as an application in their dashboards, enabling users to access it with a single click after logging in to any other application connected to the same IdP.
The following sections describe the underlying technologies and explain how to install and configure this authentication mechanism. While the examples use Okta (https://www.okta.com/) and Microsoft Entra ID (https://www.microsoft.com/en-us/security/business/identity-access/microsoft-entra-id) as example Identity Providers, the same principles apply to other OIDC-compliant providers, with minor configuration adjustments.
Introduction to Identity (Access) Managers and Identity Providers
An identity provider (IdP) focuses on managing user identities, authentication, and basic access, while an identity manager (IM) or identity and access management (IAM) system encompasses the broader process of managing identities, access, and permissions within an organization. IdPs are a core component of IAM, often serving as the foundation of an organization’s identity management infrastructure.
Identity Provider (IdP)
IdPs create, store, and manage user identities, as well as handle the authentication process (verifying user credentials). IdPs typically focus on managing user accounts and verifying their identity. Some examples of IdPs are Single Sign-On (SSO) providers and directory services.
IdPs are often considered part of an overall IAM framework, but they usually do not handle the full scope of access management aspects.
Identity Manager (IM)/Identity and Access Management (IAM)
IAM systems encompass a broader set of practices for managing user identities and access rights, including authentication, authorization, and access control. IAM manages the entire lifecycle of user identities, from provisioning to decommissioning, and ensures appropriate access to resources. For instance, this includes software solutions that manage user accounts, access policies, and permissions.
IAM systems leverage IdPs for authentication and core identity management, while also providing additional features for managing access and permissions.
Introduction to OAuth2.0 Protocol
OAuth 2.0 is an industry-standard authorization protocol that enables third-party applications to obtain limited access to user resources without exposing user credentials. It is widely adopted for securing APIs and facilitating delegated access in modern web applications.
When integrating a BWeb instance with OAuth 2.0, you leverage a robust framework that allows users to authorize the application to act on their behalf — typically through a secure login flow, using existing credentials from a trusted identity provider (such as Google, Microsoft, GitHub, Okta, etc.). That identity provider can then manage complex permission structures, groups, different multi-factor authentication techniques and many other advantages.
Core Concepts
Resource Owner: The user who authorizes access to their resources. In this context, the Bacula Enterprise instance administrator.
Client: The application requesting access. In this case, BWeb.
Authorization Server: Issues tokens after authenticating the resource owner. This is the identity provider to integrate with.
Resource Server: Hosts the user resources and validates access tokens. This is also typically the identity provider, but this and the previous function could be also provided separately.
Access Token: A short-lived credential used by the client to access protected resources.
Refresh Token (optional): A long-lived token used to obtain new access tokens without re-authenticating the user.
Common Grant Types
Authorization Code Grant: The most common type for web applications. It involves user authentication and a secure server-to-server token exchange.
Client Credentials Grant: Used for machine-to-machine authentication where no user is involved.
Implicit Grant (deprecated): A simplified flow for browser-based apps, now discouraged in favor of more secure alternatives.
Device Authorization Grant: Used for input-constrained devices (e.g., smart TVs).
BWeb OpenID/OAuth2.0 integration utilizes Authorization Code Grant.
Introduction to the OpenID Connect (OIDC) Protocol
OpenID Connect (OIDC) is an identity layer built on top of the OAuth 2.0 protocol. While OAuth 2.0 is primarily designed for authorization — granting applications access to user resources — OpenID Connect extends it to support authentication, enabling clients to verify the identity of the end user.
In other words, OAuth 2.0 answers the question:
“Is this app allowed to access a specific resource?”
Whereas OpenID Connect answers:
“Who is the user currently using the application?”
How OIDC Works
OpenID Connect uses the same OAuth 2.0 flows (most commonly the Authorization Code Flow) and adds a new type of token: the ID Token. This token is a JSON Web Token (JWT) that contains information about the authenticated user (also known as claims), such as a unique identifier, name, and email address.
The client application receives both:
An access token (used to access APIs and resources), and
An ID token (used to establish the user’s identity).
Some key components added by OIDC are:
ID Token: A JWT containing user identity claims.
UserInfo Endpoint: An API provided by the identity provider to retrieve additional user profile information.
Standard Claims: Such as sub (subject), name, email, etc.
Discovery Document: A
.well-known/openid-configurationendpoint for automatic configuration.
OIDC allows a web tool not only to authorize users, but also to log them in securely through a trusted third-party identity provider. This eliminates the need to manage passwords internally and simplifies identity management, especially when integrating with providers such as Okta, Auth0, Google, or Microsoft Entra ID among others.
For detailed information, see the official OpenID Connect specification: https://openid.net/specs/openid-connect-core-1_0.html
Introduction to Single Sign-On
Single Sign-On (SSO) is an authentication process that allows users to access multiple independent applications with a single set of credentials. With SSO, users authenticate once with a centralized identity provider (IdP) and can then seamlessly access all connected systems without re-entering credentials.
This approach simplifies user experience, reduces password fatigue, and strengthens security by centralizing access control and auditability.
Modern SSO implementations are typically built on top of OAuth 2.0 and OpenID Connect (OIDC):
OAuth 2.0 provides the foundation for authorization, granting applications (clients) access to user resources without exposing user credentials.
OpenID Connect (OIDC) extends OAuth 2.0 to support authentication, verifying the identity of the user and enabling SSO capabilities.
In an SSO flow using OIDC:
A user attempts to access Application A and is redirected to the identity provider.
After a successful login, the IdP issues an ID Token (for user identity) and an Access Token (for resource access).
The user can then access Application B without logging in again, as it trusts the same IdP and recognizes the user session or token.
Some benefits of SSO are:
Convenience: One login gives access to multiple services.
Security: Centralized authentication reduces attack surfaces and improves control.
Consistency: Unified identity management across applications.
Scalability: New applications can be integrated easily with minimal overhead.
Common identity providers include Okta, Microsoft Entra ID, Auth0 or Keycloak.
SSO is particularly well suited for organizations with multiple applications, internal tools, or microservices that need to share a common authentication context. It is especially useful in enterprise environments, customer-facing portals, and SaaS ecosystems - in any of them BWeb can be part of the mix of applications integrated behind the same identity provider.
Architecture
To provide integration with OIDC, BWeb leverages the open-source tool OAuth2-Proxy. More information and possible extra parameters that may be needed for other non-tested providers can be found on the project website: https://oauth2-proxy.github.io/oauth2-proxy/
OAuth2-Proxy is deployed in front of BWeb to manage all the OIDC/OAuth2.0 flow. Only authorized requests are forwarded to BWeb.
The request flow involving an identity provider is illustrated in the following diagram:
By default, the installation scripts deploy BWeb only internally in 127.0.0.1:9180, while
OAuth2-Proxy is put at the front of the web service and is served at 0.0.0.0:443. These settings
can be manually adjusted after the initial deployment within the different configuration files of
the associated services.
Example Connection Flow
When a user logs into BWeb via a third-party identity provider, the following sequence occurs:
BWeb redirects the user to the provider’s authorization endpoint.
The user logs in.
The provider redirects the user back to BWeb with an authorization code.
BWeb exchanges the code for an access token.
The token is used to access protected BWeb resources on behalf of the user.
For full details, see the OAuth 2.0 specification (RFC 6749).
Scope
This module is designed to support any OIDC/OAuth2.0 based provider, although it has only been tested with Okta and Microsoft Entra ID.
The module is intended to work on any supported Linux distribution, however it has only been tested with Ubuntu and AlmaLinux platforms so far.
Requirements
Before proceeding with the installation, it is necessary to define the proper configuration in the desired IdP. At the networking level, this IdP needs to be accessible from BWeb.
In general, a user with sufficient privileges needs to:
Deploy an application in the IdP representing BWeb. This application contains parameters such as the redirect URI pointing to the location of BWeb.
Have the users intended to access BWeb defined in the IdP.
Define the BWeb Admin Role in the IdP (by default, this is
Bacula Admins).Define any other role that is intended to be used in the IdP with the proper prefix (for instance:
bacula_r_viewer).Associate users with the application in the IdP (directly per user, or through other roles).
An example configuration using Okta is provided below.
Disclaimer
A large part of the configuration for this type of integrations is done in the IdP. Identity providers - especially those offering full IAM services, such as Okta - support many features that are outside the scope of this document and could impact the final configuration and present some difference to the basic approach presented here. Also, other providers may use different terminology or structures of the concepts discussed here.
Okta Configuration
The steps to configure Okta are described below.
Application
The first step is to create an application in Okta that represents BWeb.
An administrator user accesses the Okta web interface: https://login.okta.com/
Create a new application with:
Sign-in method: ODIC - OpenID Connect
Application type: Web Application
Next, in the “New App Integration” form:
App integration name: Bacula Enterprise (or BWeb, or any other desired value)
Grant type: Authorization Code
Sing-in redirect URIs:
https://[bweb.ip.or.hostname]/oauth2/callbackSign-out redirect URIs:
https://[bweb.ip.or.hostname]Login initiated by: Either Okta or App
Login flow: Redirect to app to initiate login (OIDC Compliant)
Initiate login URI:
[bweb.ip.or.hostname]
The variable [bweb.ip.or.hostname] must be the ip or hostname normally be used to access BWeb.
At this stage, you may select “Skip group assignment for now”, as group assignment will be configured in a later step.
Once finished, a configuration screen will be displayed. Record the following values, as they will be required later when configuring BWeb:
Client ID
Client Secret ((available via the copy-to-clipboard button)
Sign-in redirect URI we provided earlier
Domain URL, typically visible in the URL or close to our username in the top-right corner (xxxx.okta.com)
Access Group
Second step is to associate users with the newly created BWeb application. While this can be done individually (per user), it is strongly recommended to use a group.
After creating the group (for example, named “Bacula”), associate it with the BWeb application, and then assign the desired users to the group.
Authorization Server
The final step is to configure the API authorization server correctly. Navigate to Security > API options, where a list of authorization servers is displayed. For the basic setup, edit the “default” authorization server by double-clicking on it:
Two elements must be ensured:
Adding the groups claim to the Access Token,
Having an active policy allowing the usage of this authorization server for the intended users.
The groups claim needs to be added from the Claims tab, as shown below:
The goal is to have an entry as the one shown here. To do so, click “Add claim” and configure it with the following values:
Name: group
Include in token type: Access Token | Always
Filter: Matches regex | .*
Include in: Any Scope
Click Save and it should be displayed on the list.
Next step is the access policies tab. An active default policy containing a rule allowing access is needed, as shown below:
If the policy does not exist or is not applicable to our client (Okta application), we need to create it with the button ‘Add New Access Policy’:
Name: Bacula Enterprise Access Policy
Description: Allow access from Bacula Enterprise application
Assign to: We can choose ‘All clients’ or ‘The following clients’ and select the application we created in some steps before
If the selected policy does not contain a rule applicable to this application, add one:
Within the rule, ensure that “Authorization Code” and “Any scopes” are selected. The remaining settings can be left at their defaults or adjusted according to your organization’s security requirements.
Once everything is configured in the authorization server, it is recommended to check the token in the “Token Preview” tab. The generated token should resemble the example shown below and must include the groups claim:
Microsoft Entra ID Configuration
The steps to configure Microsoft Entra ID are described below.
Application
First step is to create an application in Microsoft Entra ID (from the Azure Cloud Portal) representing BWeb.
An administrator user accesses the Azure Portal web interface: https://portal.azure.com/auth/login/
Create a new application from:
Microsoft Entra ID > Manage > App registrations > New Registration
Introduce a name such as BWeb, Bacula Enterprise, or similar.
Set the supported account types. Typically this should be “Accounts in this organizational directory only”.
Under Redirect URI:
Select: Web
Introduce:
https://[bweb.ip.or.hostname]/oauth2/callback
Once the application is created, open it and navigate to Manage > Certificates & Secrets:
Click “New client secret”
Then, you should see the new secret listed as shown below:
Store this value safely, as it will be needed later when installing/configuring BWeb
as client_secret.
Next, add the
groupsclaim to the token of our app. Go to Manage > Token configuration.Click “Add groups claim” and select “Directory roles” (selecting “Security” is optional):
Click “Save” and the claim should appear in the list:
Finally, go to Manage > Overview to view all the values required for configuring BWeb:
You will need:
Application client ID ->
client_idDirectory (tenant ID) -> used to build
oidc_issuer_urlandoauth2_logout_url
Access Group
The second step is to associate the users are to access BWeb with the application you just created.
You can create the group under Microsoft Entra ID > Manage > Groups.
Then, associate the group with the users are to be Bacula administrators. This can be done either by editing each user or by adding members to the group from the group configuration.
A user who is a member of the group should see it listed, as shown below:
Groups and Permissions
It is possible to define different levels of permissions for authorized users. This sections describes the available options.
Admin Group
For users who are to be administrators, define another group. By default, this
group is named “Bacula Admins”, but it can be adjusted later in the BWeb internal
configuration (or in the /opt/bweb/etc/bweb.conf file).
BWeb Permissions Groups
For any other more granular control for permissions:
Create the BWeb group in Okta as a new group, using a prefix in front of it. By default, the prefix is
bacula_. An example would be:bacula_r_view_jobAssociate these groups with the users who are to have those permissions.
BWeb Console Groups
In addition to BWeb roles, it is possible to associate specific Consoles in Bacula where granular permissions based on Bacula ACL are defined. To do that, the first requirement is to define the proper Console resources with the desired set of ACLs using BWeb. In the configuration page:
define the Console resource for the Director: Configuration > Director > Consoles
define the associated Console acting as the other end of the Console communication: Configuration > Console.
Once the consoles are created and named, modify the Console connection command used by BWeb to connect to the Director. In the BWeb configuration page, modify the BConsole entry as follows:
/opt/bacula/bin/bconsole -n -c /opt/bacula/etc/bconsole-%u.conf
Then, in your IdP, define the associated groups using the same prefix discussed in the previous
point (bacula_ by default) and another fixed prefix: console_.
Example: If we have a console named operator (/opt/bacula/etc/bconsole-operator.conf),
we would need to define a group in the IdP with the name bacula_console_operator.
Any user associated with that role and logging in into BWeb will use that Console and all the defined ACLs in the Director Console resource will be applied.
BWeb Internal Group Matching
Different providers may return group information differently in an OAuth 2.0/OIDC context.
Some providers return group names (e.g., Okta), while others return group IDs instead of group names (e.g., Microsoft Entra ID).
For providers that return group IDs, you must create an additional file representing the
association between each ID and each BWeb group. This must be done in the reserver
path: /opt/bweb/etc/bweb_external_roles.json. The contents must be JSON compliant as the
following example shows:
# cat /opt/bweb/etc/bweb_external_roles.json
{
"aaaaaaaa-1111-2222-bbbb-333333333333" : "Bacula Admins",
"zzzzzzzz-yyyy-wwww-0000-111111111111" : "r_view_job",
"bbbbbbbb-yyyy-cccc-0000-222222222222" : "r_config"
}
As shown above, it is not mandatory to define all available BWeb roles. However, you musy define
at least the “Bacula Admins” one (or the name that we put as default_admin_role during the
installation) and any other represented role in the IdP should be defined.
Installation
This section explains how to install and configure the oauth2-proxy module for BWeb in two
different situations:
In a new installation, where BWeb is deployed directly enabling OIDC/OAuth2.0 authentication,
In an existing installation, where the OIDC/OAuth 2.0 module is installed and configured separately.
New BWeb Deployment
New BWeb deployments should use Bacula Installation Manager and include the OAuth2.0 configuration.
When running BIM and trying to install the Bacula Director and BWeb, BIM asks all the questions to configure OIDC/OAuth2.0 properly. However, there is also an alternative approach that can be more convenient when entering complex values: using a pre-created configuration file.
This configuration file must be placed in: /opt/bweb/etc/oauth2_proxy_install.conf
You can create it by copying and modifying one of the templates provided by BWeb package
(e.g., oauth2_proxy_install.conf.okta.template or oauth2_proxy_install.conf.entraid.template).
These templates are located in the ``/opt/bweb/etc``folder.
Note that those files are distributed as part of the BWeb package. If you are installing BWeb for the first time and do not yet have the package contents available locally, you may need to download the BWeb package and extract the templates manually before proceeding.
After extracting them:
Move and rename the file to:
/opt/bweb/etc/oauth2_proxy_install.confFill it with your configuration values.
Example contents:
# Public-facing address or hostname where we will serve the final service (which is oauth2-proxy->Bweb) address=your.hostname.or.ip # Provider kind # If Okta: oidc # If Microsoft Entra ID: entra-id # There are more options, but not tested oauth2_provider=oidc # Address from the provider that will manage the OIDC/OAuth2.0 process # Okta example oidc_issuer_url=https://my-env.okta.com/oauth2/default # Logout URL that will be called automatically by OAuth2-Proxy just after logging-out from the BWeb button oauth2_logout_url=https://my-env.okta.com/login/signout # Client ID of the App registered in the Identity Provider client_id=0loijnmuy3478dnfPj609 # Associated secret client_secret=a3c3_tloijnm87yhdb2349dbP6tcJaer090cjfpes_A9g1-dDu7qrCIAD0398 # Default group name or id that will represent a BWeb admin. For the first access, an admin user must login # If you use Entra ID and just want to use the admin role, here you could put the admin group UUID default_admin_role="Bacula Admins" # Configure the firewall automatically, so enabling HTTPS/443 configure_firewall=y # Restart BWeb and OIDC/OAuth2.0 after the configuration restart_services=y
Pay close attention to the values of oidc_issuer_url and oauth2_logout_url:
In Okta:
https://[your.okta.domain]/oauth2/defaultandhttps://[your.okta.domain]/login/signoutMS Entra ID:
https://login.microsoftonline.com/your-tenant-id/v2.0andhttps://login.microsoftonline.com/your-tenant-id/oauth2/logout
The other values for client_id and client_secret are obtained from the previous configuration sections.
After the configuration file is in place, you can run BIM regularly, as follows:
============================================================ Welcome to Bacula Enterprise Installation Manager 2024.12.13 ============================================================ This script will assist you during Bacula Enterprise installation Ubuntu 24.04.2 LTS detected [noble-64]. Press ENTER to start =============================================== Installation of Director and associated plugins =============================================== Proceed with Installation of Director and associated plugins? [Y/n] Using Download Area Code [xxxxxxxxxxx] Would you like to use this one again? [Y/n] .... =============================================== Installation of Director and associated plugins =============================================== Proceed with Installation of Director and associated plugins? [Y/n] Using Download Area Code [xxxxxxxxxxxxx] Would you like to use this one again? [Y/n] Available versions found on your Download Area for your current operating system [noble-64]: --------------------------------------------------------------------------------------------- 1 : 16.0.16 2 : 18.0.8 3 : 18.2.0 --------------------------------------------------------------------------------------------- Please, select the version of your Bacula Director ('18.2.0' by default) : 2 [====================] 100.0% totp-dir (not installed) The Bacula Director and Storage deamon will be installed or upgraded by default. The following plugins available for the Director can be installed at version 18.0.8 : --------------------------------------------------------------------------------------- 1 : bguardian 2 : bweb 3 : callhome-dir 4 : totp-dir --------------------------------------------------------------------------------------- Select the number(s) of the plugins you want to install, separated by commas. Leave empty and just press <Enter> to skip plugin selection : 2 Please, enter the BWeb password for the "admin" account: Please, enter the same password once again: Install and setup OIDC/OAuth2 with BWeb? [y/N] y ... go: downloading go.opentelemetry.io/auto/sdk v1.1.0 Go and OAuth2 Proxy are installed now ===================================================== Please answer the following questions to configure properly OAuth2 and BWeb: address set from config: 192.168.1.102 oidc_issuer_url set from config: https://xxxxxxx.okta.com/oauth2/default oauth2_logout_url set from config: https://xxxxxxx.okta.com/login/signout client_id set from config: 9ijkn83klpr09iY87yd7 client_secret set from config: ik0987hypuzTu9DFzVpEQMM038djn763hgv6i-90i7oknsBxDpl987gbhBpfm3QI configure_firewall set from config: y restart_services set from config: y Generating secure cookie_secret... cookie_secret generated. ===================================================== Saving configuration to /opt/bweb/etc/oauth2-proxy.cfg... Configuration saved. ===================================================== Configuring firewall to allow HTTPS traffic... Configuring UFW to allow port 443... Rules updated Rules updated (v6) Firewall configured. ===================================================== Creating systemd service at /etc/systemd/system/oauth2-proxy.service... Systemd service created. ===================================================== Creating symlink to OAuth2 Proxy binary... Symlink created. ===================================================== Modifying /opt/bweb/etc/httpd.conf... Added server.bind line: server.bind = "127.0.0.1" Commented out: auth.backend = "htpasswd" Commented out: auth.backend.htpasswd.userfile = "/opt/bweb/etc/htpasswd.bweb" Commented out: auth.require = ( "/" => Commented out: ( Commented out: "method" => "basic", Commented out: "realm" => "Password protected area", Commented out: "require" => "valid-user" Commented out: ) Commented out: ) httpd.conf modification complete. ===================================================== Modifying /opt/bweb/etc/bweb.conf... ===================================================== Restarting services... Created symlink /etc/systemd/system/multi-user.target.wants/oauth2-proxy.service → /etc/systemd/system/oauth2-proxy.service. Services restarted. ===================================================== OAuth2 Proxy installation and configuration complete. Congratulations!! You can access to BWeb now from https://192.168.1.102 ===================================================== Success. ... Installation of Director Successfully completed =============================================== If you wish to use the Bacula CLI, please type "sudo -u bacula /opt/bacula/bin/bconsole" BWeb has been installed. It can be accessed on https://your.hostname or https://<Bweb's IP or FQDN> =============================================== The following ports have been opened: [9101, 9103, 9180] Installation Manager. Done. ===========================
Existing BWeb Deployment
For existing BWeb deployments, you must run the specific oauth2-proxy deployment script that
BWeb incorporates in the path: /opt/bweb/bin/install_oauth2_proxy.sh.
Before running the script, it is recommended to configure the installation by creating
the following file: /opt/bweb/etc/oauth2_proxy_install.conf.
This file can be created by copying and modifying one of the templates that are provided by
BWeb (e.g., oauth2_proxy_install.conf.okta.template or oauth2_proxy_install.conf.entraid.template).
These template files are located in the ``/opt/bweb/etc``folder.
Example contents:
# Public-facing address or hostname where we will serve the final service (which is oauth2-proxy->Bweb) address=your.hostname.or.ip # Provider kind # If Okta: oidc # If Microsoft Entra ID: entra-id # There are more options, but not tested oauth2_provider=oidc # Address from the provider that will manage the OIDC/OAuth2.0 process # Okta example oidc_issuer_url=https://my-env.okta.com/oauth2/default # Logout URL that will be called automatically by OAuth2-Proxy just after logging-out from the BWeb button oauth2_logout_url=https://my-env.okta.com/login/signout # Client ID of the App registered in the Identity Provider client_id=0loijnmuy3478dnfPj609 # Associated secret client_secret=a3c3_tloijnm87yhdb2349dbP6tcJaer090cjfpes_A9g1-dDu7qrCIAD0398 # Default group name or id that will represent a BWeb admin. For the first access, an admin user must login # If you use Entra ID and just want to use the admin role, here you could put the admin group UUID default_admin_role="Bacula Admins" # Configure the firewall automatically, so enabling HTTPS/443 configure_firewall=y # Restart BWeb and OIDC/OAuth2.0 after the configuration restart_services=y
Pay close attention to the values of oidc_issuer_url and oauth2_logout_url:
Okta:
https://[your.okta.domain]/oauth2/defaultandhttps://[your.okta.domain]/login/signoutMS Entra ID:
https://login.microsoftonline.com/your-tenant-id/v2.0andhttps://login.microsoftonline.com/your-tenant-id/oauth2/logout
The other values for client_id and client_secret are obtained from the previous configuration sections.
Once this is done, the root user can run the installation script and have it deployed in an unattended mode:
root@jubu:/opt/bweb/bin# bash install_oauth2_proxy.sh ===================== BWeb OIDC/OAuth2 deployment script ================== ===================================================== Welcome to the BWeb OIDC/OAuth2 deployment script ===================================================== Installing Go and OAuth2 Proxy... ... Go and OAuth2 Proxy are installed now ===================================================== Please answer the following questions to configure properly OAuth2 and BWeb: address set from config: 192.168.1.136 oidc_issuer_url set from config: https://dev-24198306.okta.com/oauth2/default oauth2_logout_url set from config: https://dev-24198306.okta.com/login/signout client_id set from config: 0oaoqr389frDSgY5m5d7 client_secret set from config: q0kTfgZqpuzTu9DFzVpEQMM9s8KHOE5xTcUGi-BdL7gYssBxD9umVaHh1Bpfm3QI configure_firewall set from config: y restart_services set from config: y Generating secure cookie_secret... cookie_secret generated. ===================================================== Saving configuration to /opt/bweb/etc/oauth2-proxy.cfg... Configuration saved. ===================================================== Configuring firewall to allow HTTPS traffic... Configuring UFW to allow port 443... Skipping adding existing rule Skipping adding existing rule (v6) Firewall configured. ===================================================== Creating systemd service at /etc/systemd/system/oauth2-proxy.service... Systemd service created. ===================================================== Creating symlink to OAuth2 Proxy binary... Symlink created. ===================================================== Modifying /opt/bweb/etc/httpd.conf... Updated existing server.bind line to: server.bind = "127.0.0.1" httpd.conf modification complete. ===================================================== Modifying /opt/bweb/etc/bweb.conf... ===================================================== Restarting services... Services restarted. ===================================================== OAuth2 Proxy installation and configuration complete. Congratulations!! You can access to BWeb now from https://192.168.1.136 and use your Identity Provider users to authenticate on it =====================================================
If the configuration file is not created, the installation script will ask questions for each of the configuration values, so they are introduced manually.
Additional Configurations
The technology behind BWeb OIDC/OAuth2.0 integration is highly flexible and other providers, customizations or setups are possible. The setup exposed here should serve for most cases, but further adjustments are possible manually modifying the main configuration files of the implied services, which are:
BWeb Configuration: It can be modified directly from the Web Interface under BWeb Configuration section. Particularly, the sign-out URL and group-mapping configuration can be adjusted here.
Web server configuration:
/opt/bweb/etc/httpd.conf.OAuth2-proxy configuration:
/opt/bweb/etc/oauth2-proxy.cfg(the file is commented to help with further changes).Roles IDs association:
/opt/bweb/etc/bweb_external_roles.json(described in the BWeb Internal Group Matching section).
The range of possible customizations is broad. For example, you may change the port of the service, provide different certificates, configure a different timeout for the cookie, personalize log behavior and location, an others.
Usage
Once the integration is deployed, accessing the BWeb application will redirect the user to the external IdP login page:
After entering valid user credentials, the user is automatically redirected to the BWeb application. If additional authentication factors are configured - as recommended - they will be requested at this stage:
Once logged in, the User Info page displays information from the user info page. The comment section shows the groups associated with the user:
Note that when the identity provider (e.g., Microsoft Entra ID) returns group IDs instead of group names, any group not defined in the group-mapping file will be displayed using its ID.
From the BWeb configuration screen, it is also possible to adjust certain OAuth 2.0–related settings:
Single Sign-On (SSO)
After logging out of BWeb, the user is redirected back to the IdP login screen.
If the user logs in again from the IdP directly (rather than accessing BWeb via its URL), or if the user is already logged in to the IdP (for example, Okta), BWeb can be accessed automatically with a single click using Single Sign-On (SSO).
Simply, click in the application we created and a new tab will be automatically opened with BWeb:
The same behavior applies to Microsoft Entra ID when the application is configured to be visible to users:
As it is visible, you can see it from the M365 application launcher and open it with one click:
Troubleshooting
First Login
When accessing BWeb for the first time, the application must establish a connection with Bacula and the Catalog using a welcome wizard. This step must performed by a user with administrator privileges (“Bacula Admins” by default). If a non-administrator user attempts this initial access, the web server may return an HTTP 500 error.
Log Files
BWeb errors can be consulted in the regular error log file in, typically located at: /opt/bacula/working/bweb-error.log.
OAuth2 Proxy errors can be consulted in: /var/log/oauth2-proxy-error.log and /var/log/oauth2-proxy.log.
Information about errors in OAuth2 Proxy can be displayed in the web pages by activating the parameter: show_debug_on_error.
Fallback to Local Login
It is recommended to add the admin user to your system and set a password for it. This ensures that you can still access BWeb using system authentication if OIDC/OAuth 2.0 integration is disabled for any reason.
root@jubu:/# sudo adduser admin info: Adding user `admin' ... info: Selecting UID/GID from range 1000 to 59999 ... info: Adding new group `admin' (1001) ... info: Adding new user `admin' (1001) with group `admin (1001)' ... info: Creating home directory `/home/admin' ... info: Copying files from `/etc/skel' ... New password: Retype new password: passwd: password updated successfully Changing the user information for admin Enter the new value, or press ENTER for the default Full Name []: BacAdmin Room Number []: Work Phone []: Home Phone []: Other []: Is the information correct? [Y/n] info: Adding new user `admin' to supplemental / extra groups `users' ... info: Adding user `admin' to group `users' ...
If you ever need to disable the proxy, you can do so by disabling the oauth2-proxy service
(e.g., using systemctl) and re-enabling BWeb to be served in any address. To achieve this,
edit the /opt/bweb/etc/httpd.conf file and comment out the server.bind line.
SSL Certificate
If you encounter HTTP 500 errors when accessing BWeb while using a custom or self-signed certificate,
oauth2-proxy may be rejecting the certificate. You can disable certificate verification by
setting the following option in the oauth2-proxy configuration:
# In /opt/bweb/etc/oauth2-proxy.cfg ssl_insecure_skip_verify = true
Since BWeb is typically served only in 127.0.0.1, this can still be considered a safe
approach, but we recommend to use a certificate that is valid for the server.
OAuth2.0 Access Token
As discussed in the Okta configuration section, most identity providers allow you to preview issued tokens. If BWeb is not being able to process authentication requests, first verify that the access token is valid and includes the required groups claim.
See also
Previous articles:
Go back to: BWeb Authentication Methods.