Documentation for Confluence 5.4.
Documentation for Confluence OnDemand and earlier versions of Confluence is available too.

Skip to end of metadata
Go to start of metadata
Some directory servers allow you to define a group as a member of another group. Groups in such a structure are called 'nested groups'. If you are using groups to manage permissions, you can create nested groups to allow inheritance of permissions from one group to its sub-groups.

This page describes how Confluence handles nested groups that exist in one or more of your directory servers.

Enabling Nested Groups

You can enable or disable support for nested groups on each directory individually. Go to the 'User Directories' section of the Confluence Administration Console, edit the directory and select 'Enable Nested Groups'. See Configuring User Directories.

Notes:

  • Before enabling nested groups for a specific directory type in Confluence, please make sure that your directory server supports nested groups.
  • Please read the rest of this page to understand what effect nested groups will have on authentication (login) and permissions in Confluence, and what happens when you update users and groups in Confluence.

On this page:

(warning) The information on this page does not apply to Confluence OnDemand.

Effect of Nested Groups

This section summarises the effect nested groups will have on login and permissions, and on the viewing and updating of users and groups.

Login

When a user logs in, they will be allowed access to the application if they belong to an authorised group or any of its sub-groups.

Permissions

The user will be allowed access to a function if they belong to a group that has the necessary permissions, or if they belong to any of its sub-groups.

Viewing Lists of Group Members

If you ask to view the members of a group, you will see all users who are members of the group and all users belonging its sub-groups, consolidated into one list. We call this a 'flattened' list.

You cannot view or edit the nested groups themselves. You will not be able to see that one group is a member of another group.

Adding and Updating Group Memberships

If you add a user to a group, the user is added to the named group and not to any other groups.

If you try to remove a user from a flattened list, the following will happen:

  • If the user is a member of the top group in the hierarchy (tree) of groups contained in the flattened list, the user will be removed from the group.
  • Otherwise, you will see an error message stating that the user is not a direct member of the group.

Examples

Example 1: User is Member of Sub-Group

Let's assume that the following two groups exist in your directory server:

  • staff
  • marketing

Memberships:

  • The marketing group is a member of the staff group.
  • User jsmith is a member of marketing.

You will see that jsmith is a member of both marketing and staff. You will not see that the two groups are nested. If you assign permissions to the staff group, then jsmith will get those permissions.

Example 2: Sub-Groups as Members of the 'jira-developers' group

In an LDAP directory server, we have groups 'engineering-group' and 'techwriters-group'. We want to grant both groups developer-level access to our JIRA site.

  • Add a group called 'jira-developers'.
  • Add the 'engineering-group' as a sub-group of 'jira-developers'.
  • Add the 'techwriters-group' as a sub-group of 'jira-developers'.

Group memberships are now:

  • jira-developers — sub-groups: engineering-group, techwriters-group
  • engineering-group — sub-groups: dev-a, dev-b; users: pblack
  • dev-a — users: jsmith, sbrown
  • dev-b — users: jsmith, dblue
  • techwriters-group — users: rgreen

When JIRA requests a list of users in the 'jira-developers' group, it will receive the following list:

  • pblack
  • jsmith
  • sbrown
  • dblue
  • rgreen


Diagram: Sub-groups as members of the 'jira-developers' group

Gliffy Zoom Zoom

Example 3: Sub-Groups as Members of the 'confluence-users' group

In an LDAP directory server, we have groups 'engineering-group' and 'payroll-group'. We want to grant both groups access to our Confluence site.

  • Add a group called 'confluence-users'.
  • Add the 'engineering-group' as a sub-group of 'confluence-users'.
  • Add the 'payroll-group' as a sub-group of 'confluence-users'.

Group memberships are now:

  • confluence-users — sub-groups: engineering-group, payroll-group
  • engineering-group — sub-groups: dev-a, dev-b; users: pblack
  • dev-a — users: jsmith, sbrown
  • dev-b — users: jsmith, dblue
  • payroll-group — users: rgreen

When Confluence requests a list of users in the 'confluence-users' group, it will receive the following list:

  • pblack
  • jsmith
  • sbrown
  • dblue
  • rgreen


Diagram: Sub-groups as members of the 'confluence-users' group

Gliffy Zoom Zoom

Notes

  • Possible impact on performance. Enabling nested groups may result in slower user searches.
  • Definition of nested groups in LDAP. In an LDAP directory, a nested group is defined as a child group entry whose DN (Distinguished Name) is referenced by an attribute contained within a parent group entry. For example, a parent group 'Group One' might have an objectClass=group attribute and one or more member=DN attributes, where the DN can be that of a user or that of a group elsewhere in the LDAP tree:

RELATED TOPICS

Configuring User Directories

3 Comments

  1. Anonymous

    Thanks for this introduction; I'm trying to establish nested groups in openLDAP as a newby; so it would be helpful to show the example above (gliffy graph) configured with all the cn=... and ou=.....

    I try to attach a pic from my Apache directory Studio to show what I mean.

    Thanks a lot!

    kr Wolfgang 

  2. Anonymous

    Hi,

    I have successfully configured an AD directory, and enabled Nested Groups, but I everytime I try to add an AD secruity group to the jira-developers group i get the following error:

    You do not have permission to perform this operation.

    The documentation doesn't seem to cover this scenario

     

    1. Anonymous

      I managed to work around this by adding the AD group I wanted to the Project Developer role. Is this the correct way to do it, or should I have been able to add the AD group to the jira-developers group?