現在表示中:

CRX 1.4.x から CRX 2.0 にかけて(つまり CQ 5.2 から CQ 5.3 にかけて)、セキュリティモデルに変更が加えられました。アップグレード手順によって、ほぼすべてのインストールで、これらの変更のほとんどに対する補正が実施されるので、通常はそれ以上のアクションは必要ありません。

ただし、一部の変更についてアップグレード手順によって対応できず、既存のインストールに影響を及ぼす可能性があります。ここでは、そのような変更に対応するための方法を示します。

注意:

このページでは、セキュリティの概念について非常に詳しく説明しており、5.3 より前の CQ5 バージョンおよび 2.0 より前の CRX バージョンのセキュリティモデルに関する深い理解と、アクセス制御管理の分野における新しい JCR 2.0 標準の知識、Jackrabbit 2.0 の新しいセキュリティ、ACL、ユーザー管理 API に関する知識および一般的な開発に関する知識が必要になります。

このページは、セキュリティ分野における CQ 5.3/CRX 2.0 へのアップグレードに関する疑問が生じた場合の補助リソースとして使用することを想定しています。

アクセス制御評価

アクセス制御評価(ACE)が CRX 1.4.x から CRX 2.0 にかけて変更されました。主な変更点は次のとおりです。

CRX 1.4.x

  • ACE は、アクセス制御リスト(ACL)での順序に基づいて厳格に評価されます。
  • ローカル ACE は、階層的に離れた ACE よりも優先されます。
  • GUI での編集時に、ユーザーの ACE が ACL に挿入され、グループプリンシパル用の ACE よりもユーザーの ACE が優先されます。これは、ACE の並べ替えによって変更できます。
  • 冗長な ACE を作成でき、そのような ACE はアクセス制御実装からはクリアされません。評価順は最終結果に基づいて決定されます。クリーンアップは UI ヘルパークラスによって実行されます。

CRX 2.0

  • 以下に関係なく、ユーザープリンシパルの ACE が常にグループプリンシパル ACE よりも優先されます。
    • ACL 内の順序
    • ノード階層内の位置
  • ある特定のプリンシパルに対して、あるノードで存在する deny エントリと allow エントリはそれぞれ 1 つまでです。冗長なエントリは常に実装によってクリアされ、allow と deny に同じ権限が示されることはありません。

次に例を示します。

ユーザー aUser がグループ aGroup のメンバーの場合:

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

以前のバージョンの場合:

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

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

  • CRX 1.4:
    • grandChildNode に対する aUser の書き込み権限は、childNode での ACE の順序によって決定されます。
  • CRX 2.0:
    • aUser には grandChildNode に対する書き込み権限が付与されません。
    • aUser の 2 つ目の ACE は冗長になります。

以前の CRX ActionSet と新しい JCR 権限のマッピング

現在のマッピングは CqActions コードモジュールで定義されており、以前のマッピングに最も近く一致するように選択されています。

ActionSet JCR 権限 一致 コメント
read JCR_READ +  
set_property JCR_MODIFY_PROPERTIES
JCR_LOCK_MANAGEMENT
JCR_VERSION_MANAGEMENT
+- [1]
add_node JCR_ADD_CHILD_NODES
JCR_NODE_TYPE_MANAGEMENT
+ [2]
remove JCR_REMOVE_CHILD_NODES
JCR_REMOVE_NODE
+- [3]
acl_read JCR_READ_ACCESS_CONTROL +  
acl_edit JCR_MODIFY_ACCESS_CONTROL +  
-
-
JCR_LIFECYCLE_MANAGEMENT
JCR_RETENTION_MANAGEMENT
-
-
[4]
[4]
sudo - - [5]
workspaceAccess - - [6]

次の表に、CQActions と CRX 1.4 ActionSet のマッピングを示します。CQActions と CRX 1.4 ActionSet のマッピングは 1:1 に対応付けられており、以前は AclRecord.js で定義されていました。

CQAction CRX ActionSet
read read
modify set_property
create add_node
delete remove
acl_read acl_read
acl_edit acl_edit

[1]

set_property ActionSet は JCR_MODIFY_PROPERTIES に対応付けられます。

CRX 2.0 では、保護された項目は通常の権限チェックではチェックされなくなり、保護された項目を変更する特定の操作を実行できるかどうかを判断する特別な権限によって対応する必要があります。

以前と同じ効果を生み出すために、ユーザーにプロパティの変更権限が付与された場合、CQ では JCR_LOCK_MANAGEMENT と JCR_VERSION_MANAGEMENT(両方とも保護されたプロパティを書き込む)が自動的に付与されます。

JCR_MODIFY_PROPERTIES は、新しいプロパティの作成と既存のプロパティの変更だけでなく、プロパティの削除にも対応します。[3] を参照してください。

