AEM の閉じられたユーザーグループ

概要

AEM 6.3 より、「閉じられたユーザーグループ」という新しい実装が組み込まれています。これは、既存の実装が抱えていたパフォーマンス、スケーラビリティおよびセキュリティ上の問題を解決するためのものです。

新しい実装の目標は、必要に応じて既存の機能を対象とし、古いバージョンの問題や設計上の制限に対処することです。 その結果として、次の特性を持つ新しい CUG デザインが生まれました。

• 認証要素と承認要素の切り離し。これらの要素は、個別に使用することも、一緒に使用することもできます。
• 他のアクセス制御設定や権限要件と競合することなく、設定済みの CUG ツリーで制限付き読み取りアクセスを反映する専用の承認モデル。
• 制限付き読み取りアクセスのアクセス制御設定（通常オーサリングインスタンスで必要）と、通常は公開でのみ必要な権限の評価とは別個の設定です。
• 権限を昇格しなくても、制限付き読み取りアクセスを編集可能。
• 認証要件をマークするための、専用のノードタイプ拡張。
• 認証要件に関連付けられる、オプションのログインパス。

新しいカスタムユーザーグループの実装

CUG は、AEM のコンテキストで知られるように、次の手順で構成されます。

• 保護する必要があるツリーに対する読み取りアクセスを制限して、特定の CUG インスタンスと一緒にリストされるプリンシパルか、CUG 評価全体から除外されるプリンシパルにのみ読み取りを許可します。これは、承認​要素と呼ばれます。
• 特定のツリーに認証を強制的に適用します。オプションで、そのツリー専用のログインページも指定できます（後で除外されます）。これは、認証​要素と呼ばれます。

この新しい実装では、認証要素と承認要素が切り離されています。AEM 6.3 の時点では、認証要件を明示的に追加しなくても、読み取りアクセスを制限できます。例えば、特定のインスタンス全体で認証が必要な場合や、既に認証を必要としているサブツリー内に特定のツリーが既に存在している場合はそうです。

同様に、有効な権限設定を変更せずに、特定のツリーに認証要件をマークすることもできます。 これらの組み合わせと結果については、CUG ポリシーと認証要件の組み合わせの節に示します。

概要

承認：読み取りアクセスの制限

CUG の重要な機能は、コンテンツリポジトリ内の特定のツリーに対する読み取りアクセスを制限することです（選択されたプリンシパルを除く）。新しい実装では、実行中にデフォルトのアクセス制御コンテンツを操作しません。これまでとは異なるアプローチとして、CUG を表す専用のアクセス制御ポリシータイプを定義します。

CUG 用のアクセス制御ポリシー

この新しいタイプのポリシーは、次の特性を持ちます。

• org.apache.jackrabbit.api.security.authorization.PrincipalSetPolicyタイプのアクセス制御ポリシー（Apache Jackrabbit APIで定義）;
• PrincipalSetPolicyは、変更可能なプリンシパルのセットに対する権限を付与します。
• 付与される権限とポリシーの有効範囲は、実装の詳細です。

CUGを表すために使用されるPrincipalSetPolicyの実装には、次の定義も含まれます。

• CUG ポリシーは、通常の JCR アイテムへの読み取りアクセスのみを付与します（例えば、アクセス制御コンテンツは除外されます）。
• 有効範囲は、CUG ポリシーを保持する、アクセス制御されたノードによって定義されます。
• CUG ポリシーはネストできます。ネストされた CUG は、「親」CUG のプリンシパルセットを継承しなくても、新しい CUG を開始できます。
• ポリシーの効果は、評価が有効になっている場合は次にネストされた CUG に至るまで、サブツリー全体に継承されます。

これらのCUGポリシーは、oak-authorization-cugと呼ばれる別の認証モジュールを介してAEMインスタンスにデプロイされます。 このモジュールは、独自のアクセス制御管理および権限評価に付属しています。つまり、デフォルトの AEM のセットアップには、複数の承認メカニズムを組み合わせた Oak コンテンツリポジトリ設定が付属しています。詳しくは、Apache Oak Documentation🔗のこのページを参照してください。

この複合セットアップでは、新しいCUGは、ターゲットノードにアタッチされた既存のアクセス制御コンテンツを置き換えませんが、補助として設計されており、AEMではデフォルトでアクセス制御リストとなり、元のアクセス制御に影響を与えずに後で削除できます。

前の実装とは対照的に、新しい CUG ポリシーは常にアクセス制御コンテンツとして認識、処理されます。つまり、新しい CUG ポリシーは、JCR アクセス制御管理 API を使用して作成、編集されるということです。詳しくは、CUGポリシーの管理の節を参照してください。

CUG ポリシーの権限評価

CUG の専用アクセス制御管理とは別に、新しい承認モデルでは、CUG ポリシーの権限評価を条件付きで有効にできます。このモデルでは、CUG ポリシーをステージング環境に設定しておき、実稼動環境にレプリケーションされた後で、有効な権限の評価を有効にするという手法を使用できます。

CUG ポリシーの権限評価と、デフォルトまたは追加の承認モデルとの連携は、Apache Jackrabbit Oak の複数の承認メカニズム用に設計されたパターンに従います。つまり、すべてのモデルがアクセスを付与する場合にのみ、特定の権限セットが付与されます。詳しくは、このページを参照してください。

CUG ポリシーを処理、評価するために設計された承認モデルに関連付けられる権限評価には、次の特性が適用されます。

• 通常のノードとプロパティの読み取り権限のみを処理し、アクセス制御コンテンツを読み取りません。
• 書き込み権限や、保護されたJCRコンテンツの変更に必要な権限(アクセス制御、ノードタイプ情報、バージョン管理、ロック、ユーザー管理など)は処理されません。これらの権限はCUGポリシーの影響を受けず、関連付けられた承認モデルによって評価されません。 これらの権限が付与されるかどうかは、セキュリティ設定に設定された他のモデルに応じます。

権限評価に対する単一のCUGポリシーの影響を以下に要約できます。

