ユーザー、グループおよびアクセス権限の管理 user-group-and-access-rights-administration

CRX リポジトリへのアクセスの有効化に関連するトピックは以下のとおりです。

基本的な要素:

ユーザーアカウント - CRX では、ユーザーアカウントに保持されている詳細情報に従って(特定の個人が、または別のアプリケーションを使用して)ユーザーを識別および検証し、アクセスを認証します。

CRX では、ユーザーアカウントはすべてワークスペース内のノードです。CRX ユーザーアカウントには次のプロパティがあります。

  • CRX の 1 人のユーザーを表します。

  • ユーザー名とパスワードが格納されます。

  • そのワークスペースに適用できます。

  • サブユーザーを含めることはできません。階層構造のアクセス権限の場合は、グループを使用する必要があります。

  • ユーザーアカウントのアクセス権限を指定できます。

    ただし、管理を簡略化するために、アドビでは(多くの場合)グループアカウントにアクセス権限を割り当てることをお勧めします。個々のユーザーにアクセス権限を割り当てると、管理が困難になります(インスタンスの数が 1 つか 2 つしかない状況におけるシステムユーザーは例外です)。

グループアカウント - グループアカウントは、ユーザーや他のグループの集合です。グループに割り当てられたアクセス権の変更は、そのグループ内のすべてのユーザーに自動的に適用されるので、グループを使用すると管理を簡略化できます。ユーザーはグループに属している必要はありませんが、多くの場合、複数のグループに属しています。

CRX では、グループには次のプロパティがあります。

  • 共通のアクセス権を持つユーザーのグループを表します。例えば、作成者や開発者などです。
  • そのワークスペースに適用できます。
  • メンバーを持つことができます。メンバーには、個々のユーザーや他のグループを指定できます。
  • 階層構造のグループ化は、メンバーの関係を使用することで実現できます。リポジトリ内の別のグループの直下にグループを配置することはできません。
  • すべてのグループメンバーのアクセス権を定義できます。

アクセス権限 - CRX では、アクセス権限を使用してリポジトリの特定の領域へのアクセスを制御します。

そのためには、リポジトリ内のリソース(ノードまたはパス)へのアクセスを許可または拒否する権限を割り当てます。割り当てることのできる権限は様々なので、権限を評価して、現在の要求に適用可能な組み合わせを判断する必要があります。

CRX では、ユーザーアカウントとグループアカウントの両方にアクセス権限を設定できます。その後、同じ評価の基本原則を両方に適用します。

アクセス権限の評価方法 how-access-rights-are-evaluated

NOTE
CRX は、JSR-283 で定義されるアクセス制御を実装しています。
CRX リポジトリの標準インストールは、リソースベースのアクセス制御リストを使用するように設定されます。これは、JSR-283 アクセス制御の実装と、Jackrabbit に存在する実装の 1 つとして考えられます。

件名とプリンシパル subjects-and-principals

CRX では、次に示す 2 つの主要な概念を使用してアクセス権限を評価します。

  • プリンシパル ​は、アクセス権を持つエンティティです。プリンシパルには次が含まれます。

    • ユーザーアカウント

    • グループアカウント

      1 つ以上のグループに属しているユーザーアカウントは、それらの各グループプリンシパルにも関連付けられます。

  • サブジェクト ​は、リクエストのソースを表すために使用されます。

    リクエストに適用されるアクセス権を統合するために使用されます。これらは次の場所から取得されます。

    • ユーザープリンシパル

      ユーザーアカウントに直接割り当てる権限。

    • ユーザーに関連付けられているすべてのグループプリンシパル

      すべての権限が、ユーザーが属するいずれかのグループに割り当てられています。

    結果は、リクエストされたリソースへのアクセスを許可または拒否するために使用されます。

サブジェクトのアクセス権限のリストを編集する compiling-the-list-of-access-rights-for-a-subject

CRX では、サブジェクトは以下の項目に依存します。

  • ユーザープリンシパル
  • そのユーザーに関連付けられているすべてのグループプリンシパル

