入れ子グループの効果

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

ログイン

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.

権限

ユーザーが必要な権限を持つグループに属している場合、またはそのサブグループに属している場合、機能へのアクセスが許可されます。

グループ メンバーのリストを表示する

グループのメンバーを表示しようとする場合、グループの全ユーザー、およびそのサブグループに属するすべてのユーザーが1つのリストにまとめられて表示されます。このリストを「フラット」リストと呼びます。

入れ子グループ自身を表示、編集することはできません。1つのグループが別のグループのメンバーであることを確認することはできません。

グループ メンバーを追加、更新する

グループにユーザーを追加する場合、ユーザーは指定したグループに追加され、他のグループには追加されません。

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

  • ユーザーが、フラットリストに含まれるグループのヒエラルキー（ツリー）の一番上のグループのメンバーである場合、ユーザーはグループから削除されます。
  • そうでない場合、ユーザーがグループの直接のメンバーではないことを示すエラー メッセージが表示されます。

例

例1：ユーザーがサブグループのメンバーである

以下の2つのグループがディレクトリ サーバーに存在すると仮定します。

  • staff
  • marketing

メンバーシップ：

  • 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.

例2：「jira-developers」グループのメンバーとしてのサブグループ

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.

  • 「jira-developers」というグループを追加します。
  • 「jira-developers」のサブグループとして「engineering-group」を追加します。
  • 「jira-developers」のサブグループとして「techwriters-group」を追加します。

グループのメンバーシップは現在、以下のようになっています。

  • jira-developers — サブグループ： engineering-group、techwriters-group
  • engineering-group — サブグループ： dev-a、dev-b、ユーザ： pblack
  • dev-a — ユーザー： jsmith、sbrown
  • dev-b — ユーザー： jsmith、dblue
  • techwriters-group — ユーザー：rgreen

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

  • pblack
  • jsmith
  • sbrown
  • dblue
  • rgreen


図： 「jira-developers」グループのメンバーとしてのサブグループ

入れ子グループ GliffyDiagram-JIRA

例3：「confluence-users」グループのメンバーとしてのサブグループ

LDAP ディレクトリ サーバーに、「engineering-group」と「payroll-group」の2つのグループがあります。両グループに Confluence サイトへのアクセスを許可したいと考えています。

  • 「confluence-users」というグループを追加します。
  • 「confluence-users」のサブグループとして「engineering-group」を追加します。
  • 「confluence-users」のサブグループとして「payroll-group」を追加します。

グループのメンバーシップは現在、以下のようになっています。

  • confluence-users — サブグループ： engineering-group、payroll-group
  • engineering-group — サブグループ： dev-a、dev-b、ユーザ： pblack
  • dev-a — ユーザー： jsmith、sbrown
  • dev-b — ユーザー： jsmith、dblue
  • payroll-group — ユーザー：rgreen

Confluence が「confluence-users」グループのユーザー一覧をリクエストした場合、以下の一覧が返却されます。

  • pblack
  • jsmith
  • sbrown
  • dblue
  • rgreen


図： 「confluence-users」グループのメンバーとしてのサブグループ

入れ子グループ GliffyDiagram

注意

  • パフォーマンスに影響を与える可能性。入れ子グループを有効にすると、ユーザー検索が遅くなる可能性があります。
  • 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: 
    member=CN=John Smith,OU=Users,OU=OrgUnitA,DC=sub,DC=domain
member=CN=Group Two,OU=OrgUnitBGroups,OU=OrgUnitB,DC=sub,DC=domain
  • ラベルなし