• 読み取りアクセスは拒否されます（除外されたプリンシパルやポリシーにリストされたプリンシパルを含むサブジェクトを除く）。
• ポリシーは、ポリシーとそのプロパティを保持するアクセス制御ノードに対して有効になります。
• この効果は、階層（アクセス制御ノードによって定義される項目ツリー）に追加的に継承されます。
• ただし、アクセス制御ノードの兄弟や先祖には影響しません。
• 特定の CUG の継承は、ネストされた CUG で止まります。

ベストプラクティス

CUG を介した、制限付き読み取りアクセスを定義する際は、次のベストプラクティスを考慮する必要があります。

• CUG は、読み取りアクセスの制限のために必要なのか、認証要件のために必要なのかを判断します。後者の場合、または両方が必要な場合は、認証要件の詳細について、「ベストプラクティス」の項を参照してください。

• 保護する必要があるデータやコンテンツの脅威モデルを作成して、脅威の範囲を識別し、データの感度と、承認されたアクセスに関連付けられている役割を明確にします。

• リポジトリコンテンツと CUG をモデル化して、承認に関する一般事項とベストプラクティスを覚えておきます。

  • 特定の CUG と、セットアップに導入されている他のモジュールの評価によって、特定のサブジェクトが特定のリポジトリアイテムを読み取ることが許可される場合にのみ、読み取り権限が付与されます。
  • 読み取りアクセスが既に他の承認モジュールによって制限されている場合は、冗長 CUG の作成を回避します。
  • ネストされた CUG が大量に必要になる場合は、コンテンツデザインに問題がある可能性があります。
  • CUG が大量に必要な場合（例えば、各ページに CUG が必要な場合）は、そのアプリケーションやコンテンツのセキュリティニーズに見合ったカスタム承認モデルを導入することが必要な可能性があります。

• CUG ポリシーのためにサポートされるパスを、リポジトリ内のいくつかのツリーに制限して、最適なパフォーマンスを維持します。例えば、/contentノードの下のCUGを、AEM 6.3以降のデフォルト値として出荷済みとして許可します。

• CUG ポリシーは、少数のプリンシパルに読み取りアクセスを付与することを想定して設計されています。大量のプリンシパルが必要な場合は、コンテンツやアプリケーションのデザインに関する問題が発生する可能性があるので、再検討する必要があります。

認証：認証要件の定義

CUG 機能の認証関連のパーツにより、認証を必要とするツリーをマークできます。オプションで、専用のログインページも指定できます。以前のバージョンに従って、新しい実装では、コンテンツリポジトリでの認証を必要とするツリーにマークを付け、最終的に要件を適用し、ログインリソースにリダイレクトするSling org.apache.sling.api.auth.Authenticatorとの条件付き同期を有効にできます。

これらの要件は、sling.auth.requirements 登録プロパティを提供する OSGi サービスによって Authenticator に登録されます。その後、これらのプロパティは、認証要件の動的な拡張に使用されます。詳しくは、Sling に関するドキュメントを参照してください。

専用の Mixin タイプによる認証要件の定義

セキュリティ上の理由から、新しい実装は、残りのJCRプロパティの使用をgranite:AuthenticationRequiredと呼ばれる専用のmixin型に置き換えます。この型は、ログインパスgranite:loginPathにSTRING型の1つのオプションのプロパティを定義します。 この mixin タイプに関連するコンテンツが変更された場合にのみ、Apache Sling Authenticator に登録される要件が更新されます。一時的な変更が行われると、変更が追跡されるので、有効にするにはjavax.jcr.Session.save()呼び出しが必要です。

granite:loginPathプロパティにも同様です。 認証要件に関連するミックスインの種類で定義されている場合にのみ考慮されます。 この名前を持つ残存のプロパティを非構造化JCRノードに追加しても、望ましい効果は表示されず、OSGi登録を更新するハンドラによってそのプロパティは無視されます。

Sling Authenticator への認証要件とログインパスの登録

この認証要件は、特定の実行モードとコンテンツリポジトリ内の小さなツリーのサブセットに限定されると考えられるので、要件mixinタイプとログインパスプロパティの追跡は、条件付きで、サポートされるパスを定義する対応する設定に連結されます（後述の設定オプションを参照）。 したがって、サポートパスの有効範囲内で変更があった場合にのみ、OSGi 登録の更新が実行され、それ以外の場所では、mixin タイプもログインパスプロパティも無視されます。

現在は、デフォルトのAEM設定でこの設定が使用され、作成者実行モードでのミックスインの設定が許可されますが、パブリッシュインスタンスへの複製時にのみ有効になります。 Slingが認証要件を適用する方法の詳細については、このページを参照してください。

設定されたサポートされているパスにgranite:AuthenticationRequiredミックスインタイプを追加すると、sling.auth.requirementsプロパティを持つ新しい追加のエントリを含む、OSGiでの責任ハンドラの登録が更新されます。 特定の認証要件でオプションのgranite:loginPathプロパティが指定されている場合、認証要件から除外するために、この値はAuthenticatorに「 — 」プレフィックスを付けて追加登録されます。

認証要件の評価と継承

Apache Sling 認証要件は、ページやノード階層を介して継承されることが期待されます。認証要件の継承と評価の詳細（順序や優先順位など）は、実装の詳細になるので、このドキュメントでは説明しません。

ログインパスの評価

現在、ログインパスの評価と認証時の対応するリソースへのリダイレクトは、AEMでデフォルトで設定されたApache Sling AuthenticationHandlerのAdobeGranite Login Selector Authentication Handler ( com.day.cq.auth.impl.LoginSelectorHandler)の実装詳細です。

AuthenticationHandler.requestCredentialsを呼び出すと、このハンドラは、ユーザがリダイレクトされる対応付けのログインページを決定しようとします。 この決定は、次の手順に従います。

• リダイレクトの理由として、パスワードの失効と、通常のログインに必要な処理を区別します。

