Configure secure administrator sessions (websudo)

Administer Bitbucket Data Center

Still need help?

The Atlassian Community is here for you.

Ask the community

Bitbucket Data Center protects access to its administrative functions by requiring a secure administrator session to access and use the instance administration user interface. This functionality is known as WebSudo.

When a Bitbucket administrator tries to access administrative functions that require ADMIN or SYS_ADMIN level permissions, they will be prompted to re-authenticate using a second-step factor. In Bitbucket Data Center 9.6, secure admin sessions, referred to as websudo, have been enhanced to incorporate two-step verification (2SV) for added security. Admins who are enrolled in 2SV are required to provide their specified second-step verification factor prior to performing sensitive operations or accessing the Global administration settings page. Admins not enrolled in 2SV will still see the regular prompt.

The temporary secure administrator session has a default rolling timeout of 10 minutes. If there is no activity in the Bitbucket administration pages for a period that exceeds the timeout, the admin will be logged out of the secure session but will remain logged in to Bitbucket.

End a secure administrator session manually

You can choose to manually end your secure session by selecting the drop access link in the banner at the top of the screen.

Disable secure administrator sessions

Secure administrator sessions are enabled by default. You can disable the feature by adding the following line in your bitbucket.properties file and restarting Bitbucket:

feature.websudo=false

Disable two-step verification support for websudo

Two-step verification support for websudo is enabled by default. You can disable the feature by adding the following line in your bitbucket.properties file and restarting Bitbucket:

atlassian.authentication.2sv.websudo.disabled

Disabling 2SV by using the atlassian.authentication.legacy.mode flag will turn off 2SV for websudo. 2SV support for websudo is a specific component of the overall 2SV login mechanism.

Disabling the Bitbucket Data Center websudo feature will also deactivate 2SV support for websudo, as 2SV is a specific component of the overall websudo functionality.

 For more information, visit Manage two-step verification for your Atlassian account.

Change the websudo session timeout

By default, the secure administrator session timeout is 10 minutes. That is, after 10 minutes of not accessing the administration pages, your session will automatically have its secure administration access removed. To access the instance administration functionality again, you'll need to re-enter your credentials.

You can change this timeout. For example, to decrease the timeout to 5 minutes, add the following line in your bitbucket.properties file and restart Bitbucket:

websudo.session.timeout=5

This value is in minutes by default but you can also use certain suffixes: s, m, h, and d for seconds, minutes, hours, or days, respectively. For example, 1h for one hour.

IP address allowlisting

It's useful to restrict administrator functionality to certain IP addresses, while continuing to permit non-administrator developer users to access the instance regardless of an IP address. Doing so is a smart security measure to, for example, restrict the impact of a stolen administrator user’s authentication credentials. You can achieve this by using the IP address allowlisting functionality of websudo.

By default, websudo requests from all IP addresses will be permitted. If you configure an allowlist, websudo will be denied for clients that don't originate from an IP address on the allowlist.

You can configure an allowlist by adding one or more IP address patterns in the bitbucket.properties file. For example, to only permit websudo from the IP address 192.168.1.10, add the following line to your bitbucket.properties file and restart Bitbucket:

websudo.allowlist.patterns=192.168.1.10

Patterns can be IPv4/IPv6 addresses or subnets in both asterisk and CIDR notation. Here are the examples of valid patterns:

  • 192.168.1.10

  • ::10

  • 192.168.1.*

  • 192.168.5.128/26

  • 0:0:0:7b::/64

Multiple patterns can be specified as a comma separated list. For example:

websudo.allowlist.patterns=192.168.1.10, 192.168.2.*, 192.168.5.128/26

Developer notes

REST APIs

  • Elevate Websudo using TOTP: /rest/2sv-websudo/1.0/elevate/totp (POST)

  • Elevate Websudo using Recovery Code: /rest/2sv-websudo/1.0/elevate/recovery-code (POST)

If you've written a plugin that includes the administration pages requiring ADMIN or SYS_ADMIN permissions, the servlets or REST resources that implement those pages should be made websudo-aware.

Add websudo support to your plugin

Last modified on Mar 18, 2025

Was this helpful?

Yes
No
Provide feedback about this article
Powered by Confluence and Scroll Viewport.