Confluence enables teams to collaborate more efficiently and effectively on all aspects of their content. In this article we give a high-level overview of Atlassian Confluence’s flexible permission system.
Users and groups
In Confluence you can assign permissions to registered users and groups. Groups are simply lists of users (or other groups) that are lumped together because they are given identical access rights.
It is also possible to grant access to certain content and functions to anonymous users . If public access is activated, every user who is not logged in will receive the rights of an anonymous user. For anonymous users, only a restricted subset of all permissions can be assigned. 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 are visible to anonymous users.
There are two special groups that are created by default.
Newly created users are automatically assigned to this group. After creation, you are automatically assigned the authorizations for this group. 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 also be granted without this group. This group can also be deleted, if the administration rights were previously secured in another way – otherwise the administrator can exclude himself. It is therefore recommended to make a backup beforehand.
Choosing the optimal licensing model
Confluence’s pricing model is graded 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 be retained, but he or she will no longer occupy a license. Especially when a large number of users are integrated via external user directories such as the company’s Active Directory, it is often difficult to determine the number of occupied user licenses via the user interface. However, in most cases this can be done via an SQL database queryand can often reveal optimisation potential.
An important feature of anonymous user access from a software licensing perspective is that it has no impact on the pricing model, regardless of the number and frequency of accesses. Only registered users who have access to the application are required to hold a user license. If many users in your company only use the system as so called watchers or their identity is insignificant, you could check whether they need their own application login or access as anonymous users would be 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, they will, depending on the security relevance of the information, potentially consider this to be sufficiently protected by the network configuration. In addition, anonymous access greatly limits the traceability and thus the auditability of accesses and changes, which may be undesirable or, depending on the situation. This is also prohibited by regulatory requirements.
Organizational scaling possible via decentralized authorization management
All content in Confluence is stored in a container called a space. Various space administrators can be defined for each space. They have no global administration rights in Confluence, but can manage the content and access to it within their space. In larger organizations, administration tasks can be divided or decentralized among several people. For example, the HR management can be defined as the administrator of the HR space to enable it to independently make certain content visible only to certain managers.
Confluence’s authorization system is hierarchically divided into three levels. The first two levels shown in the diagram function according to a whitelist approach. Only those who explicitly have authorization are granted access to information. The third level are restrictions on certain content pages that are defined similarly to a blacklist. If no specific restriction is defined on the content page, all those who are authorized to access the application and the respective space have access by default.
The first level contains global settings, which can only be set 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 spaces.
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 space 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 space.
- Can users create new space themselves? The user is automatically entered there as space 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. The permission as Confluence administrator differs despite very similar names with the special group confluence-administrators explained earlier in this article. The members of this special group get additional rights for 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 privileges.
Fine granular authorization management down to the individual information page
Within the spaces, the authorizations can be fine tuned further. At the second hierarchical level of the authorization system, authorizations that are valid space-wide are defined first. Several authorizations can be assigned to a group, individual users and anonymous access. In the following sections, for the sake of easier readability we will be using the term “user” to refer to persons with individual authorization rights and group autorization rights.
Usually, the authorization to display contents of the space represents the basic authorization that is assigned. Further it can be defined individually for pages, blog articles, attachments and comments whether these can be created (and changed) and/or deleted. You can also specify separately that only your own content can be deleted, for example. The user’s own content is everything the user originally created, regardless of whether this content was later revised or added to by other users.
As special privileges, it can also be set whether the user can define further access restrictions on the page content, whether content entered into the system can be deleted by mail, and whether the user can export or administer the entire space.
If a user is a member of several groups or is assigned further authorizations in addition to group authorizations as an individual user, note that the authorizations cumulate. The user thus receives the sum of all granted rights. It is therefore not possible to revoke individual rights granted to a user via an individual authorization. In addition, every registered and logged in user receives at least all rights that have also been granted to an anonymous user.
The described space authorizations can also be granted to anonymous users. As a rule, however, only display rights and possibly the right to enter 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 space level can view or edit the information page. In addition, only the editing alone or simultaneously the display and the editing together can be further restricted to certain users or groups per page.
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 the case of display. In the following example, a display restriction is defined on the content page with the title Project Management.
As a result, the subordinate Planning and Status Reports pages 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 child page.
Note, however, that if the Planning subpage is moved and placed below the Concept page, for example, this inherited display restriction is automatically removed for that page.
This behaves differently 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 afterwards. This means that the Planning and Status Reports pages 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 even if the page is moved later.
Best Practice: Authorizations preferred via groups and at space level
As a best practice, it is recommended to assign authorizations primarily to suitable groups and not to individual users when assigning authorizations. This considerably reduces the administration effort and ensures consistent and consistent authorization concepts.
Page restrictions should be used moderately, as they quickly become unclear. While the use of display restrictions can still be applied relatively consistently within an authorization concept due to their inheritance properties, editing restrictions are quickly turn into a patchwork because they have to be assigned anew for each relevant page. There may well be occasional or temporary use cases for editing restrictions. However, if it turns out that a certain topic group of content can only be edited to a limited extent, the creation of a separate Confluence space is recommended.
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 cleansing of your authorization management? Would you like to implement a single sign-on for several applications? Do you need a two-factor authentication for your Confluence or another application? Contact: email@example.com | +41 78 746 51 16