• 通常のログインに必要な処理である場合は、ログインパスを取得できるかどうかを、以下の順序で確認します。

  • を、新しいcom.adobe.granite.auth.requirement.impl.RequirementServiceによって実装されたLoginPathProviderから、
  • 廃止された古い CUG 実装から
  • 」をLoginSelectorHandlerで定義される「ログインページのマッピング」から
  • 最後に、LoginSelectorHandlerで定義されている「デフォルトログインページ」にフォールバックします。

• 前述の呼び出しから有効なログインパスが取得されると、ユーザーのリクエストはすぐに、そのページにリダイレクトされます。

このドキュメントのターゲットは、内部LoginPathProviderインターフェイスで公開されるログインパスの評価です。 AEM 6.3 以降に付属する実装は、次のように動作します。

• ログインパスの登録は、リダイレクトの理由が、パスワードの失効であるか、通常のログインに必要な処理であるかによって異なります。

• 通常のログインに必要な処理である場合は、ログインパスを取得できるかどうかを、以下の順序で確認します。

  • 新しいcom.adobe.granite.auth.requirement.impl.RequirementServiceが実装したLoginPathProviderから、
  • 廃止された古い CUG 実装から
  • 」をLoginSelectorHandlerで定義されている「ログインページのマッピング」から
  • 最後に、LoginSelectorHandlerで定義されている「デフォルトログインページ」にフォールバックします。

• 前述の呼び出しから有効なログインパスが取得されると、ユーザーのリクエストはすぐに、そのページにリダイレクトされます。

Graniteの新しい認証要件サポートによって実装されたLoginPathProviderは、granite:loginPathプロパティで定義されたログインパスを公開します。その後、上記のmixinタイプで定義されます。 ログインパスとプロパティ値自体を保持するリソースパスのマッピングはメモリ内に保存され、階層内にある他のノードの適切なログインパスを検出するために評価されます。

ベストプラクティス

認証要件を定義する際は、次のベストプラクティスを考慮する必要があります。

• 認証要件のネストを回避します。ツリーの先頭部に認証要件マーカーを 1 つ配置するだけで十分です。そのマーカーは、ターゲットノードによって定義されるサブツリー全体に継承されます。そのツリー内に他の認証要件があると、Apache Sling 内で認証要件を評価する際にパフォーマンス上の問題となる可能性があります。承認と認証に関連する CUG エリアを切り離すことで、CUG やその他のポリシーによって読み取りアクセスを制限すると同時に、ツリー全体に認証を適用できます。

• ネストされたサブツリーを再度要件から除外する必要なく、認証要件がツリー全体に適用されるようなモデルリポジトリコンテンツ。

• 余分なログインパスの指定を回避するには、次のようにします。

  • 継承に依存し、ネストされたログインパスを定義しない。
  • オプションのログインパスを、デフォルト値または継承された値に対応する値に設定しないでください。
  • アプリケーション開発者は、LoginSelectorHandler に関連付けられるグローバルなログインパス設定（デフォルトとマッピングの両方）に設定する必要があるログインパスを識別してください。

リポジトリでの表現

リポジトリでの CUG ポリシーの表現

Oakのドキュメントでは、新しいCUGポリシーがリポジトリのコンテンツにどのように反映されるかについて説明します。 詳しくは、このページを参照してください。

リポジトリでの認証要件

個別の認証要件の必要性は、専用のミックスインノードタイプをターゲットノードに配置したリポジトリコンテンツに反映されます。 この mixin タイプは、オプションのプロパティを定義して、ターゲットノードによって定義されるツリーの専用ログインページを指定します。

ログインパスに関連付けられるページは、ツリーの内部または外部のいずれにでも配置できます。このページは、認証要件から除外されます。

[granite:AuthenticationRequired]
      mixin
      - granite:loginPath (STRING)

CUG ポリシーと認証要件の管理

CUG ポリシーの管理

CUGの読み取りアクセスを制限する新しいタイプのアクセス制御ポリシーは、JCRアクセス制御管理APIを使用して管理され、JCR 2.0仕様で説明されているメカニズムに従います。

新しい CUG ポリシーの設定

次のコードは、CUG がまだ設定されていないノードに新しい CUG ポリシーを適用します。getApplicablePoliciesが返すのは、以前に設定されたことのない新しいポリシーのみです。 最後に、このポリシーを書き戻して、変更を保存する必要があります。

String path = [...] // needs to be a supported, absolute path

Principal toAdd1 = [...]
Principal toAdd2 = [...]
Principal toRemove = [...]

AccessControlManager acMgr = session.getAccessControlManager();
PrincipalSetPolicy cugPolicy = null;

AccessControlPolicyIterator it = acMgr.getApplicablePolicies(path);
while (it.hasNext()) {
        AccessControlPolicy policy = it.nextAccessControlPolicy();
        if (policy instanceof PrincipalSetPolicy) {
           cugPolicy = (PrincipalSetPolicy) policy;
           break;
        }
}

if (cugPolicy == null) {
   log.debug("no applicable policy"); // path not supported or no applicable policy (e.g.
                                                   // the policy was set before)
   return;
}

cugPolicy.addPrincipals(toAdd1, toAdd2);
cugPolicy.removePrincipals(toRemove));

acMgr.setPolicy(path, cugPolicy); // as of this step the policy can be edited/removed
session.save();

既存の CUG ポリシーの編集

既存の CUG ポリシーを編集するには、次の手順が必要です。変更したポリシーを書き戻す必要があり、変更はjavax.jcr.Session.save()を使用して保持する必要があることに注意してください。

String path = [...] // needs to be a supported, absolute path

Principal toAdd1 = [...]
Principal toAdd2 = [...]
Principal toRemove = [...]

AccessControlManager acMgr = session.getAccessControlManager();
PrincipalSetPolicy cugPolicy = null;

for (AccessControlPolicy policy : acMgr.getPolicies(path)) {
     if (policy instanceof PrincipalSetPolicy) {
        cugPolicy = (PrincipalSetPolicy) policy;
        break;
     }
}

if (cugPolicy == null) {
   log.debug("no policy to edit"); // path not supported or policy not set before
   return;
}