サブジェクトに適用可能なアクセス権限のリストは、以下の要素から構成されます。

  • ユーザーアカウントに直接割り当てる権限
  • ユーザーが属するいずれかのグループに割り当てられているすべての権限

chlimage_1-56

NOTE
  • CRX では、リストを編集する際に、ユーザー階層が考慮されません。
  • CRX では、グループを別のグループのメンバーとして含める場合にのみ、グループ階層を使用します。グループの権限は自動的に継承されません。
  • グループを指定する順序は、アクセス権限に影響しません。

リクエストの解決とアクセス権限 resolving-request-and-access-rights

CRX では、リクエストを処理する場合、サブジェクトからのアクセスリクエストとリポジトリノードのアクセス制御リストを比較します。

次の図は、Linda が次のリポジトリ構造内の /features ノードの更新を要求する場合の処理を示しています。

chlimage_1-57

優先順位 order-of-precedence

CRX のアクセス権限は次のように評価されます。

  • 以下に関係なく、ユーザープリンシパルは常にグループプリンシパルよりも優先されます。

    • アクセス制御リスト内の順序
    • ノード階層内の位置
  • ある特定のプリンシパルに対して、特定のノードで存在する deny エントリと allow エントリはそれぞれ(最大で)1 つです。冗長なエントリは常に実装によってクリアされ、allow エントリと deny エントリに同じ権限が示されることはありません。

NOTE
この評価プロセスは、標準の CRX インストールのリソースベースのアクセス制御に適しています。

ユーザー aUser がグループ aGroup のメンバーである 2 つの例を次に示します。

   + parentNode
     + acl
       + ace: aUser - deny - write
     + childNode
       + acl
         + ace: aGroup - allow - write
       + grandChildNode

この場合、次のようになります。

  • aUser には grandChildNode に対する書き込み権限が付与されません。
   + parentNode
     + acl
       + ace: aUser - deny - write
     + childNode
       + acl
         + ace: aGroup - allow - write
         + ace: aUser - deny - write
       + grandChildNode

この場合の解決策は、次のとおりです。

  • aUser には grandChildNode に対する書き込み権限が付与されません。
  • aUser の 2 つ目の ACE は冗長になります。

複数のグループプリンシパルのアクセス権限は、階層内および単一のアクセス制御リスト内の両方で、その順序に基づいて評価されます。

ベストプラクティス best-practices

いくつかの推奨事項とベストプラクティスを次の表に示します。

推奨...
理由...
グループを使用する

アクセス権限をユーザーごとに割り当てないようにします。その理由は次の通りです。

  • グループ数よりもユーザー数の方がはるかに多く、グループを使用すると構造が簡素化されます。
  • グループはアカウント全体の概要を確認するのに役立ちます。
  • グループを使用すると、継承が簡単になります。
  • ユーザーは頻繁に追加および削除されます。グループは長期的に使用されます。
ポジティブに

グループプリンシパルのアクセス権限を指定するには、(可能な限り)常に「許可」ステートメントを使用します。「拒否」ステートメントの使用は避けてください。

グループプリンシパルは、階層内でも、単一のアクセス制御リスト内でも順番に評価されます。

シンプルに

新しいインストールの設定時にある程度時間をかけて検討すると、より良い設定となります。

わかりやすい構造を適用すると、継続的なメンテナンスと管理が簡単になり、現在の担当者と将来の後継者が実装されている内容を理解しやすくなります。

テスト
練習のためのテストインストールを利用して、様々なユーザーとグループ間の関係を把握してください。
デフォルトのユーザー/グループ
セキュリティ上の問題を防ぐために、必ずインストール直後にデフォルトのユーザーとグループを更新してください。

ユーザー管理 user-administration

標準ダイアログは​ ユーザー管理 ​に使用されます。

適切なワークスペースにログインする必要があり、ログインすると、次の両方の場所からダイアログにアクセスできるようになります。

  • CRX のメインコンソールの​ ユーザー管理 ​リンク
  • CRX Explorer の​ セキュリティ ​メニュー

