Permission management in Confluence

Confluence enables teams to work together more efficiently and better around their content. In this article, we provide a high-level overview of Atlassian Confluence's flexible authorization system.

Users and groups

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

In addition, 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 authorizations can be assigned to anonymous users. In global settings, access can be made in the General settings under Global entitlements grant. In addition to access to the application, you can also define 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, after creation, you will automatically be assigned the permissions to this group. If this group is deleted, new users have no permissions.

Confluence administrators

The members of this group have access to the Confluence administration masks. Administration rights can also be granted without this group. Accordingly, this can also be deleted, provided that the administration rights have been saved in another way beforehand — otherwise the administrator can exclude himself in this way. A previous backup is therefore recommended.

Choose the optimal licensing model

Confluence's pricing model is tiered based on the number of users. For example, if 90 users are working with Confluence, a license must be obtained for 100 users. If an employee leaves the company, their user account can be deactivated. His data is then retained, but he no longer uses 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. About a SQL database query However, this can be achieved in most cases and can often already reveal potential for optimization. An important feature of anonymous user access from the point of view of software licensing is that, regardless of their number and frequency of access, there is no influence on the pricing model. Only registered users who have access to the application use a user license. If many users in your company use the system read-only or the identity of the users is irrelevant, you should therefore check whether they should receive their own application login at all or whether the access options of anonymous users are sufficient. Of course, it should be noted that the information made available to these users is then de facto made public within the network. If the system is 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 due to regulatory requirements.

Organizational scaling possible via decentralized authorization management

All content in Confluence is named in a container area or English Space filed. Different area administrators can be defined for each area. Although they then have no global administration rights in Confluence, they can manage the content and access to it within their area. In this way, administrative tasks can be divided or decentralized among several people in larger organizations. For example, HR management can be defined as an administrator of the HR department in order to enable them to independently make certain content visible only to certain managers or similar.

For this purpose, Confluence's authorization system is hierarchically divided into three levels. The first two levels shown in the graph work according to a whitelist approach. Only those who have explicit authorization have access to information. The third level is restrictions on certain content pages, which are defined in a similar way to a blacklist. If no special restriction is defined on the content page, everyone who is authorized to the application and the respective area has access by default. On the first level, there are global settings, which can only be assigned by the Confluence system administrator. This includes managing the user directory or integrating external user directories, granting global authorizations and defining standard authorizations for newly created areas. In addition to basic application access, the following global authorizations can be issued for registered users and groups:

• Can the user create a personal area for themselves? Here he can store personal notes, link lists, etc., keep a personal blog or provide information for others that does not directly fit into another area.
• Can the user create new areas themselves? After creation, he is automatically entered there as an area administrator.
• Is the user a Confluence administrator or a system administrator with access to global settings? The system administrator also has access to security-related settings, while the Confluence administrator can only change selected settings. The exact differences can be found in Product documentation be removed. Despite having a very similar name, permission as a Confluence administrator differs from the special group Confluence administrators explained earlier in this article. The members of this special group receive additional rights compared to users with Confluence administration privileges (cf. Product documentation). This can cause some confusion, but is usually only relevant for larger organizations that want to divide up their Confluence administration privileges.

Fine-grained authorization management down to the individual information page

Within the areas, authorizations can be defined in a fine-grained manner. At the second hierarchical level of the authorization system, authorizations valid across the area are first defined. Several authorizations can be assigned for a group, individual users and anonymous access. For easier readability, the following sections talk about users, regardless of whether this user is assigned the permission individually or is authorized via a group of which he is a member. Usually, the permission to display content in the area represents the minimum permission that is granted. Furthermore, it can then be defined individually for pages, blog articles, attachments and comments whether they can be created (and modified) and/or deleted. In addition, you can specify separately that, for example, only your own content can be deleted. Personal content is anything that the user has originally created himself, regardless of whether this content was later revised or supplemented by other users. As special privileges, it can also be set whether the user may define further access restrictions on the page content, whether on the Mailweg Content entered into the system may be deleted and whether the user can export or administer the entire area. If a user is a member of several groups or receives additional permissions as an individual user in addition to group permissions, it should be noted that the authorizations cumulate. The user therefore receives the sum of all rights granted. It is therefore not possible to revoke individual rights that a user has received via a group authorization via an individual 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 explained area permissions can also be granted to anonymous users. As a rule, however, only viewing rights and possibly permission to enter comments are granted here.

Display and editing restrictions can then be defined at the level of the individual information pages. By default, there are no restrictions; anyone with the respective permission at the area level can view or edit the information page. In addition, only editing alone or simultaneously viewing and editing together can now be further restricted to specific users or groups per page. The restriction is thus stored on a specific content page. Changes are not automatically made to the restriction settings of subordinate pages, but there is an inheritance rule when displayed. The following example shows an ad restriction on the content page with the title Project management defined.

As a result, you can also access the subordinate pages planning and status reports are only accessed by users who also access the site Project management has access. It is not possible to remove this restriction on a child page. However, it should be noted that if the child page planning If it is now moved and, for example, arranged below the Concept page, this inherited display restriction is automatically lifted for this page. This is different — which can be quite confusing — when it comes to editing restrictions. In the example below, there is only one editing restriction on the page Project management defined.

This restriction is not inherited afterwards. So that 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 applied to subpages, these restrictions will of course remain in place even if the page is moved later.

Best practice: Authorizations preferred across groups and at area level

As a best practice, it is recommended, on the one hand, when granting authorizations, primarily to appropriate groups and not to individual users. This significantly reduces administrative costs and ensures consistent and consistent authorization concepts. On the other hand, page restrictions should be used moderately, as they quickly become confusing. While the use of display restrictions can still be applied relatively consistently as part of an authorization concept due to their inheritance characteristics, editing restrictions in particular are quickly a patchwork as they must be reassigned for each relevant page. There may well be occasional or temporary use cases for processing restrictions. However, if it turns out that a specific topic group of content can only be edited to a limited extent, it is recommended to create a separate Confluence area.

‍About the author

Stefan Haller is a certified Confluence administrator and specialist in authorization concepts and data protection at linkyard. Do you need help designing or streamlining your authorization management? Would you like to implement a single sign-on for several applications? Do you need two-factor authentication for your Confluence or another application? Sign in to: stefan.haller@linkyard.ch | +41 78 746 51 16