|
This build is slated for the first of the year.
Can you create an issue regarding your 'dynamic' groups feature request?
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)) 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: Derived groups: Sample data: CS 101 1st semester 2007, section 1: CS 101 1st semester 2007, section 2: CS 101 2nd semester 2007, section 1: CS 101 2nd semester 2007, section 2: CS 103 1st semester 2007, section 1: CS 103 1st semester 2007, section 2: 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) 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: 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. When will this issue be implemented?
This is an essential feature in an enterprise setting with Crowd. 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. 
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.
> Ops is very resistant to crowd because this feature is missing.
And they are right. This also affects OpenDirectory
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.
+1 vote, this really is an essential feature.
Hi All,
The 1.4 release of Crowd will support Nested Groups. There are some things you should be aware of:
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! 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 Dave. 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.
Yes, loading of all members will be included. So you shouldn't need '980.
will this soon affect confluence also ?
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, 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?
Abundantly. Thanks for taking the time to draw out the diagrams. It made your question very easy to understand
Yep! That's the primary use-case. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Resolved
Blocker
Support groups-within-groups
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