chlimage_1-58

プロパティ

  • UserID

    CRX へのアクセス時に使用されるアカウントの省略名。

  • プリンシパル名

    アカウントの完全な名前。

  • パスワード

    このアカウントを使用して CRX にアクセスする場合に必要です。

  • ntlmhash

新しい各アカウントに自動的に割り当てられます。パスワードが変更されると更新されます。

  • 名前、タイプ、値を定義して新しいプロパティを追加できます。新しいプロパティごとに「保存」(緑色のチェックマーク)をクリックします。

グループのメンバーシップ

アカウントが属しているすべてのグループが表示されます。「継承」列は、別のグループのメンバーシップの結果として継承されたメンバーシップを示します。

グループ ID(使用可能な場合)をクリックすると、そのグループ用のグループ管理が開きます。

実行

別のユーザーとして実行する機能では、ユーザーは別のユーザーに成り代わって作業を行うことができます。

つまり、ユーザーアカウントは、自分のアカウントで操作できる他のアカウント(ユーザーまたはグループ)を指定できます。つまり、ユーザー B がユーザー A としての実行を許可されている場合、ユーザー B はユーザー A のアカウントの詳細(ID、名前、アクセス権を含む)をすべて使用して実行できます。

これにより、別のユーザーのアカウントを使用している場合と同様にタスクを完了できます。例えば、ユーザーの不在時や過剰な量の作業を短期間で分担する場合などに使用できます。

あるアカウントが別のアカウントとして実行する場合、その判別は非常に困難です。ログファイルには、そのイベントで、別のユーザーとして実行されたという事実に関する情報は含まれません。そのため、ユーザー B がユーザー A として実行している場合、ユーザー A がすべてのイベントを実行しているように見えます。

ユーザーアカウントの作成 creating-a-user-account

  1. ユーザー管理 ​ダイアログを開きます。

  2. ユーザーを作成」をクリックします。

  3. 次に、以下のプロパティを入力できます。

    • ユーザー ID:アカウント名として使用されます。
    • パスワード:ログイン時に必要です。
    • プリンシパル名:完全な名前を指定します。
    • 中間パス:ツリー構造を作成するために使用できます。
  4. 保存(緑色のチェックマーク)をクリックします。

  5. ダイアログボックスが展開され、次の操作が可能になります。

    1. プロパティ ​を設定します。
    2. グループのメンバーシップ」を確認します。
    3. 実行 ​を定義します。
NOTE
以下の項目の数がどちらも多いインストール環境で新しいユーザーを登録すると、パフォーマンスが低下する場合があります。
  • ユーザー
  • 多数のメンバーを持つグループ

ユーザーアカウントの更新 updating-a-user-account

  1. ユーザー管理 ​ダイアログボックスで、すべてのアカウントのリスト表示を開きます。
  2. ツリー構造内を移動します。
  3. 必要なアカウントをクリックして、編集用に開きます。
  4. 変更を加え、そのエントリの保存(緑色のチェックマーク)をクリックします。
  5. 閉じる」をクリックして終了するか、「リスト…」をクリックしてすべてのユーザーアカウントのリストに戻ります。

ユーザーアカウントの削除 removing-a-user-account

  1. ユーザー管理 ​ダイアログボックスで、すべてのアカウントのリスト表示を開きます。
  2. ツリー構造内を移動します。
  3. 必要なアカウントを選択し、「ユーザーを削除」をクリックします。アカウントはすぐに削除されます。
NOTE
これにより、このプリンシパルのノードがリポジトリから削除されます。
アクセス権限のエントリは削除されません。これにより、履歴の整合性が確保されます。

プロパティの定義 defining-properties

新規または既存のアカウントの​ プロパティ ​を定義できます。

  1. 適切なアカウントの​ ユーザー管理 ​ダイアログを開きます。
  2. プロパティ ​名を定義します。
  3. ドロップダウンリストから「タイプ」を選択します。
  4. ​を定義します。
  5. 新しいプロパティの「保存」(緑色のチェックマーク)をクリックします。

