CRX リポジトリへのアクセスを有効にするには、次の複数のトピックが含まれます。
アクセス権 — 定義および評価方法に関する概念
ユーザー管理 — アクセスに使用する個々のアカウントの管理
グループ管理 - グループの作成によるユーザー管理の簡略化
アクセス権限の管理 - ユーザーとグループがリソースにアクセスする方法を制御するポリシーの定義
基本的な要素:
ユーザーアカウント CRX では、ユーザーアカウントに保持されている詳細情報に従って(特定の個人が、または別のアプリケーションを使用して)ユーザーを識別および検証し、アクセスを認証します。
CRX では、すべてのユーザーアカウントはワークスペース内のノードです。 CRX ユーザーアカウントには次のプロパティがあります。
CRX の 1 人のユーザーを表します。
ユーザー名とパスワードが格納されます。
そのワークスペースに適用できます。
サブユーザーを含めることはできません。 階層アクセス権の場合は、グループを使用する必要があります。
ユーザーアカウントのアクセス権限を指定できます。
ただし、管理を簡略化するために、(多くの場合)グループアカウントにアクセス権限を割り当てることをお勧めします。個々のユーザーにアクセス権限を割り当てると、管理が非常に困難になります(インスタンスの数が 1 つか 2 つしかない状況におけるシステムユーザーは例外です)。
グループアカウント グループアカウントは、ユーザーまたは他のグループの集合です。グループに割り当てられたアクセス権の変更は、そのグループ内のすべてのユーザーに自動的に適用されるので、これらを使用して管理を簡略化できます。 ユーザーはどのグループにも属している必要はありませんが、多くの場合、複数のグループに属しています。
CRX では、グループには次のプロパティがあります。
共通のアクセス権を持つユーザーのグループを表します。 例えば、作成者や開発者などです。
そのワークスペースに適用できます。
メンバーを持つことができます。個々のユーザーや他のグループを指定できます。
階層グループ化は、メンバーの関係を使用して実現できます。 リポジトリ内の別のグループのすぐ下にグループを配置することはできません。
すべてのグループメンバーのアクセス権を定義できます。
アクセス権限 CRX では、アクセス権限を使用してリポジトリの特定の領域へのアクセスを制御します。
そのためには、リポジトリ内のリソース(ノードまたはパス)へのアクセスを許可または拒否する権限を割り当てます。割り当てることのできる権限は様々なので、権限を評価して、現在の要求に適用可能な組み合わせを判断する必要があります。
CRX では、ユーザーアカウントとグループアカウントの両方にアクセス権を設定できます。 その後、同じ評価の基本原則を両方に適用します。
CRX 実装 JSR-283 で定義されるアクセス制御.
CRX リポジトリの標準インストールは、リソースベースのアクセス制御リストを使用するように設定されます。 これは、JSR-283 アクセス制御の実装と、Jackrabbit に存在する実装の 1 つとして考えられます。
CRX では、次に示す 2 つの主要な概念を使用してアクセス権限を評価します。
A 元本 は、アクセス権を持つエンティティです。 プリンシパルには次が含まれます。
ユーザーアカウント.
グループアカウント
1 つ以上のグループに属しているユーザーアカウントは、それらの各グループプリンシパルにも関連付けられます。
サブジェクトは、リクエストのソースを表すために使用されます。
リクエストに適用されるアクセス権を統合するために使用されます。これらは次の場所から取得されます。
ユーザープリンシパル
ユーザーアカウントに直接割り当てる権限。
ユーザーに関連付けられているすべてのグループプリンシパル
ユーザーが属するいずれかのグループに割り当てられているすべての権限。
結果は、リクエストされたリソースへのアクセスを許可または拒否するために使用されます。
CRX では、件名は次の項目に依存します。
対象に適用されるアクセス権のリストは、次の要素から構成されます。
CRX が要求を処理する際には、主体からのアクセス要求とリポジトリノード上のアクセス制御リストを比較します。
次の図は、Linda が次のリポジトリ構造内の /features
ノードの更新を要求する場合の処理を示しています。
CRX のアクセス権は次のように評価されます。
ユーザープリンシパルは、以下に関係なく、常にグループプリンシパルよりも優先されます。
特定のプリンシパルに対して、特定のノードに deny エントリと allow エントリが(最大で)1 つ存在します。 冗長なエントリは常に実装によってクリアされ、allow エントリと deny エントリに同じ権限が示されることはありません。
この評価プロセスは、標準の 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 は冗長になります。
複数のグループプリンシパルからのアクセス権は、階層内と単一のアクセス制御リスト内の順序に基づいて評価されます。
いくつかの推奨事項とベストプラクティスを次の表に示します。
推奨... | 理由... |
グループを使用する | アクセス権をユーザーごとに割り当てないようにします。 これには、いくつかの理由があります。
|
ポジティブに | 常に Allow ステートメントを使用して、グループプリンシパルのアクセス権を指定します(可能な場合)。 「拒否」ステートメントの使用は避けてください。 グループプリンシパルは、階層内でも、単一のアクセス制御リスト内でも順番に評価されます。 |
シンプルに | 新しいインストールの設定時にある程度時間をかけて検討すると、より良い設定となります。 明確な構造を適用すると、継続的なメンテナンスと管理が簡単になり、現在の同僚や将来の後継者が実装されている内容を容易に理解できるようになります。 |
テスト | 練習のためのテストインストールを利用して、様々なユーザーとグループ間の関係を把握してください。 |
デフォルトのユーザー/グループ | セキュリティ上の問題を防ぐため、インストール直後に必ずデフォルトのユーザーとグループを更新してください。 |
標準ダイアログはユーザー管理に使用されます。
適切なワークスペースにログインする必要があります。その後、次の両方からダイアログにアクセスできます。
プロパティ
UserID
CRX へのアクセス時に使用される、アカウントの短い名前。
プリンシパル名
アカウントのフルテキスト名。
パスワード
このアカウントで CRX にアクセスする際に必要です。
ntlmhash
新しいアカウントごとに自動的に割り当てられ、パスワードが変更されると更新されます。
名前、タイプ、値を定義して新しいプロパティを追加できます。新しいプロパティごとに「保存」(緑色のチェックマーク)をクリックします。
グループのメンバーシップアカウントが属しているすべてのグループが表示されます。「継承」列は、別のグループのメンバーシップの結果として継承されたメンバーシップを示します。
グループ ID(使用可能な場合)をクリックすると、そのグループ用のグループ管理が開きます。
実行別のユーザーとして実行する機能では、ユーザーは別のユーザーに成り代わって作業を行うことができます。
これは、あるユーザーアカウントが操作を行うための他のアカウント(ユーザーまたはグループ)を指定できることを意味します。つまり、ユーザー B がユーザー A として実行することを許可されている場合、ユーザー B はユーザー A のアカウントの詳細(ID、名前、アクセス権限を含む)をすべて使用してアクションを実行できます。
これにより、別のユーザーアカウントが、別のユーザーとして実行しているアカウントを使用している場合と同様に、タスクを完了できます。例えば、不在時や過剰な負荷を短期間共有する場合などです。
アカウントが別のアカウントになりすます場合、表示は非常に困難です。 ログファイルには、イベントで偽装が発生したことに関する情報は含まれません。 したがって、ユーザー B がユーザー A として実行している場合、すべてのイベントは、ユーザー A が個人的に実行したかのように見えます。
を開きます。 ユーザー管理 ダイアログ。
「ユーザーを作成」をクリックします。
次のプロパティを入力できます。
保存(緑色のチェックマーク)をクリックします。
ダイアログが展開され、次の操作が可能になります。
次の両方が多数あるインストールで新しいユーザーを登録すると、パフォーマンスが低下する場合があります。
ユーザー管理ダイアログで、すべてのアカウントのリスト表示を開きます。
ツリー構造内を移動します。
編集用に開く必要のあるアカウントをクリックします。
変更を加え、そのエントリの保存(緑のチェックマーク)をクリックします。
クリック 閉じる 終了するか、または リスト… をクリックして、すべてのユーザーアカウントのリストに戻ります。
ユーザー管理ダイアログで、すべてのアカウントのリスト表示を開きます。
ツリー構造内を移動します。
必要なアカウントを選択し、 ユーザーを削除;アカウントは直ちに削除されます。
これにより、このプリンシパルのノードがリポジトリから削除されます。
アクセス権限のエントリは削除されません。これにより、履歴の整合性が確保されます。
次の項目を定義できます。 プロパティ 新規または既存のアカウントの場合:
既存のプロパティは、ごみ箱シンボルで削除できます。
パスワードを除き、プロパティは編集できません。削除して再作成する必要があります。
この パスワード は、 パスワードを変更 リンク。
また、 セキュリティ 」メニューを使用します。
次のように、新規または既存のアカウントに対して次のように実行を定義できます。
を開きます。 ユーザー管理 適切なアカウントのダイアログ。
別のユーザーとして実行を許可するアカウントを指定します。
「参照…」を使用して、既存のアカウントを選択できます。
新しいプロパティの [ 保存 ] (緑のチェックマーク)をクリックします。
標準ダイアログは、 グループ管理.
適切なワークスペースにログインする必要があります。その後、次の両方からダイアログにアクセスできます。
プロパティ
GroupID
グループアカウントの省略名。
プリンシパル名
グループアカウントのフルテキスト名。
名前、タイプ、値を定義して新しいプロパティを追加できます。新しいプロパティごとに「保存」(緑色のチェックマーク)をクリックします。
メンバー
ユーザーや他のグループを、このグループのメンバーとして追加できます。
グループメンバーシップ 現在のグループアカウントが属するすべてのグループが表示されます。 「継承」列は、別のグループのメンバーシップの結果として継承されたメンバーシップを示します。
グループ ID をクリックすると、そのグループ用のダイアログが開きます。
メンバー 現在のグループのメンバーであるすべてのアカウント(ユーザーまたはグループ)が一覧表示されます。
この 継承 列は、別のグループのメンバーシップの結果として継承されたメンバーシップを示します。
いずれかのアセットフォルダーでユーザーに対して所有者、編集者または閲覧者の役割が割り当てられると、新しいグループが作成されます。役割が定義された各フォルダーのグループ名は mac-default-<foldername>
の形式となります。
を開きます。 グループ管理 ダイアログ。
クリック グループを作成.
次のプロパティを入力できます。
保存(緑色のチェックマーク)をクリックします。
ダイアログが展開され、次の操作が可能になります。
グループ管理ダイアログで、すべてのアカウントのリスト表示を開きます。
ツリー構造内を移動します。
編集用に開く必要のあるアカウントをクリックします。
変更を加え、そのエントリの保存(緑のチェックマーク)をクリックします。
クリック 閉じる 終了するか、または リスト… をクリックして、すべてのグループアカウントのリストに戻ります。
グループ管理ダイアログで、すべてのアカウントのリスト表示を開きます。
ツリー構造内を移動します。
必要なアカウントを選択し、 グループを削除;アカウントは直ちに削除されます。
これにより、このプリンシパルのノードがリポジトリから削除されます。
アクセス権限のエントリは削除されません。これにより、履歴の整合性が確保されます。
新規または既存のアカウントのプロパティを定義できます。
既存のプロパティは、ごみ箱シンボルで削除できます。
現在のグループにメンバーを追加できます。
を開きます。 グループ管理 適切なアカウントのダイアログ。
以下のどちらかの操作を行います。
新しいプロパティの [ 保存 ] (緑のチェックマーク)をクリックします。
または、ごみ箱記号を含む既存のメンバを削除します。
CRXDE Lite の「アクセス制御」タブを使用して、アクセス制御ポリシーを定義し、関連する権限を割り当てることができます。
例えば、右下のウィンドウの「アクセス制御」タブにある「現在のパス」では、必要なリソースを左側のウィンドウで選択します。
ポリシーは次のように分類されます。
適用可能なアクセス制御ポリシーこれらのポリシーは適用できます。
これらのポリシーは、ローカルポリシーの作成に使用できます。適用可能なポリシーを選択して追加すると、そのポリシーがローカルポリシーになります。
ローカルアクセス制御ポリシーこれらは、適用したアクセス制御ポリシーです。このポリシーの更新、並べ替えまたは削除を行うことができます。
親から継承したポリシーはローカルポリシーによって上書きされます。
有効なアクセス制御ポリシーアクセス要求に対して有効なアクセス制御ポリシーです。ローカルポリシーおよび親から継承したポリシーから派生した集計ポリシーが表示されます。
次の項目用のポリシーを選択できます。
現在のパス前述の例では、リポジトリ内のリソースを選択します。この「現在のパス」用のポリシーが表示されます。
リポジトリリポジトリレベルのアクセス制御を選択します。例えば、
jcr:namespaceManagement
権限。ノードではなく、リポジトリにのみ関連します。
プリンシパル
リポジトリに登録されているプリンシパルです。
プリンシパル名を入力するか、フィールドの右側にあるアイコンをクリックして、プリンシパルを選択ダイアログを開きます。
これにより、ユーザーまたはグループを検索できます。表示されるリストから必要なプリンシパルを選択し、「OK」をクリックして値を前のダイアログに戻します。
管理を簡素化するには、個々のユーザーアカウントではなく、グループアカウントにアクセス権を割り当てることをお勧めします。
多数のユーザーアカウントよりも、少数のグループを管理するほうが簡単です。
アクセス制御エントリを追加する場合は、以下に示す権限を選択できます(詳しくは、セキュリティ 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 |
新しい権限を登録します。 |
新しい権限を登録することもできます。
ツールバーから「ツール」を選択し、「権限」を選択して、現在登録されている権限を表示します。
権限を登録アイコン(+)を使用してダイアログを開き、新しい権限を定義します。
「OK」をクリックして保存します。これで、権限を選択できるようになります。
リソースを選択して「アクセス制御」タブを開きます。
新しいローカルアクセス制御ポリシーを追加するには、「適用可能なアクセス制御ポリシー」リストの右側にある + アイコンをクリックします。
新しいエントリが「「ローカルアクセス制御ポリシー」の下に表示されます。。
+ アイコンをクリックして新しいエントリを追加します。
現時点では、空の文字列を指定するには対策が必要です。
"" を使用してください。
アクセス制御ポリシーを定義し、 OK 保存します。 新しいポリシーでは、次のことが行われます。
CRX が選択を検証します。特定のプリンシパルに対しては、特定のノードに deny エントリと allow エントリが(最大で)1 つ存在します。 冗長なエントリは常に実装によってクリアされ、allow エントリと deny エントリに同じ権限が示されることはありません。
リスト内の順序は、ポリシーの適用順序を示します。
「ローカルアクセス制御ポリシー」のテーブルで必要なエントリを選択して、テーブル内の新しい位置にドラッグします。
「ローカルアクセス制御ポリシー」と「有効なアクセス制御ポリシー」のテーブルの両方に変更が表示されます。
「ローカルアクセス制御ポリシー」のテーブルで、エントリの右側にある赤いアイコン(-)をクリックします。
「ローカルアクセス制御ポリシー」と「有効なアクセス制御ポリシー」のテーブルの両方からエントリが削除されます。
CRXDE Lite のツールバーから「ツール」、「アクセス制御をテスト」の順に選択します。
右上のウィンドウに新しいダイアログが開きます。テストするパスまたはプリンシパルを選択します。
「テスト」をクリックして選択項目の結果を確認します。