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

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

基本的な要素：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

優先順位 order-of-precedence

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

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

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

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

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

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

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

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

いくつかのレコメンデーションとベストプラクティスを次の表に示します。

ユーザー管理 user-administration

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

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

プロパティ

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

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

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

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

実行

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

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

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

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

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

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

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

プロパティの定義 defining-properties

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

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

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

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

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

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

偽装の定義 defining-an-impersonator

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

グループ管理 group-administration

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

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

プロパティ

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

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

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

メンバー

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

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

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

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

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

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

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

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

メンバー members

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

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

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

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

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

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

ポリシーの選択 policy-selection

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

権限 privileges

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

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

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

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

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

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

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

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

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