既存のプロパティは、ごみ箱アイコンを使用して削除できます。

パスワード以外のプロパティは編集できません。削除して再作成する必要があります。

パスワードの変更 changing-the-password

パスワード ​は、パスワードの変更 ​リンクをクリックして変更できる特別なプロパティです。

CRX Explorer の​ セキュリティ ​メニューからパスワードを自分のユーザーアカウントに変更することもできます。

偽装の定義 defining-an-impersonator

新規または既存のアカウントを他のユーザーとして実行するユーザーを定義できます。

  1. 適切なアカウントの​ ユーザー管理 ​ダイアログを開きます。

  2. 別のユーザーとして実行を許可するアカウントを指定します。

    「参照…」を使用して、既存のアカウントを選択できます。

  3. 新しいプロパティの「保存」(緑色のチェックマーク)をクリックします。

グループ管理 group-administration

グループ管理 ​には標準ダイアログが使用されます。

適切なワークスペースにログインする必要があり、ログインすると、次の両方の場所からダイアログにアクセスできるようになります。

  • CRX のメインコンソールの​ グループ管理 ​リンク
  • CRX Explorer の​ セキュリティ ​メニュー

chlimage_1-8

プロパティ

  • GroupID

    グループアカウントの省略名。

  • プリンシパル名

    グループアカウントの完全な名前。

  • 名前、タイプ、値を定義して新しいプロパティを追加できます。新しいプロパティごとに「保存」(緑色のチェックマーク)をクリックします。

  • メンバー

    グループのメンバーとして、ユーザーまたは他のグループを追加できます。

グループのメンバーシップ

現在のグループアカウントが属しているすべてのグループが表示されます。「継承」列は、別のグループのメンバーシップの結果として継承されたメンバーシップを示します。

グループ ID をクリックすると、そのグループのダイアログボックスが開きます。

メンバー

現在のグループのメンバーであるすべてのアカウント(ユーザーまたはグループ)が一覧表示されます。

継承 ​列は、別のグループのメンバーシップの結果として継承されたメンバーシップを示します。

NOTE
いずれかのアセットフォルダーでユーザーに対して所有者、編集者または閲覧者の役割が割り当てられると、新しいグループが作成されます。役割が定義された各フォルダーのグループ名は mac-default-<foldername> の形式となります。

グループアカウントの作成 creating-a-group-account

  1. グループ管理 ​ダイアログを開きます。

  2. グループを作成」をクリックします。

  3. 次に、以下のプロパティを入力できます。

    • プリンシパル名:完全な名前を指定します。
    • 中間パス:ツリー構造を作成するために使用できます。
  4. 保存(緑色のチェックマーク)をクリックします。

  5. ダイアログボックスが展開され、次の操作が可能になります。

    1. プロパティ ​を設定します。
    2. グループのメンバーシップ」を確認します。
    3. メンバー ​を管理します。

グループアカウントの更新 updating-a-group-account

  1. グループ管理 ​ダイアログボックスで、すべてのアカウントのリスト表示を開きます。
  2. ツリー構造内を移動します。
  3. 必要なアカウントをクリックして、編集用に開きます。
  4. 変更を加え、そのエントリの保存(緑色のチェックマーク)をクリックします。
  5. 閉じる」をクリックして終了するか、「リスト…」をクリックしてすべてのグループアカウントのリストに戻ります。

グループアカウントの削除 removing-a-group-account

  1. グループ管理 ​ダイアログボックスで、すべてのアカウントのリスト表示を開きます。
  2. ツリー構造内を移動します。
  3. 必要なアカウントを選択し、「グループを削除」をクリックします。アカウントはすぐに削除されます。
NOTE
これにより、このプリンシパルのノードがリポジトリから削除されます。
アクセス権限のエントリは削除されません。これにより、履歴の整合性が確保されます。

プロパティの定義 defining-properties-1

