• Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.

      See USER-101

            [CWD-74] Support groups-within-groups

            Is this clear?

            Abundantly. Thanks for taking the time to draw out the diagrams. It made your question very easy to understand

            Can Crowd 1.4 do this?

            Yep! That's the primary use-case.

            David O'Flynn [Atlassian] added a comment - Is this clear? Abundantly. Thanks for taking the time to draw out the diagrams. It made your question very easy to understand Can Crowd 1.4 do this? Yep! That's the primary use-case.

            Hi,

            It's not clear to me if Crowd 1.4 will support my requirements. Hopefully if I explain here someone can clarify...

            My ActiveDirectory is configured like this:

            + DC=sub,DC=domain
            |---+ OU=SomeTopLevelNode
                  |---+ OU=SomeOtherNode
                       |---+ OU=MyConfluenceGroups
                             |---- CN=MixedUsersAndReferencedGroups
            |---+ OU=AnotherTopLevelNode
                 |---+ OU=Users
                       |---- CN=Joe Bloggs
                       |---- CN=Barny Rubble
                       |---- CN=Fred Flintstone
            |---+ OU=YetAnotherTLNode
                  |---+ OU=GroupsOutsideMyControl
                        |--- CN=Some Outside Group
                        |--- CN=Some Other Outside Group
            

            Users (e.g. Joe or Fred) have an objectClass=person attribute and an sAMAccountName=fred (for example) attribute.

            Groups 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 AD tree (e.g. Some Other Outside Group). This use of a member=DN attribute to refer to something other than a user is what I mean by "nested groups" but may not be your meaning.

            Assume that the MixedUsersAndReferencedGroups group has these member= attributes

            member=CN=Joe Bloggs,OU=Users,OU=AnotherTopLevelNode,DC=sub,DC=domain
            member=CN=Some Outside Group,OU=GroupsOutsideMyControl,OU=YetAnotherTLNode,DC=sub,DC=domain
            

            And that the Some Outside Group group has these member= attributes:

            member=CN=Fred Flintstone,OU=Users,OU=AnotherTopLevelNode,DC=sub,DC=domain
            

            When I look in Confluence -> Administration -> Manage Groups I want to see:

            MixedUsersAndReferencedGroups
            

            If I drill down into MixedUsersAndReferencedGroups the members I see should be:

            User, Full Name
            joe, Joe Bloggs
            fred, Fred Flintstone
            

            I should also be able to choose the MixedUsersAndReferencedGroups group in any of the permissions screens so that I can restrict access to various spaces to members of the groups under MyConfluenceGroups.

            Is this clear?
            Can Crowd 1.4 do this?

            Ximon Eighteen added a comment - Hi, It's not clear to me if Crowd 1.4 will support my requirements. Hopefully if I explain here someone can clarify... My ActiveDirectory is configured like this: + DC=sub,DC=domain |---+ OU=SomeTopLevelNode |---+ OU=SomeOtherNode |---+ OU=MyConfluenceGroups |---- CN=MixedUsersAndReferencedGroups |---+ OU=AnotherTopLevelNode |---+ OU=Users |---- CN=Joe Bloggs |---- CN=Barny Rubble |---- CN=Fred Flintstone |---+ OU=YetAnotherTLNode |---+ OU=GroupsOutsideMyControl |--- CN=Some Outside Group |--- CN=Some Other Outside Group Users (e.g. Joe or Fred) have an objectClass=person attribute and an sAMAccountName=fred (for example) attribute. Groups 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 AD tree (e.g. Some Other Outside Group). This use of a member=DN attribute to refer to something other than a user is what I mean by "nested groups" but may not be your meaning. Assume that the MixedUsersAndReferencedGroups group has these member= attributes member=CN=Joe Bloggs,OU=Users,OU=AnotherTopLevelNode,DC=sub,DC=domain member=CN=Some Outside Group,OU=GroupsOutsideMyControl,OU=YetAnotherTLNode,DC=sub,DC=domain And that the Some Outside Group group has these member= attributes: member=CN=Fred Flintstone,OU=Users,OU=AnotherTopLevelNode,DC=sub,DC=domain When I look in Confluence -> Administration -> Manage Groups I want to see: MixedUsersAndReferencedGroups If I drill down into MixedUsersAndReferencedGroups the members I see should be: User, Full Name joe, Joe Bloggs fred, Fred Flintstone I should also be able to choose the MixedUsersAndReferencedGroups group in any of the permissions screens so that I can restrict access to various spaces to members of the groups under MyConfluenceGroups. Is this clear? Can Crowd 1.4 do this?

            Hi Martin,

            Yes, a Crowd-integrated Confluence instance will see users in child groups as members of the parent group, allowing administrators to use nested groups to manage permissions. This will not affect Confluence instances that are not Crowd-enabled.

            Cheers,
            Dave.

            David O'Flynn [Atlassian] added a comment - Hi Martin, Yes, a Crowd-integrated Confluence instance will see users in child groups as members of the parent group, allowing administrators to use nested groups to manage permissions. This will not affect Confluence instances that are not Crowd-enabled. Cheers, Dave.

            will this soon affect confluence also ?

            Martin Mitry added a comment - will this soon affect confluence also ?

            Yes, loading of all members will be included. So you shouldn't need '980.

            David O'Flynn [Atlassian] added a comment - Yes, loading of all members will be included. So you shouldn't need '980.

            Bob Swift added a comment -

            Just a clarification, if I import a LDAP/AD directory into a delegated directory, will it load all members (including members from groups in groups)? If so, then the referenced item is not needed for LDAP based groups. If not, then 980 is absolutely needed.

            Bob Swift added a comment - Just a clarification, if I import a LDAP/AD directory into a delegated directory, will it load all members (including members from groups in groups)? If so, then the referenced item is not needed for LDAP based groups. If not, then 980 is absolutely needed.

            Hi Bob,

            Yep, Active Directory is definitely supported!

            Since delegated directories store their group information in Internal Directories, Nested Groups will not be available for them in the 1.4 release. Please vote for CWD-980 if you want this implemented.

            Dave.

            David O'Flynn [Atlassian] added a comment - Hi Bob, Yep, Active Directory is definitely supported! Since delegated directories store their group information in Internal Directories, Nested Groups will not be available for them in the 1.4 release. Please vote for CWD-980 if you want this implemented. Dave.

            Bob Swift added a comment -

            This is good news! I assume you mean LDAP directories including active directory.
            Does this support delegated LDAP/AD directories? The requirement, of course, is to support this!

            Bob Swift added a comment - This is good news! I assume you mean LDAP directories including active directory. Does this support delegated LDAP/AD directories? The requirement, of course, is to support this!

            Hi All,

            The 1.4 release of Crowd will support Nested Groups. There are some things you should be aware of:

            • This will be for LDAP directories only.
            • You can view, add & modify group->group relationships from the UI.
            • Client applications that ask for members of a group will see all members of the group and all sub-groups, consolidated into one list. This makes the new feature transparent to client applications.
            • If you have JIRA, Confluence, or another Atlassian application connected to Crowd, and you have nested groups in your directory, we suggest turning External User Management on. This will avoid confusion in the administration UI, as these applications do not understand the concept of nested groups.
            • There will be some additional developer documentation published, so developers using the SOAP API, or one of the wrappers, can understand how this change will affect them.

            Please let us know if this fails to satisfy your requirements, either by voting for one of the linked issues, creating one of your own, or commenting on this issue.

            Thanks!

            David O'Flynn [Atlassian] added a comment - Hi All, The 1.4 release of Crowd will support Nested Groups. There are some things you should be aware of: This will be for LDAP directories only. You can view, add & modify group->group relationships from the UI. Client applications that ask for members of a group will see all members of the group and all sub-groups, consolidated into one list. This makes the new feature transparent to client applications. If you have JIRA, Confluence, or another Atlassian application connected to Crowd, and you have nested groups in your directory, we suggest turning External User Management on. This will avoid confusion in the administration UI, as these applications do not understand the concept of nested groups. There will be some additional developer documentation published, so developers using the SOAP API, or one of the wrappers, can understand how this change will affect them. Please let us know if this fails to satisfy your requirements, either by voting for one of the linked issues, creating one of your own, or commenting on this issue. Thanks!

            +1 vote, this really is an essential feature.

            Liechti Thomas added a comment - +1 vote, this really is an essential feature.

            Bob Swift added a comment -

            This is critical for us as well as we re-organize our AD groups to better enable expanded Confluence, JIRA, Fisheye, and Crucible usage. Good group definitions make it easier to administrate authorities to spaces and projects. Putting this in Crowd would relieve pressure to put this support in the individual products.

            Bob Swift added a comment - This is critical for us as well as we re-organize our AD groups to better enable expanded Confluence, JIRA, Fisheye, and Crucible usage. Good group definitions make it easier to administrate authorities to spaces and projects. Putting this in Crowd would relieve pressure to put this support in the individual products.

            This also affects OpenDirectory

            Noah Campbell added a comment - This also affects OpenDirectory

            David Hay added a comment -

            This is a major drawback for us too.

            David Hay added a comment - This is a major drawback for us too.

            kgbvax added a comment -

            > Ops is very resistant to crowd because this feature is missing.
            And they are right.

            kgbvax added a comment - > Ops is very resistant to crowd because this feature is missing. And they are right.

            Just wanted to add that this is a huge deal for our organization as well. Ops is very resistant to crowd because this feature is missing.

            Alex Matviychuk added a comment - Just wanted to add that this is a huge deal for our organization as well. Ops is very resistant to crowd because this feature is missing.

            kgbvax added a comment -

            I concur, this is essential.
            I am wondering why this is on an "items to consider list" as it makes 50% of the groups in our (and other peoples LDAP) unusable.

            kgbvax added a comment - I concur, this is essential. I am wondering why this is on an "items to consider list" as it makes 50% of the groups in our (and other peoples LDAP) unusable.

            When will this issue be implemented?
            This is an essential feature in an enterprise setting with Crowd.

            Merete Jordal added a comment - When will this issue be implemented? This is an essential feature in an enterprise setting with Crowd.

            We would really like to see this feature added as well.

            Where it would really come in handy is in JIRA, since we must pre-defined group names (jira-users for example). Instead of adding every single user to the group, we could just add 'domain users' to the jira-users group.

            Nick Lomonte added a comment - We would really like to see this feature added as well. Where it would really come in handy is in JIRA, since we must pre-defined group names (jira-users for example). Instead of adding every single user to the group, we could just add 'domain users' to the jira-users group.

            1. Dynamic Groups requirements from Brown University are pretty simple:

            We'll need the ability to define a dynamic group based on more or less arbitrary ldap query patterns on people objects in the People OU. A couple examples:

            (&(objectClass=inetorgperson)(Type=student))
            (&(objectClass=inetorgperson)(primaryaffiliation=clinical faculty)(mailstop=1117))

            So a very broad filter set that allows admins in Crowd to define a group based on an ldap filter starting at a particular ou would be useful.

            2. Nested Groups requirements from Brown University are much more complicated and essential:

            At Brown, we have a highly nested ldap group schema for 30,000 persons and 12,000 groups on a SunOne directory server. We manage our ldap schema entirely outside of Confluence, so no person, group, or role management is necessary or desired in Confluence or Crowd. Confluence will consume centrally provisioned user and group objects, and, if possible, we want to automatically provision a Confluence space for each of the 12,000 groups. As an example, consider the courses use case:

            Say the course offering Computer Science 101 for 2nd semester 2007 has 2 sections, with base groups of faculty, TAs, matriculants, auditors, etc., plus other groups derived from the base groups.

            Generically:
            Base groups:
            ou=groups.courses.department.course_number.year.semester.section.[faculty,tas,matriculants,auditors,designers, guests]

            Derived groups:
            ou=Groups.courses.department.course_number.year.semester.section.instructors = faculty & TAs
            ou=Groups.courses.department.course_number.year.semester.section.students = matriculants & auditors
            etc.

            Sample data:

            CS 101 1st semester 2007, section 1:
            courses.cs.101.2007.1.01.faculty
            courses.cs.101.2007.1.01.matriculants
            courses.cs.101.2007.1.01.auditors
            courses.cs.101.2007.1.01.instructors (facutly & tas as unique members)
            courses.cs.101.2007.1.01.students (matriculants & auditors as unique members)

            CS 101 1st semester 2007, section 2:
            courses.cs.101.2007.1.02.faculty
            courses.cs.101.2007.1.02.matriculants
            courses.cs.101.2007.1.02.auditors
            courses.cs.101.2007.1.02.instructors (facutly & tas as unique members)
            courses.cs.101.2007.1.02.students (matriculants & auditors as unique members)

            CS 101 2nd semester 2007, section 1:
            courses.cs.101.2007.2.01.faculty
            courses.cs.101.2007.2.01.matriculants
            courses.cs.101.2007.2.01.auditors
            courses.cs.101.2007.2.01.instructors (facutly & tas as unique members)
            courses.cs.101.2007.2.01.students (matriculants & auditors as unique members)

            CS 101 2nd semester 2007, section 2:
            courses.cs.101.2007.2.02.faculty
            courses.cs.101.2007.2.02.matriculants
            courses.cs.101.2007.2.02.auditors
            courses.cs.101.2007.2.02.instructors (facutly & tas as unique members)
            courses.cs.101.2007.2.02.students (matriculants & auditors as unique members)

            CS 103 1st semester 2007, section 1:
            courses.cs.103.2007.1.01.faculty
            courses.cs.103.2007.1.01.matriculants
            courses.cs.103.2007.1.01.auditors
            courses.cs.103.2007.1.01.instructors (facutly & tas as unique members)
            courses.cs.103.2007.1.01.students (matriculants & auditors as unique members)

            CS 103 1st semester 2007, section 2:
            courses.cs.103.2007.1.02.faculty
            courses.cs.103.2007.1.02.matriculants
            courses.cs.103.2007.1.02.auditors
            courses.cs.103.2007.1.02.instructors (facutly & tas as unique members)
            courses.cs.103.2007.1.02.students (matriculants & auditors as unique members)

            etc...

            All objects in the schema are ous except the terminal members of the tree, which are groups of unique members. The base groups (faculty, matriculants, auditors, etc.) have persons as unique members, and the derived groups (instructors, students, etc.) have groups as unique members.

            So by 'nested groups,' we have long branches of ous leading to groups of people and groups of subgroups. We need to be able to assign permissions to a Confluence object to all child members of any point of the schema. For example, there may be a Confluence space for all members of CS 101 in the 1st semester of 2007, so we'll need to grant access to that space by assigning all users in the ou, from the ou level (groups.courses.cs.101.2007.1), so that any new children of that ou, be they new ous or new groups or new person objects are automatically included in the ou as soon as they show up in ldap.

            Additionally, allowing a filter or wild card will be essential for some operations. For example:

            Read permission: courses.cs.101.2007.1 (all members of all groups in cs 101 1st semester 2007)
            Write permission: courses.cs.101.2007.1.*.instructors (instructors of cs 101 1st semester 2007

            So the derived group of instructors for all sections of a course can write to an object, while students can read only.

            So this raises the question of forward references, since that would be a person-based means of looking up the various groups. I can imagine a design where Crowd or Confluence base permissions on a person attribute value in the form of ou=People.uid.memberOf=courses.cs.101.2007.1.*. This may be OK for runtime use (am I a member of group x), but I think it will be more efficient in the administration side to reverse the query and allow administrators to browse the ldap tree to find the correct node, with an option of listing members of the selected set, or at least the number of users. We may or may not wind up implementing forward references for all groups. We would prefer the flexibility to not, but we could work with that as a requirement.

            As if you need this to be more complicated, having an unfettered view of the ldap schema is not desired. There are groups and ous within the ldap schema that must remain private--both their membership as well as their existance, in some cases. Let's assume these will be labeled by acls in the ldap server, but that any interface that lists the schema will need to gracefully handle a case where a group may be listed, but its members may not be listable by the application.

            Alternatively, there is a simpler use case of residential dorms, which are sometimes defined as groups of physical buildings. So a schema for this use case would be:

            groups.dorms.cluster.building.floor.room

            Sample data:
            groups.dorms.undergrad_east.foo.1.112
            groups.dorms.undergrad_east.foo.2.212
            groups.dorms.undergrad_east.foo.3.couch
            groups.dorms.undergrad_east.bar.1.guest12
            groups.dorms.west.grad12.11.1141

            James Cramton added a comment - 1. Dynamic Groups requirements from Brown University are pretty simple: We'll need the ability to define a dynamic group based on more or less arbitrary ldap query patterns on people objects in the People OU. A couple examples: (&(objectClass=inetorgperson)(Type=student)) (&(objectClass=inetorgperson)(primaryaffiliation=clinical faculty)(mailstop=1117)) So a very broad filter set that allows admins in Crowd to define a group based on an ldap filter starting at a particular ou would be useful. 2. Nested Groups requirements from Brown University are much more complicated and essential: At Brown, we have a highly nested ldap group schema for 30,000 persons and 12,000 groups on a SunOne directory server. We manage our ldap schema entirely outside of Confluence, so no person, group, or role management is necessary or desired in Confluence or Crowd. Confluence will consume centrally provisioned user and group objects, and, if possible, we want to automatically provision a Confluence space for each of the 12,000 groups. As an example, consider the courses use case: Say the course offering Computer Science 101 for 2nd semester 2007 has 2 sections, with base groups of faculty, TAs, matriculants, auditors, etc., plus other groups derived from the base groups. Generically: Base groups: ou=groups.courses.department.course_number.year.semester.section. [faculty,tas,matriculants,auditors,designers, guests] Derived groups: ou=Groups.courses.department.course_number.year.semester.section.instructors = faculty & TAs ou=Groups.courses.department.course_number.year.semester.section.students = matriculants & auditors etc. Sample data: CS 101 1st semester 2007, section 1: courses.cs.101.2007.1.01.faculty courses.cs.101.2007.1.01.matriculants courses.cs.101.2007.1.01.auditors courses.cs.101.2007.1.01.instructors (facutly & tas as unique members) courses.cs.101.2007.1.01.students (matriculants & auditors as unique members) CS 101 1st semester 2007, section 2: courses.cs.101.2007.1.02.faculty courses.cs.101.2007.1.02.matriculants courses.cs.101.2007.1.02.auditors courses.cs.101.2007.1.02.instructors (facutly & tas as unique members) courses.cs.101.2007.1.02.students (matriculants & auditors as unique members) CS 101 2nd semester 2007, section 1: courses.cs.101.2007.2.01.faculty courses.cs.101.2007.2.01.matriculants courses.cs.101.2007.2.01.auditors courses.cs.101.2007.2.01.instructors (facutly & tas as unique members) courses.cs.101.2007.2.01.students (matriculants & auditors as unique members) CS 101 2nd semester 2007, section 2: courses.cs.101.2007.2.02.faculty courses.cs.101.2007.2.02.matriculants courses.cs.101.2007.2.02.auditors courses.cs.101.2007.2.02.instructors (facutly & tas as unique members) courses.cs.101.2007.2.02.students (matriculants & auditors as unique members) CS 103 1st semester 2007, section 1: courses.cs.103.2007.1.01.faculty courses.cs.103.2007.1.01.matriculants courses.cs.103.2007.1.01.auditors courses.cs.103.2007.1.01.instructors (facutly & tas as unique members) courses.cs.103.2007.1.01.students (matriculants & auditors as unique members) CS 103 1st semester 2007, section 2: courses.cs.103.2007.1.02.faculty courses.cs.103.2007.1.02.matriculants courses.cs.103.2007.1.02.auditors courses.cs.103.2007.1.02.instructors (facutly & tas as unique members) courses.cs.103.2007.1.02.students (matriculants & auditors as unique members) etc... All objects in the schema are ous except the terminal members of the tree, which are groups of unique members. The base groups (faculty, matriculants, auditors, etc.) have persons as unique members, and the derived groups (instructors, students, etc.) have groups as unique members. So by 'nested groups,' we have long branches of ous leading to groups of people and groups of subgroups. We need to be able to assign permissions to a Confluence object to all child members of any point of the schema. For example, there may be a Confluence space for all members of CS 101 in the 1st semester of 2007, so we'll need to grant access to that space by assigning all users in the ou, from the ou level (groups.courses.cs.101.2007.1), so that any new children of that ou, be they new ous or new groups or new person objects are automatically included in the ou as soon as they show up in ldap. Additionally, allowing a filter or wild card will be essential for some operations. For example: Read permission: courses.cs.101.2007.1 (all members of all groups in cs 101 1st semester 2007) Write permission: courses.cs.101.2007.1.*.instructors (instructors of cs 101 1st semester 2007 So the derived group of instructors for all sections of a course can write to an object, while students can read only. So this raises the question of forward references, since that would be a person-based means of looking up the various groups. I can imagine a design where Crowd or Confluence base permissions on a person attribute value in the form of ou=People.uid.memberOf=courses.cs.101.2007.1.*. This may be OK for runtime use (am I a member of group x), but I think it will be more efficient in the administration side to reverse the query and allow administrators to browse the ldap tree to find the correct node, with an option of listing members of the selected set, or at least the number of users. We may or may not wind up implementing forward references for all groups. We would prefer the flexibility to not, but we could work with that as a requirement. As if you need this to be more complicated, having an unfettered view of the ldap schema is not desired. There are groups and ous within the ldap schema that must remain private--both their membership as well as their existance, in some cases. Let's assume these will be labeled by acls in the ldap server, but that any interface that lists the schema will need to gracefully handle a case where a group may be listed, but its members may not be listable by the application. Alternatively, there is a simpler use case of residential dorms, which are sometimes defined as groups of physical buildings. So a schema for this use case would be: groups.dorms.cluster.building.floor.room Sample data: groups.dorms.undergrad_east.foo.1.112 groups.dorms.undergrad_east.foo.2.212 groups.dorms.undergrad_east.foo.3.couch groups.dorms.undergrad_east.bar.1.guest12 groups.dorms.west.grad12.11.1141

            Can you create an issue regarding your 'dynamic' groups feature request?

            Justen Stepka [Atlassian] added a comment - Can you create an issue regarding your 'dynamic' groups feature request?

            This build is slated for the first of the year.

            Justin Koke added a comment - This build is slated for the first of the year.

            wen will this next build be out?

            also - will this build be supporting "nested groups" or "dynamic groups". These are two completely different concepts. so which one will be available in this build

            • bhavin

            Bhavin Turakhia added a comment - wen will this next build be out? also - will this build be supporting "nested groups" or "dynamic groups". These are two completely different concepts. so which one will be available in this build bhavin

              Unassigned Unassigned
              jnolen Jonathan Nolen (Inactive)
              Votes:
              51 Vote for this issue
              Watchers:
              25 Start watching this issue

                Created:
                Updated:
                Resolved:

                  Estimated:
                  Original Estimate - 24h Original Estimate - 24h
                  24h
                  Remaining:
                  Remaining Estimate - 0h
                  0h
                  Logged:
                  Time Spent - 58h
                  58h