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