新規または既存のアカウントのプロパティを定義できます。

  1. 適切なアカウントの​ グループ管理 ​ダイアログを開きます。
  2. プロパティ ​名を定義します。
  3. ドロップダウンリストから「タイプ」を選択します。
  4. ​を定義します。
  5. 新しいプロパティの「保存」(緑色のチェックマーク)をクリックします。

既存のプロパティは、ごみ箱アイコンを使用して削除できます。

メンバー members

現在のグループにメンバーを追加できます。

  1. 適切なアカウントの​ グループ管理 ​ダイアログを開きます。

  2. 以下のどちらかの操作を行います。

    • 必要なメンバーの名前(ユーザーまたはグループアカウント)を入力します。
    • または「参照…」を使用して、追加するプリンシパル(ユーザーまたはグループアカウント)を検索し、選択します。
  3. 新しいプロパティの「保存」(緑色のチェックマーク)をクリックします。

または、ごみ箱アイコンを使用して既存のメンバーを削除します。

アクセス権限の管理 access-right-management

CRXDE Lite の「アクセス制御」タブを使用して、アクセス制御ポリシーを定義し、関連する権限を割り当てることができます。

例えば、右下のウィンドウの「アクセス制御」タブにある「現在のパス」では、必要なリソースを左側のウィンドウで選択します。

crx_accesscontrol_tab

ポリシーは次のように分類されます。

  • 適用可能なアクセス制御ポリシー

    これらのポリシーは適用できます。

    これらのポリシーは、ローカルポリシーの作成に使用できます。適用可能なポリシーを選択して追加すると、そのポリシーがローカルポリシーになります。

  • ローカルアクセス制御ポリシー

    これらは、適用したアクセス制御ポリシーです。このポリシーの更新、並べ替えまたは削除を行うことができます。

    親から継承したポリシーはローカルポリシーによって上書きされます。

  • 有効なアクセス制御ポリシー

    アクセス要求に対して有効なアクセス制御ポリシーです。ローカルポリシーおよび親から継承したポリシーから派生した集計ポリシーが表示されます。

ポリシーの選択 policy-selection

次の項目用のポリシーを選択できます。

  • 現在のパス

    前述の例では、リポジトリ内のリソースを選択します。この「現在のパス」用のポリシーが表示されます。

  • リポジトリ

    リポジトリレベルのアクセス制御を選択します。例えば、ノードではなくリポジトリにのみ関連する jcr:namespaceManagement 権限を設定する場合などに使用します。

  • プリンシパル

    リポジトリに登録されているプリンシパルです。

    プリンシパル ​名を入力するか、フィールドの右側にあるアイコンをクリックして、プリンシパルを選択 ​ダイアログボックスを開きます。

    これにより、ユーザー ​または​ グループ ​を​ 検索 ​できます。表示されるリストから必要なプリンシパルを選択し、「OK」をクリックして値を前のダイアログボックスに戻します。

crx_accesscontrol_selectprincipal

NOTE
管理を簡素化するために、個々のユーザーアカウントではなく、グループアカウントにアクセス権を割り当てることをお勧めします。
多数のユーザーアカウントよりも、少数のグループの方が管理しやすくなります。

権限 privileges

アクセス制御エントリを追加する場合は、以下に示す権限を選択できます(詳しくは、セキュリティ API に関するページを参照)。

