Backdoor administrative access via configuration files

If proper configuration and documentation is done, an administrator should never be locked out of their JIRA instance's web interface. The reality is that mistakes happen and this is actually a fairly common scenario.

The common workaround to this problem is to use the steps mentioned here: https://confluence.atlassian.com/display/JIRA/Retrieving+the+JIRA+Administrator

This is a fairly complicated process, and is dangerous because it requires direct database modifications. Additionally, enterprise organizations may have a separate JIRA administrator and database administrator. This results in a longer, drawn out, access and modification request process.

Google Analytics shows 10,323 page views (see image) for the above mentioned document in the last year alone. A search on SAC for the document brings up 310 support tickets (I am not saying it was absolutely useful in each ticket, just what came up in a search for the url). This procedure is also frequently used internally by support engineers when dealing with customer data.

In other products I have worked on, there has been an easy to use backdoor feature.

It is important for the backdoor to natively verify a certain level of access permissions before it is triggered.

I propose that we add a parameter to the jira-config.properties file along the lines of:

jira.backdoor = 0

To enable, you would simply set it to 1, and restart the JIRA instance.

This would be read at the time of JIRA starting and would disable all authentication directories within JIRA, and attach a single directory with a preconfigured user and password. This directory would not be editable (or can be generated at boot time, so modifications do not persist).

By placing this option in the configuration file, we are verifying that:

1. The user has access to the server running the instance
2. The user's level of access allows them to write changes to the jira-config.properties file
3. The user's level of access allows them to restart services / applications

This would also serve as a first step towards providing a solution to JRA-1924