Permission management in Confluence

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 whether user profiles should be visible to anonymous users. There are two special groups that are created by default.

confluence-users

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.

confluence-administrators

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.

Choosing 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. 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 are entitled to 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, all users who are authorized to access the application and the respective area have access by default. The first level contains global settings that can only be assigned by the Confluence system administrator. This includes the administration of the user directory or 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 the 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-granular 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 this user is assigned the authorization individually or via a group of which he or she is a member. Furthermore, it can be defined individually for pages, blog articles, attachments and comments whether they can be created (and modified) and/or deleted. In addition, it can also be defined separately that, for example, only own content can be deleted. As special privileges, you can also define whether the user is allowed to define further access restrictions on the page content, whether the user is allowed to delete content received by the system via mail and whether the user is allowed to export or administrate the whole area. If a user is a member of several groups or receives 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 rights. It is therefore not possible for a user 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. 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 group, or to limit the display and editing together to certain users or groups. The restriction is thus stored on a specific content page. Changes in the restriction settings of subordinate pages are not made automatically, but there is an inheritance rule in 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, but if the subordinate Planning page is moved and placed below the Concept page, for example, this inherited display restriction is automatically removed for this page. 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. On the other hand, page restrictions should be used moderately, since 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: stefan.haller@linkyard.ch | +41 78 746 51 16