権限名
制御する権限
jcr:read
ノードを取得して、そのプロパティと値を読み取ります。
rep:write
jcr:write および jcr:nodeTypeManagement の Jackrabbit 専用の集計権限です。
jcr:all
他の事前定義済み権限がすべて含まれる集計権限です。
詳細
crx:replicate
ノードのレプリケーションを実行します。
jcr:addChildNodes
ノードの子ノードを作成します。
jcr:lifecycleManagement
ノード上でライフサイクル操作を実行します。
jcr:lockManagement
ノードをロックおよびロック解除します。ロックを更新します。
jcr:modifyAccessControl
ノードのアクセス制御ポリシーを変更します。
jcr:modifyProperties
ノードのプロパティを作成、変更および削除します。
jcr:namespaceManagement
名前空間の定義を登録、登録解除および変更します。
jcr:nodeTypeDefinitionManagement
ノードタイプ定義をリポジトリに読み込みます。
jcr:nodeTypeManagement
mixin ノードタイプを追加および削除し、ノードのプライマリノードタイプを変更します。また、Node.addNode および XML 読み込みメソッドの呼び出しも含まれ、mixin または新しいノードのプライマリ型が明示的に指定されます。
jcr:readAccessControl
ノードのアクセス制御ポリシーを読み取ります。
jcr:removeChildNodes
ノードの子ノードを削除します。
jcr:removeNode
ノードを削除します。
jcr:retentionManagement
ノード上で保持管理操作を実行します。
jcr:versionManagement
ノード上でバージョン管理操作を実行します。
jcr:workspaceManagement
JCR API によるワークスペースの作成と削除。
jcr:write
次の権限が含まれる集計権限です。
- jcr:modifyProperties
- jcr:addChildNodes
- jcr:removeNode
- jcr:removeChildNodes
rep:privilegeManagement
新しい権限を登録します。

新しい権限の登録 registering-new-privileges

新しい権限を登録することもできます。

  1. ツールバーから「ツール」を選択し、続いて「権限」を選択して、現在登録されている権限を表示します。

    ac_privileges

  2. 権限を登録 ​アイコン(+)を使用して、権限を定義できます。

    ac_privilegeregister

  3. OK」をクリックして保存します。これで、権限を選択できるようになりました。

アクセス制御エントリの追加 adding-an-access-control-entry

  1. リソースを選択して「アクセス制御」タブを開きます。

  2. 新しい​ ローカルアクセス制御ポリシー ​を追加するには、「適用可能なアクセス制御ポリシー」リストの右側にある + アイコンをクリックします。

    crx_accesscontrol_applicable

  3. 新しいエントリが「「ローカルアクセス制御ポリシー」の下に表示されます。。

    crx_accesscontrol_newlocal

  4. + アイコンをクリックして、エントリを追加できます。

    crx_accesscontrol_addentry

    note note
    NOTE
    現時点では、空の文字列を指定するには対策が必要です。
    このためには、"" を使用する必要があります。
  5. アクセス制御ポリシーを定義し、「OK」をクリックして保存します。新しいポリシーは、以下のようになります。

    • ローカルアクセス制御ポリシー」の下に表示されます。
    • 有効なアクセス制御ポリシー」に変更が反映されます。

CRX が選択を検証します。特定のプリンシパルに対して、特定のノードで存在する deny エントリと allow エントリはそれぞれ(最大で)1 つです。冗長なエントリは常に実装によってクリアされ、allow エントリと deny エントリに同じ権限が示されることはありません。

ローカルアクセス制御ポリシーの順序付け ordering-local-access-control-policies

リスト内の順序は、ポリシーの適用順序を示します。

  1. ローカルアクセス制御ポリシー」のテーブルで必要なエントリを選択して、テーブル内の新しい位置にドラッグします。

    crx_accesscontrol_reorder

  2. ローカルアクセス制御ポリシー」と「有効なアクセス制御ポリシー」のテーブルの両方に変更が表示されます。

アクセス制御ポリシーの削除 removing-an-access-control-policy

  1. ローカルアクセス制御ポリシー」のテーブルで、エントリの右側にある赤いアイコン(-)をクリックします。
  2. ローカルアクセス制御ポリシー」と「有効なアクセス制御ポリシー」のテーブルの両方からエントリが削除されます。

アクセス制御ポリシーのテスト testing-an-access-control-policy

  1. CRXDE Lite のツールバーから「ツール」、「アクセス制御をテスト」の順に選択します。

  2. 右上のウィンドウに新しいダイアログが開きます。テストする​ パス ​や​ プリンシパル ​を選択します。

  3. テスト」をクリックして選択項目の結果を確認します。

    crx_accesscontrol_test

recommendation-more-help
19ffd973-7af2-44d0-84b5-d547b0dffee2