注意:ユーザーに JCR_MODIFY_PROPERTIES が付与され、他の 2 つの権限は付与されていない場合、そのユーザーが通常の JCR プロパティの追加、設定および削除の権限を持っていても、CQ ページ権限フラグ内の「変更」アクションでは false と表示されます。

[2]

add_node ActionSet は JCR_ADD_CHILD_NODES に対応付けられます。

保護されたプロパティ jcr:primaryType および jcr:mixinTypes を書き込むには JCR_NODE_TYPE_MANAGEMENT が必要になるので、Node.addNode(String) と Node.addNode(String, String) を呼び出すための両方の権限を付与するために、後者がマッピングに含まれています。

CRX 1.4 では、create に子ノードの追加権限が含まれているだけでなく、この権限によって、新しいノードが永続化されていない限り、ユーザーにプロパティの書き込み権限も付与されました。CRX 2.0 ではそのような動作になりません。保護されていないプロパティへの書き込み権限は、JCR_MODIFY_PROPERTIES のみで対応します。

[3]

CRX 1.4 の remove ActionSet では、その ActionSet が位置する ACE 内のノードと、すべての子ノードおよびプロパティが削除されました。CRX 2.0 でのノードの削除では、編集セッションが親ノードに対して JCR_REMOVE_CHILD_NODES を持ち、削除されるノードに対して JCR_REMOVE_NODE を持っている必要があります。プロパティの削除は JCR_MODIFY_PROPERTIES 権限によって制御されます。

CRX およびその対応する CQ 内の ActionSet で定義されている remove ActionSet は、JCR_REMOVE_CHILD_NODES および JCR_REMOVE_NODE という 2 つの JCR 権限に対応付けられています。

これにより、結果が以下のように少し変化します。

  • 2 つの権限が付与されたターゲットノードは削除できなくなりました。
  • ターゲットの子ノードは削除できます(以前と同様)。
  • ターゲットおよびその子ノードに存在するプロパティは、JCR_MODIFY_PROPERTIES を付与しない限り削除できません。

例:

ユーザー aUser には、/foo での CQ ページ削除権限が付与されています。

CRX 1.4:

delete は、CRX 1.4 の remove ActionSet として解釈されます。
aUser
は、 /foo/foo/* およびすべてのプロパティを削除できます。

CRX 2.0:

aUser は、/foo/* に一致するすべてのノードを削除できますが、/foo や、/foo/prop/foo/*/prop などのプロパティは削除できません。

[4]

JCR 権限の JCR_LIFECYCLE_MANAGEMENT と JCR_RETENTION_MANAGEMENT に対応する権限は CRX 1.4 にはありません。

これらは意図的にマッピングから省略されています。JCR_LIFECYCLE_MANAGEMENT は CQ のスコープでは使用せず、JCR_RETENTION_MANAGEMENT 権限は存在しますが、定義済みの保持管理ツールのみから使用されること(保持管理機能を提供しない通常の CQ インスタンス内からは使用されないこと)が想定されています。

[5]

CRX 1.4 で使用できる sudo ActionSet は、CRX 2.0 では削除されました。

CRX 2.0 では、ユーザー A は、A のプリンシパル名がユーザー Brep:impersonators に記述されている場合に、ユーザー B として操作できます。

[6]

CRX 1.4 で使用できる workspaceAccess ActionSet は、CRX 2.0 では削除されました。

CRX 2.0 では、特定のワークスペースへのアクセス権は、設定済みの WorkspaceAccessManager 実装がアクセス権を付与する場合に付与されます。

CRX および CQ のデフォルト実装は、ユーザーがそのワークスペースで定義されている UserManager の既知のユーザーである場合に限り、ワークスペースへのアクセス権を付与します。

他の実装では次のようになります。

  • SimpleWorkspaceAccessManager:常にアクセス権を付与します。
  • DefaultSecurityManager#WorkspaceAccessManagerImpl:ルートノードが特定のユーザーに見える
    場合にアクセス権を付与します。

CRX アクセス制御 API

CRX 1.x で提供されているアクセス制御 API は、JSR 283 によって定義されたインターフェイスと、Jackrabbit API によって定義された一部の拡張に置き換えられました。

AclSetupService

CQ 5.3 より、実行モードに依存するデフォルトの権限は、起動時に必ず実行される AclSetupService によって定義できます。

AclSetupService では、特定のプリンシパル名の特定のパスに、アクセス制御エントリを作成するように指定できます。また、特定のプリンシパル名の特定のパスにある既存のエントリをクリアすることもできます。

このサービスの性質上、この機能によって既存のアクセス制御コンテンツで問題が発生する場合があります。

本作品は Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License によってライセンス許可を受けています。  Twitter™ および Facebook の投稿には、Creative Commons の規約内容は適用されません。

リーガルノーティス   |   プライバシーポリシー