Permission management in Confluence

Share on facebook
Share on twitter
Share on email

Confluence enables teams to work together more efficiently and better around their content. In this article we give a high-level overview of the flexible permission system of Atlassian Confluence.

Users and groups

In Confluence, permissions can be assigned to registered users and groups. Groups are simply lists of users (or additional groups) that are combined because they will be given identical access rights.

It is also possible to grant anonymous users access to certain content and functions. If public access is activated, every user who is not logged in will receive the rights of an anonymous user. Only a limited subset of all permissions can be assigned to anonymous users. In the global settings, access can be granted in the General Settings under Global Permissions. In addition to access to the application, you can also specify there whether user profiles should be visible to anonymous users.

There are two special groups that are created by default.


Newly created users are automatically assigned to this group. Accordingly, you will automatically be assigned the permissions of this group after creation. If this group is deleted, new users have no permissions.


The members of this group get access to the administration masks of Confluence. Administration rights can be granted even without this group. Accordingly, this group can be deleted if the administration rights have been secured in another way – otherwise the administrator can exclude himself. It is therefore recommended to make a backup of the administration rights in advance.

Choose the optimal licensing model

Confluence’s pricing model is tiered according to the number of users. For example, if 90 users work with Confluence, a license for 100 users must be purchased. If an employee leaves the company, his user account can be deactivated. His or her data will then still be retained, but he or she will no longer use a license. Especially if a large number of users are integrated via external user directories like the company’s Active Directory, it is often difficult to determine the number of occupied user licenses via the user interface. In most cases, however, this can be done via an SQL database query and can often already reveal optimization potential.

An important feature of anonymous user access from the point of view of software licensing is that there is no influence on the pricing model, regardless of the number and frequency of access. Only registered users who have access to the application prove a user license. If many users in your company use the system for reading or the identity of the users is insignificant, you should therefore check whether they should receive their own application login at all or whether the access possibilities of the anonymous users are sufficient. Of course, it should be noted that the information made available to these users will then be made public within the network. If the system is located in a protected network, depending on the security relevance of the information, they will potentially be able to regard this as sufficiently protected by the network configuration. In addition, anonymous access severely limits the traceability and thus the auditability of accesses and changes, which may be undesirable or, depending on the situation, may also be prohibited by regulatory requirements.

Organizational scaling via decentralized authorization management possible

All content in Confluence is stored in a container called a space. For each area different area administrators can be defined. These administrators do not have global administration rights in Confluence, but they can manage the content and access to it within their area. This allows larger organizations to distribute or decentralize administration tasks to several people. For example, HR management can be defined as the administrator of the HR department to enable them to independently make certain content visible only to certain managers or similar.

The authorization system of Confluence is hierarchically structured into three levels. The first two levels shown in the graphic work according to a whitelist approach. Only those who explicitly have an authorization are granted access to information. The third level are restrictions to certain content pages, which are defined similar to a blacklist. If no specific restriction is defined on the content page, by default all those who are authorized to access the application and the respective area have access.

The first level contains global settings that can only be assigned by the Confluence system administrator. This includes the administration of the user directory respectively the integration of external user directories, the assignment of global permissions and the definition of standard permissions for newly created areas.

For registered users and groups, the following global permissions can be assigned in addition to basic application access itself:

  • Can the user create a personal area for himself? Here he can store personal notes, link lists, etc., maintain a personal blog or provide information for others that does not fit directly into another area.
  • Can the user create new areas himself? He is automatically entered as area administrator after creation.
  • Is the user a Confluence administrator or a system administrator with access to global settings? The system administrator also has access to security-relevant settings, while the Confluence administrator can only change selected settings. The exact differences can be found in the product documentation. Despite the very similar name, the Confluence-Administrator privilege differs from the special group confluence-administrators explained earlier in this article. The members of this special group are given additional rights compared to users with Confluence-administration permissions (see product documentation). This can cause some confusion, but is usually only relevant for larger organizations that want to split their Confluence administration permissions.

Fine-grained authorization management down to the individual information page

Within the areas, the authorizations can be defined in fine granularity. First, area-wide authorizations are defined on the second hierarchical level of the authorization system. Several authorizations can be assigned for a group, individual users and anonymous access. In the following sections, the term user is used for ease of reading, regardless of whether the user is assigned the authorization individually or is authorized via a group of which he or she is a member.

Usually, the permission to display the contents of the area is the basic permission that is assigned at least. Furthermore, it can be defined individually for pages, blog articles, attachments and comments whether they can be created (and changed) and/or deleted. In addition, it can also be defined separately that, for example, only own content can be deleted. Own content is everything that the user originally created, regardless of whether this content was later revised or added by other users.

As special privileges, you can also set whether the user may define further access restrictions on the page contents, whether contents received into the system by mail may be deleted and whether the user may export or administer the entire area.

If a user is a member of several groups or is assigned additional permissions in addition to group permissions as an individual user, please note that the permissions are cumulative. The user therefore receives the sum of all granted authorizations. It is therefore not possible for a user to use an individual authorization to revoke individual rights that he or she has been granted via a group authorization. In addition, every registered and logged in user receives at least all rights that were also granted to an anonymous user.

In principle, the area authorizations explained can also be granted to anonymous users. As a rule, however, only display rights and possibly the authorization for entering comments are granted here.

Display and editing restrictions can then be defined at the level of the individual information pages. By default, no restrictions are set; anyone with the appropriate authorization at the Area level can view or edit the information page. In addition, it is now possible to limit the editing per page to a single user or to display and edit the information together with certain users or groups.

The restriction is thus stored on a specific content page. Changes in the restriction settings of subordinate pages are not automatically made, but there is an inheritance rule in the case of display. The following example defines a display restriction on the content page entitled Project Management.

As a result, the subordinate pages Planning and Status Reports can only be accessed by those users who also have access to the Project Management page. It is not possible to remove this restriction on a subordinate page.

Note, however, that if the Planning subordinate page is moved and placed below the Concept page, for example, this inherited display restriction is automatically removed for this page.

This is different for editing restrictions, which can be confusing. In the following example, only one editing restriction is defined on the Project Management page.

This restriction is not inherited thereafter. This means that the pages Planning and Status Reports can still be edited without restrictions. If inheritance is desired, it must also be entered manually on the subpages. If this restriction is entered on subpages, these restrictions will of course remain in place even if the page is moved later.

Best Practice: Authorizations preferably over groups and on area level

As a best practice, it is recommended on the one hand to primarily grant permissions to appropriate groups rather than individual users when assigning permissions. This considerably reduces the administration effort and ensures consistent and universal authorization concepts.

On the other hand, page restrictions should be used moderately, as they quickly become unclear. While the use of display restrictions can still be applied relatively consistently within the framework of an authorization concept due to their inheritance properties, editing restrictions in particular can quickly become a patchwork because they have to be reassigned for each relevant page. There may be occasional or temporary cases where editing restrictions can be applied. However, if it turns out that a certain group of topics may only be edited in a limited way, it is recommended to create a separate Confluence area.

About the author

Stefan Haller is a certified Confluence Administrator and specialist for authorization concepts and data protection at linkyard. Do you need support with the conception or cleanup of your authorization management? Do you want to realize a single sign-on for several applications? Do you need a two-factor authentication for your Confluence or another application? Please contact: | +41 78 746 51 16