Administrator's Guide - 1.0
- Randall Ward
| Configuration Setting | Description | Default Value |
|---|---|---|
| Application users Can Require 2FA | Application users familiar with 2FA may want the strongest possible settings in place for their own account. If enabled, this configuration provides you with the option to allow application users to control how 2FA behaves for their own user account. Users can elect to have 2FA always enforced, regardless of rules in place to control certain content areas of the application. | Yes (enabled) |
Users can disable their own 2FA | This setting controls whether or not you will allow your application end users to disable 2FA configuration once they're set up. | Yes (allow) |
| Allow use of recovery code | If a user doesn't have their 2FA application or token, they can access their accounts using a recovery code. Recovery codes are only issued once to a user when they first set up 2FA and users are encouraged to store them in a safe location. Six separate recovery codes are issued to the user, of which, only one is required to be keyed into the application order to recover their 2FA credentials. | Yes (enabled) |
2FA Timeout Value | Configure the length of time that a application users 2FA session token is valid after which the system logs out inactive users. Valid timeout values range between 15 minutes and 48 hours. Choose a shorter timeout period if you want to enforce stricter security. | 1 hr |
Restrict Git repository activities | While the rules don't apply to specific Git activities (e.g.,'git pull', 'git push', 'git fetch', etc) you can enforce that all user sessions from external client applications (e.g., SourceTree, eclipse, etc) have a active 2FA session established - directing the user to establish this by logging into the application. | NO (do not restrict) |
Send activity emails to users | When a user enables or disables 2FA on their own account, the system can send them an email notifying them of the action. | Yes (enabled) |
Send usage data | As part of building awesome add-ons we sometimes need to gather basic usage data to continually improve. No Personally Identifiable Information (PII) is included in the analytics information sent. We do include the Support Entitlement Number (SEN) to help improve our customer support experience. For more details on what is being sent, please refer to this page. | Yes (enabled) |
Rules Configuration
Rules configuration settings are available through the Add-ons administration interface under the Rules Configuration link. Here you can create any number of custom rules that define how you should enforce 2FA behavior (Block) or (Allow). Once created, click Add to save them. Upon being added, Rules will be enforced immediately. To remove an existing Rule, simply click on the Delete button next to the Rule you wish to remove.
Creating Rules
Creating a Rule is easy and you can have any number of them in place. Note: Rules are evaluated top-down in the order they are listed. Simply provide the following information and click on Add:
- Name: Provided a unique name for your new Rule. It helps if you try and include the intent of your rule in the name, especially as you begin to have similar rules.
- Path Type: Choose from one of the following Path Types:
- Starts with - use this Path Type to match on URL paths that begins (starts) with the value you specify. Note: this applies to the URL path beyond the Base URL value defined within your Administrative settings. So if your Base URL were: https://acme.com/bitbucket then this rule would be evaluated against URL values after the Base URL. For example, a Starts with value of "IT" would evaluate your Rule Behavior for any URL that began with IT, such as "<BASE URL>/IT-Ops/", "<BASE URL>ITGovernance/", etc.
- Ends with - use this Path Type to match on URL paths that ends with the value you specify. This applies to the end of your URL path. For example, a Ends with value of "ngs" would evaluate your Rule Behavior for any URL that ended with "ngs" such as: "https://acme.com/bitbucket/admin/server-settings".
- Contains - use this Path Type to match on URL paths that contain the value you specify. For example, a Contains value of "admin" would evaluate your Rule Behavior for any URL that contained "admin" such as: https://acme.com/bitbucket/admin/settings"
- Regular Expression - Use this Path Type to unlock powerful regex pattern matching by using valid regex syntax within the Path Value;.
- Path Value: This field contains a value specific to the Path Type and Rule Behavior you are looking to evaluate.
- Group: Define a specific G upon which the Rule will be evaluated and Behavior applied. When specified, Rules will only apply to application users belonging to the specified Group. Leave the Group value blank if you would like the Rule evaluated for all application users.
- Behavior: Specify Block, if you would like to prevent access to the Path Value specified when the rule is triggered. Specify Allow if you would like to allow access to the Path Value specified when the rule is triggered.
Rules Templates
Our 2FA add-on ships with several out-of-the-box Rules Templates that can be applied to your application. To use one of our templates, you can click on the ShowMe! link at the top of this configuration section.
Testing Rules
Once created, you can test a rule by clicking on the Test Rules button and specifying a Group to test against. When you click on Test, each of the Rules defined will be evaluated for the Group specified and you will see either 
or 
next to each of the Rules.
2FA User Management
Find out which users have 2FA configured within your instance. Should you require, this configuration screen also allows you to reset 2FA configuration for all application users.
End User Messaging
You can easily customize most text displayed to 2FA users when interacting with this environment. Once you have completed making your changes, click Save to apply them.
Messages are organized across 6 tabbed collections.