if (cugPolicy.addPrincipals(toAdd1, toAdd2) || cugPolicy.removePrincipals(toRemove)) {
   acMgr.setPolicy(path, cugPolicy);
   session.save();
} else {
     log.debug("cug policy not modified");
}

有効な CUG ポリシーの取得

JCR アクセス制御管理では、特定のパスで有効なポリシーを取得する最善の方法を定義します。CUGポリシーの評価は条件付きで、有効にする対応する設定に依存するため、getEffectivePoliciesを呼び出すと、特定のCUGポリシーが特定のインストールで有効になるかどうかを検証するのに便利です。

String path = [...] // needs to be a supported, absolute path

AccessControlManager acMgr = session.getAccessControlManager();
PrincipalSetPolicy cugPolicy = null;

// log an debug message of all CUG policies that take effect at the given path
// there could be zero, one or many (creating nested CUGs is possible)
for (AccessControlPolicy policy : acMgr.getEffectivePolicies(path) {
     if (policy instanceof PrincipalSetPolicy) {
        String policyPath = "-";
        if (policy instanceof JackrabbitAccessControlPolicy) {
           policyPath = ((JackrabbitAccessControlPolicy) policy).getPath();
        }
        log.debug("Found effective CUG for path '{}' at '{}', path, policyPath);
     }
}

継承された CUG ポリシーの取得

ネストされたすべての CUG が有効かどうかに関係なく、特定のパスに定義されているそれらの CUG を検出します。詳しくは、設定オプションの節を参照してください。

String path = [...]

List<AccessControlPolicy> cugPolicies = new ArrayList<AccessControlPolicy>();
while (isSupportedPath(path)) {
     for (AccessControlPolicy policy : acMgr.getPolicies(path)) {
         if (policy instanceof PrincipalSetPolicy) {
            cugPolicies.add(policy);
         }
      }
      path = (PathUtils.denotesRoot(path)) ? null : PathUtils.getAncestorPath(path, 1);
}

プリンシパルによる CUG ポリシーの管理

プリンシパルによるアクセス制御ポリシーの編集を許可するJackrabbitAccessControlManagerによって定義される拡張は、CUGアクセス制御管理では実装されません。CUGポリシーは常にすべてのプリンシパルに影響を与えます。PrincipalSetPolicyと共にリストされるプリンシパルは読み取りアクセス権を付与されますが、ターゲットノードによって定義されるツリー内のコンテンツを他のプリンシパルが読み取ることはできません。

これらに対応するメソッドは常に、空のポリシー配列を返しますが、例外はスローしません。

認証要件の管理

新しい認証要件の作成、変更、または削除は、ターゲットノードの有効なノードタイプを変更することで達成される。 その後、オプションのログインパスプロパティへの書き込みには、通常の JCR API を使用できます。

新しい認証要件の追加

次に、新しい認証要件の作成手順を示します。ターゲットノードを含むツリーに対してRequirementHandlerが設定されている場合、要件はApache Sling認証子にのみ登録されます。

Node targetNode = [...]

targetNode.addMixin("granite:AuthenticationRequired");
session.save();

ログインパスを含む新しい認証要件の追加

次に、ログインパスを含む新しい認証要件の作成手順を示します。ログインパスの要件と除外は、ターゲットノードを含むツリーに対してRequirementHandlerが設定されている場合にのみ、Apache Sling認証子に登録されます。

Node targetNode = [...]
String loginPath = [...] // STRING property

Node targetNode = session.getNode(path);
targetNode.addMixin("granite:AuthenticationRequired");

targetNode.setProperty("granite:loginPath", loginPath);
session.save();

既存のログインパスの変更

次に、既存のログインパスの変更手順を示します。ターゲットノードを含むツリーに対してRequirementHandlerが設定されている場合、変更はApache Sling認証子にのみ登録されます。 以前のログインパス値は登録から削除されます。ターゲットノードに関連付けられている認証要件は、この変更の影響を受けません。

Node targetNode = [...]
String newLoginPath = [...] // STRING property

if (targetNode.isNodeType("granite:AuthenticationRequired")) {
   targetNode.setProperty("granite:loginPath", newLoginPath);
   session.save();
} else {
     log.debug("cannot modify login path property; mixin type missing");
}

既存のログインパスの削除

次に、既存のログインパスの削除手順を示します。ログインパスのエントリは、ターゲットノードを含むツリーに RequirementHandler が設定済みの場合にのみ、Apache Sling Authenticator から登録が解除されます。ターゲットノードに関連付けられている認証要件は、影響を受けません。

Node targetNode = [...]

if (targetNode.hasProperty("granite:loginPath") &&
   targetNode.isNodeType("granite:AuthenticationRequired")) {
   targetNode.setProperty("granite:loginPath", null);
   session.save();
} else {
     log.debug("cannot remove login path property; mixin type missing");
}

また、次の方法でも、既存のログインパスを削除できます。

String path = [...] // absolute path to target node

String propertyPath = PathUtils.concat(path, "granite:loginPath");
if (session.propertyExists(propertyPath)) {
    session.getProperty(propertyPath).remove();
    // or: session.removeItem(propertyPath);
    session.save();
}

認証要件の削除

次に、既存の認証要件の削除手順を示します。ターゲットノードを含むツリーに対してRequirementHandlerが設定されている場合、要件はApache Sling認証子からのみ登録解除されます。

Node targetNode = [...]
targetNode.removeMixin("granite:AuthenticationRequired");

session.save();

有効な認証要件の取得

Apache Sling認証子に登録されている有効な認証要件をすべて読み取るための専用のパブリックAPIはありません。 ただし、リストはシステムコンソールのhttps://<serveraddress>:<serverport>/system/console/slingauthにある「Authentication Requirement Configuration」セクションに公開されます。

以下に、デモコンテンツを含む AEM パブリッシュインスタンスの認証要件を示します。ハイライトされているコミュニティページのパスは、このドキュメントに記載される実装によって追加される要件が Apache Sling Authenticator にどのように反映されるかを示しています。

有効なログインパスの取得

現在、認証が必要なリソースに匿名でアクセスした場合に有効となるログインパスを取得するパブリックAPIはありません。 ログインパスの取得方法について詳しくは、「ログインパスの評価」の節を参照してください。

ただし、この機能に定義されるログインパスとは別に、ログインへのリダイレクトを指定する他の方法があります。これについては、コンテンツモデルと、特定の AEM インストールの認証要件を設計する際に検討する必要があります。

継承された認証要件の取得

ログインパスの場合と同様に、コンテンツに定義された、継承される認証要件を取得できるパブリック API はありません。次の例は、特定の階層で定義されたすべての認証要件を、それらの要件が有効かどうかに関係なくリストする方法を示しています。 詳しくは、設定オプションを参照してください。

String path = [...]
Node node = session.getNode(path);

Map<String, String> authRequirements = new ArrayList<String, String>();
while (isSupported(node)) {
     if (node.isNodeType("granite:AuthenticationRequired")) {
         String loginPath = (node.hasProperty("granite:loginPath") ?
                                     node.getProperty("granite:loginPath").getString() :
                                     "";
        authRequirements.put(node.getPath(), loginPath);
        node = node.getParent();
     }
}

CUG ポリシーと認証要件の組み合わせ

次の表に、両方のモジュールが設定を介して有効になっている AEM インスタンスでの、CUG ポリシーと認証要件の有効な組み合わせを示します。

認証が必要です	ログインパス	制限付き読み取りアクセス	期待効果
はい	可	はい	有効な権限評価でアクセスが許可されている場合、特定のユーザーがCUGポリシーでマークされたサブツリーの表示のみを実行できます。 未認証ユーザーは、指定されたログインページにリダイレクトされます。
はい	いいえ	可	有効な権限評価でアクセスが許可されている場合、特定のユーザーがCUGポリシーでマークされたサブツリーの表示のみを実行できます。 認証されていないユーザーは、継承されたデフォルトのログインページにリダイレクトされます。
はい	可	いいえ	未認証ユーザーは、指定されたログインページにリダイレクトされます。 認証要件でマークされているツリーを表示できるかどうかは、そのサブツリーに含まれる個々のアイテムの有効な権限に応じます。読み取りアクセスを制限する専用の CUG はありません。
はい	いいえ	いいえ	認証されていないユーザーは、継承されたデフォルトのログインページにリダイレクトされます。認証要件でマークされているツリーを表示できるかどうかは、そのサブツリーに含まれる個々のアイテムの有効な権限に応じます。読み取りアクセスを制限する専用の CUG はありません。
不可	不可	可	特定の認証済みユーザーまたは未認証ユーザーは、有効な権限評価によってアクセスが許可される場合にのみ、CUGポリシーでマークされたサブツリーを表示できます。 認証されていないユーザーも同じように処理され、ログインにリダイレクトされません。

OSGi コンポーネントと設定

この節では、新しい CUG 実装によって導入された OSGi コンポーネントと個々の設定オプションの概要を示します。

古い実装と新しい実装の設定オプションの包括的なマッピングについては、CUGマッピングのドキュメントも参照してください。

承認：セットアップと設定

新しい承認関連のパーツは、AEM のデフォルトインストールの一部である Oak CUG Authorization バンドル（org.apache.jackrabbit.oak-authorization-cug）に含まれています。このバンドルは、読み取りアクセスを管理する追加の方法として導入される、別の承認モデルを定義します。

CUG 承認のセットアップ

CUG認証の設定については、関連するApacheドキュメントで詳しく説明しています。 AEM ではデフォルトで、CUG 承認はすべての実行モードに導入されています。別の承認セットアップを必要とするインストールでは、CUG 承認を無効にすることもできます。

Referrer Filter の設定

また、AEMへのアクセスに使用できるすべてのホスト名をSling転送者フィルタに設定する必要があります。例えば、CDN、ロードバランサーなどを使用して、

Referrer Filter が設定されていないと、ユーザーが CUG サイトへのログインを試みたときに、次のようなエラーが表示されます。

31.01.2017 13:49:42.321 *INFO* [qtp1263731568-346] org.apache.sling.security.impl.ReferrerFilter Rejected referrer header for POST request to /libs/granite/core/content/login.html/j_security_check : https://hostname/libs/granite/core/content/login.html?resource=%2Fcontent%2Fgeometrixx%2Fen%2Ftest-site%2Ftest-page.html&$$login$$=%24%24login%24%24&j_reason=unknown&j_reason_code=unknown

OSGi コンポーネントの特性

認証要件を定義して、専用のログインパスを指定するために、次の 2 つの OSGi コンポーネントが導入されています。

• org.apache.jackrabbit.oak.spi.security.authorization.cug.impl.CugConfiguration
• org.apache.jackrabbit.oak.spi.security.authorization.cug.impl.CugExcludeImpl

org.apache.jackrabbit.oak.spi.security.authorization.cug.impl.CugConfiguration

ラベル	Apache Jackrabbit Oak CUGの設定
説明	CUG権限の設定と評価に専用の認証設定。
設定プロパティ	cugSupportedPaths cugEnabled configurationRanking また、下記の設定オプションも参照してください。
構成ポリシー	ConfigurationPolicy.REQUIRE
参照	CugExclude (ReferenceCardinality.OPTIONAL_UNARY)

org.apache.jackrabbit.oak.spi.security.authorization.cug.impl.CugExcludeImpl

ラベル	Apache Jackrabbit Oak CUG除外リスト
説明	設定された名前を持つプリンシパルをCUG評価から除外できます。
設定プロパティ	principalNames 後述の「設定オプション」セクションも参照してください。
構成ポリシー	ConfigurationPolicy.REQUIRE
参照	該当なし

設定オプション

主な設定オプションは次のとおりです。

• cugSupportedPaths：CUG を含むことができるサブツリーを指定します。デフォルト値は設定されません。
• cugEnabled：現在の CUG ポリシーに対して権限評価を有効にする設定オプション。

CUG 承認モジュールに関連する設定オプションの一覧と、その詳細な説明については、Apache Oak ドキュメントを参照してください。

CUG 評価からのプリンシパルの除外

CUG 評価からの個々のプリンシパルの除外は、前の実装から採用されていました。新しいCUG認証では、CugExcludeという名前の専用インターフェイスがこの機能に対応しています。 Apache Jackrabbit Oak 1.4 には、プリンシパルの固定セットを除外するデフォルト実装と、個々のプリンシパル名を設定できる拡張実装が付属しています。拡張実装は AEM パブリッシュインスタンスに設定されます。

AEM 6.3 以降のデフォルトでは、次のプリンシパルは、CUG ポリシーの影響を受けません。

• 管理プリンシパル（管理者ユーザー、管理者グループ）
• サービスユーザープリンシパル
• リポジトリ内部システムプリンシパル

詳しくは、後述の AEM 6.3 以降のデフォルト設定の表を参照してください。

'administrators'グループの除外は、Apache Jackrabbit Oak CUG除外リスト​の設定セクションのシステムコンソールで変更または拡張できます。

また、特別な必要が生じた場合に除外プリンシパルのセットを調整するために、CugExcludeインターフェイスのカスタム実装を提供およびデプロイすることもできます。 詳細と実装例については、CUG plugabilityのドキュメントを参照してください。

認証：セットアップと設定

新しい認証関連のパーツは、Adobe Granite Authentication Handler バンドル（com.adobe.granite.auth.authhandler バージョン 5.6.48）に含まれています。このバンドルは AEM のデフォルトインストールの一部です。

廃止された CUG サポートの代わりとなる認証要件をセットアップするには、いくつかの OSGi コンポーネントを AEM インストールに提供してアクティブにする必要があります。詳しくは、後述の OSGi コンポーネントの特性​を参照してください。

OSGi コンポーネントの特性

認証要件を定義し、専用のログインパスを指定するために、次の 2 つの OSGi コンポーネントが導入されています。

• com.adobe.granite.auth.requirement.impl.RequirementService
• com.adobe.granite.auth.requirement.impl.DefaultRequirementHandler

com.adobe.granite.auth.requirement.impl.RequirementService

ラベル	-
説明	認証要件に影響するコンテンツの変更（granite:AuthenticationRequirementミックスインタイプを介する）にオブザーバーを登録する認証要件専用のOSGiサービスとログインパスは、LoginSelectorHandlerに公開されます。
設定プロパティ	-
構成ポリシー	ConfigurationPolicy.OPTIONAL
参照	RequirementHandler (ReferenceCardinality.MANDATORY_UNARY) Executor (ReferenceCardinality.MANDATORY_UNARY)

com.adobe.granite.auth.requirement.impl.DefaultRequirementHandler

ラベル	AdobeGranite認証要件およびログインパスハンドラ
説明	RequirementHandler Apache Sling認証要件と、関連付けられたログインパスの対応する除外を更新する実装。
設定プロパティ	supportedPaths
構成ポリシー	ConfigurationPolicy.REQUIRE
参照	該当なし

設定オプション

CUG のリライトの認証関連のパーツは、Adobe Granite Authentication Requirement and Login Path Handler に関連する単一の設定オプションにのみ付属しています。

「Authentication Requirement and Login Path Handler」

プロパティ	型	デフォルト値	説明
Label = Supported Paths Name = 'supportedPaths'	設定<文字列>	-	認証要件がこのハンドラーによって考慮されるパスです。 ノードにgranite:AuthenticationRequirementミックスインタイプを適用せずに追加する場合（例えば、作成者インスタンスで）は、この設定を未設定のままにします。 未設定にしておくと、この機能は無効になります。

AEM 6.3 以降のデフォルト設定

AEM の新規インストールでは、デフォルトで、CUG 機能の承認関連と認証関連のパーツの両方で新しい実装を使用します。旧実装「Adobe Granite Closed User Group (CUG) Support」は廃止されていて、すべての AEM インストールでデフォルトで無効になります。代わりに、新しい実装は、次のように有効になります。

オーサーインスタンス

"Apache Jackrabbit Oak CUG Configuration"	説明
サポートされるパス/content	CUGポリシーのアクセス制御管理が有効になっています。
CUG評価が有効なFALSE	権限の評価が無効になっています。 CUG ポリシーは無効です。
ランキング	200

パブリッシュインスタンス

"Apache Jackrabbit Oak CUG Configuration"	説明
サポートされるパス/content	CUGポリシーのアクセス制御管理は、設定されたパスの下で有効になります。
CUG評価が有効なTRUE	設定されたパスの下で権限の評価が有効になっています。 CUGポリシーはSession.save()に対して有効になります。
ランキング	200

"Apache Jackrabbit Oak CUG除外リスト"	説明
プリンシパル名管理者	管理者プリンシパルをCUG評価から除外します。

「AdobeGranite認証要件とログインパスハンドラー」	説明
サポートされるパス/content	granite:AuthenticationRequiredミックスインタイプによってリポジトリで定義される認証要件は、Session.save()の/contentの下で有効になります。 Sling Authenticator は更新されます。mixin タイプをサポートパス外に追加しても無視されます。

CUG 承認および認証要件の無効化

特定のインストールで CUG を使用しない場合、または認証と承認に別の方法を使用する場合は、新しい実装を全体で無効にできます。

CUG 承認の無効化

複合承認のセットアップから CUG 承認モデルを削除する方法について詳しくは、プラグの可／不可に関するドキュメントを参照してください。

認証要件の無効化

granite.auth.authhandler モジュールが提供する認証要件のサポートを無効にするには、Adobe Granite Authentication Requirement and Login Path Handler に関連する設定を削除するだけで十分です。

他のモジュールの操作

Apache Jackrabbit API

CUG 承認モデルで使用する新しいタイプのアクセス制御ポリシーを強化するために、Apache Jackrabbit で定義される API が拡張されています。jackrabbit-apiモジュールのバージョン2.11.0以降では、javax.jcr.security.AccessControlPolicyから拡張するorg.apache.jackrabbit.api.security.authorization.PrincipalSetPolicyと呼ばれる新しいインターフェイスが定義されています。

Apache Jackrabbit FileVault

Apache Jackrabbit FileVaultのインポートメカニズムは、PrincipalSetPolicy型のアクセス制御ポリシーに対応するように調整されました。

Apache Sling Content Distribution

詳しくは、前述の Apache Jackrabbit FileVault の節を参照してください。

Adobe Granite Replication

このレプリケーションモジュールは、異なる AEM インスタンス間で CUG ポリシーをレプリケーションできるように少し調整されています。

• DurboImportConfiguration.isImportAcl() は文字通り解釈され、実装するアクセス制御ポリシーにのみ影響を及ぼす javax.jcr.security.AccessControlList

• DurboImportTransformer は、真のACLに対してのみこの設定を適用します。

• CUG 承認モデルによって作成される org.apache.jackrabbit.api.security.authorization.PrincipalSetPolicy インスタンスなどの他のポリシーは常にレプリケーションされ、設定オプション DurboImportConfiguration.isImportAcl () は無視されます。

CUG ポリシーのレプリケーションには 1 つ制約があります。対応するミックスインノードタイプrep:CugMixin,を削除せずに指定したCUGポリシーが削除された場合、削除はレプリケーションに反映されません。 これについては、ポリシーを削除する際に mixin も必ず削除することで解消されました。ただし、mixin タイプが手動で追加された場合には、この現象が発生する可能性があります。

Adobe Granite Authentication Handler

バンドルに付属する認証ハンドラー Adobe Granite HTTP Header Authentication Handlercom.adobe.granite.auth.authhandler は、同じモジュールによって定義される CugSupport インターフェイスへの参照を保持します。これは、特定の環境内での「領域」の計算に使用され、このハンドラーによって設定される領域にフォールバックします。

このモジュールは、CugSupport への参照をオプションとして使用できるように調整されました。この調整により、既に廃止されている実装を特定のセットアップで再度有効にしても、最大限の後方互換性を確保できます。実装を使用したインストールでは、CUG実装から抽出された領域は取得されなくなりますが、AdobeGranite HTTP Header Authentication Handler​で定義された領域が常に表示されます。

AEM ライブコピー

LiveCopyと組み合わせてCUGを設定すると、次のように、1つの追加のノードと1つの追加のプロパティがリポジトリに追加されて表されます。

• /content/we-retail/us/en/blueprint/rep:cugPolicy
• /content/we-retail/us/en/LiveCopy@granite:loginPath

これらの要素はどちらもcq:Pageの下に作成されます。 現在の設計では、MSMはcq:PageContent (jcr:content)ノードの下にあるノードとプロパティのみを処理します。

したがって、CUGグループはBlueprintsからライブコピーにロールアウトできません。 ライブコピーを設定する際には、この点を考慮してください。

新しい CUG 実装による変更

この節では、CUG 機能に加えられた変更点の概要を示し、新旧の実装を比較します。CUG サポートの設定方法に影響する変更点を挙げます。また、リポジトリコンテンツにおける CUG の管理方法とその管理者についても説明します。

CUGの設定と設定の違い

廃止された OSGi コンポーネント Adobe Granite Closed User Group (CUG) Support（com.day.cq.auth.impl.cug.CugSupportImpl）は、新しいコンポーネントに置き換えられ、前の CUG 機能の承認関連のパーツと認証関連のパーツを分けて扱えるようになりました。

リポジトリコンテンツでのCUGの管理の違い

以下の節では、新旧の実装の違いについて、実装面とセキュリティ面から説明します。新しい実装でも、同じ機能を提供することを目的としていますが、新しい CUG を使用するうえで知っておくべき変更点があります。

認証に関する相違点

認証の観点からの主な違いは、次のリストにまとめられています。

CUG 専用のアクセス制御コンテンツ

古い実装では、デフォルトの承認モデルは、公開時にアクセス制御リストポリシーを操作するために使用され、既存の ACE は、CUG が要求するセットアップに置き換えられました。この承認モデルは、公開時に解釈される通常の残余 JCR プロパティを記述することで呼び出されました。

新しい実装では、デフォルトの認証モデルのアクセス制御設定は、作成、変更、または削除されるCUGの影響を受けません。 代わりに、PrincipalSetPolicyという新しいタイプのポリシーが、追加のアクセス制御コンテンツとしてターゲットノードに適用されます。 この追加ポリシーは、ターゲットノードの子として配置され、デフォルトのポリシーノードがある場合はその兄弟になります。

アクセス制御管理における CUG ポリシーの編集

残余 JCR プロパティから専用アクセス制御ポリシーに移行したことで、CUG 機能の承認パーツの作成や変更に必要な権限に影響が出ています。これはアクセス制御コンテンツの変更と見なされるので、リポジトリに書き込むためにはjcr:readAccessControlとjcr:modifyAccessControlの権限が必要です。 したがって、ページのアクセス制御コンテンツを変更する権限を持つコンテンツ作成者のみ、このコンテンツをセットアップまたは変更できます。これは、通常の JCR プロパティを書き込む機能が十分で、結果として、権限の昇格となる古い実装とは対照的です。

ポリシーによって定義されるターゲットノード

CUG ポリシーは、通常は、制限付き読み取りアクセスの対象となるサブツリーを定義する JCR ノードで作成されます。CUG がツリー全体に影響する場合は、これが AEM ページになると思われます。

CUGポリシーを特定のページの下にあるjcr:contentノードにのみ配置すると、特定のページのコンテンツs.strへのアクセスは制限されますが、兄弟ページや子ページには影響しません。 場合によってはこうしたケースも有効で、きめ細かなアクセスコンテンツを適用可能なリポジトリエディターによって達成できます。ただし、前の実装とは異なり、cq:cugEnabledプロパティをjcr:contentノードに配置すると、内部的にページノードに再マッピングされます。 こうしたマッピングは今後はおこなわれません。

CUG ポリシーによる権限評価

古い CUG サポートから追加の承認モデルに移行したことで、有効な読み取り権限の評価方法が変更されています。Jackrabbitドキュメントで説明されているように、CUGcontentを表示できる特定のプリンシパルは、Oakリポジトリで設定されたすべてのモデルの権限評価で読み取りアクセス権が付与された場合にのみ読み取りアクセス権が付与されます。

つまり、有効な権限の評価では、CUGPolicy とデフォルトのアクセス制御エントリの両方が考慮され、CUG コンテンツに対する読み取りアクセスは、両方のタイプのポリシーによって付与される場合にのみ付与されます。完全な/contentツリーへの読み取りアクセスが全員に許可されるデフォルトのAEMパブリッシュインストールでは、CUGポリシーの効果は、以前の実装と同じになります。

オンデマンド評価

CUG 承認モデルでは、アクセス制御管理と権限評価を個別にオンにできます。

• アクセス制御管理は、CUG を作成できるサポートパスがモジュールに 1 つ以上ある場合に有効になります。
• 権限評価は、「CUG Evaluation Enabled」オプションが追加でオンになっている場合にのみ有効になります。

新しい AEM のデフォルトセットアップにおける CUG ポリシーの評価では、オンデマンド評価は「パブリッシュ」実行モードでのみ有効になります。詳しくは、AEM 6.3 以降のデフォルト設定を参照してください。これは、特定のパスに対する有効なポリシーと、コンテンツに保存されたポリシーとを比較することで検証できます。 有効なポリシーは、CUG の権限評価が有効になっている場合にのみ表示されます。

上述のように、CUGアクセス制御ポリシーは常にコンテンツに保存されますが、これらのポリシーによる有効な権限の評価は、Apache Jackrabbit Oak CUG Configurationのシステムコンソールで CUG Evaluation Enabled がオンになった場合にのみ実行されます。 デフォルトでは、「公開」実行モードでのみ有効になります。

認証の違い

以下では、認証の違いを説明します。

認証要件に専用の Mixin タイプ

前の実装では、CUG の承認と認証に関連するパーツは、単一の JCR プロパティ（cq:cugEnabled）によって呼び出されました。認証に関する限り、これによって、Apache Sling Authenticator 実装で保存される認証要件の更新リストが得られました。新しい実装では、これと同じことが、専用の mixin タイプ（granite:AuthenticationRequired）でターゲットノードをマークすることで達成されます。

ログインパスを除外するためのプロパティ

mixin型は、granite:loginPathと呼ばれる、オプションの1つのプロパティを定義します。基本的にはcq:cugLoginPageプロパティに対応します。 前の実装とは対照的に、ログインパスプロパティは、その宣言ノードタイプが前述の mixin の場合にのみ考慮されます。mixin タイプを設定せずに、その名前でプロパティを追加しても有効にならず、新しい要件もログインパスの除外も認証にレポートされません。

認証要件の権限

mixin タイプを追加または削除するには、jcr:nodeTypeManagement 権限が付与されている必要があります。前の実装では、jcr:modifyProperties権限を使用して残りのプロパティを編集します。

granite:loginPath に関する限り、残余プロパティを追加、変更または削除するには同じ権限が必要です。

Mixin タイプによって定義されるターゲットノード

認証要件は、通常は、強制的なログインの対象となるサブツリーを定義する JCR ノードで作成されます。CUG がツリー全体に影響する場合は、これが AEM ページになると思われ、この新しい実装の UI により、結果として、認証要件 mixin タイプがそのページノードに追加されます。

CUGポリシーを特定のページの下にあるjcr:contentノードにのみ配置すると、そのコンテンツへのアクセスは制限されますが、ページノード自体や子ページには影響しません。

場合によってはこうしたケースも有効で、任意のノードに mixin を配置できるリポジトリエディターによって達成できます。ただし、前者の実装とは異なり、jcr:contentノードにcq:cugEnabledまたはcq:cugLoginPageプロパティを配置すると、内部的にページノードに再マッピングされました。 こうしたマッピングは今後はおこなわれません。

設定済みのサポートパス

granite:AuthenticationRequired mixin型とgranite:loginPathプロパティはどちらも、AdobeGranite Authentication RequirementとLogin Path Handler​にある​Supported Paths​構成オプションのセットで定義される範囲内でのみ考慮されます。 これらのパスが指定されていないと、認証要件機能は全体で無効になります。この場合、ミックスインのタイプやプロパティは、特定のJCRノードに追加または設定されると有効になります。

JCR コンテンツ、OSGi サービスおよび設定のマッピング

以下のドキュメントでは、OSGiサービス、設定、およびリポジトリの内容を、以前の実装と新しい実装の間で包括的にマッピングしています。

AEM 6.3 以降の CUG の対応関係

ファイルを入手

CUG のアップグレード

廃止された CUG を使用した既存のインストール

古い CUG サポートの実装は廃止され、将来のバージョンでは削除されます。AEM 6.3 より前のバージョンからのアップグレード時に新しい実装に移行することが推奨されます。

アップグレードされた AEM のインストールには、1 つの CUG 実装のみが有効であることを確認してください。新しい CUG サポートと廃止された CUG サポートの組み合わせはテストされていないので、次のような問題が発生する場合があります。

• Sling Authenticator で認証要件が競合する。
• 古い CUG に関連する ACL セットアップと新しい CUG ポリシーが相反して、読み取りアクセスが拒否される。

既存の CUG コンテンツの移行

Adobe は、新しい CUG 実装への移行ツールを提供しています。このツールを使用するには、次の手順をおこないます。

1. https://<serveraddress>:<serverport>/system/console/cug-migrationに移動してツールにアクセスします。
2. CUG を調べるルートパスを入力し、「Perform dry run」ボタンを押します。選択した場所で変換に適したCUGがスキャンされます。
3. 結果を確認した後、「Perform migration」ボタンを押して、新しい実装に移行します。