Group membership in Crowd not applying aggregation correctly

XMLWordPrintable

    • Type: Suggestion
    • Resolution: Unresolved
    • None
    • Component/s: Directories
    • None

      Problem

      We are using Crowd with multiple user directories and directory aggregation enabled for Jira and Confluence. The same usernames exist in more than one directory (for example, DirA and DirB).

      We have configured group‑level administration so that a group in one directory (for example, GroupAdmin in DirA) is a group admin of another group (for example, GroupDev in DirA). Users who are members of GroupAdmin should be able to manage membership of GroupDev.

      When we change the directory ordering so that another directory (DirB) becomes the primary/top directory, the user from DirB becomes the canonical user. At that point:

      • Group‑level admin rights configured in DirA no longer take effect, even though
      • The user's profile still shows membership in both groups via directory aggregation, and
      • The same user can still authenticate and be authorised correctly in Jira/Confluence based on aggregated memberships.

      In practice, this means that group‑level admin does not respect directory aggregation: group‑level admin privileges that exist in a secondary directory stop working as soon as a different directory becomes primary.

      Suggested Solution

      Provide a way for Crowd's group‑level administration to work consistently when:

      • Directory aggregation is enabled, and
      • The same user exists across multiple directories.

      Why This Is Important

      Many Crowd customers use multiple external directories with directory aggregation to present a unified set of users and groups to their applications. In these setups, it's often impractical to move or recreate all admin groups in the primary directory, and admins reasonably expect that if aggregation shows a user in an "admin group", their delegated admin rights will work regardless of which physical directory holds that group.

      The current behaviour causes unexpected loss of delegated admin rights when directory order changes, confusion for administrators (membership appears correct but admin actions fail), and extra operational overhead to redesign directory and group structures just to work around this limitation.

      Workaround

      (Add a workaround, if available)

              Assignee:
              Unassigned
              Reporter:
              Eleno Diaz
              Votes:
              1 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated: