AEM の閉じられたユーザーグループ closed-user-groups-in-aem

はじめに introduction

AEM 6.3 以降には、新しい閉じられたユーザーグループ実装があり、既存の実装に存在するパフォーマンス、拡張性、セキュリティの問題に対処することを目的としています。

この新しい実装の目的は、必要に応じて既存の機能をカバーすると同時に、旧バージョンからの問題や設計上の制限に対応することです。その結果、次の特性を持つ新しい CUG デザインが作成されます。

新しいカスタムユーザーグループの実装 the-new-custom-user-group-implementation

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

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

同様に、有効な権限設定を変更しなくても、特定のツリーに認証要件をマークできます。組み合わせと結果は、 CUG ポリシーと認証要件の組み合わせ 」セクションに入力します。

概要 overview

認証：読み取りアクセスの制限 authorization-restricting-read-access

CUG の主な機能は、選択したプリンシパル以外のすべてのユーザーに対して、コンテンツリポジトリ内の特定のツリーに対する読み取りアクセスを制限することです。 デフォルトのアクセス制御コンテンツをその場で操作する代わりに、CUG を表す専用のアクセス制御ポリシーを定義することで、新しい実装では異なるアプローチを取ります。

CUG のアクセス制御ポリシー access-control-policy-for-cug

この新しいタイプのポリシーには、次の特徴があります。

CUG の表現に使用される PrincipalSetPolicy の実装は、さらに次も定義します。

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

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

以前の実装とは異なり、新しい CUG ポリシーは常にアクセス制御コンテンツとして認識され、扱われます。 これは、JCR アクセス制御管理 API を使用して作成および編集されることを意味します。 詳しくは、CUG ポリシーの管理の節を参照してください。

CUG ポリシーの権限評価 permission-evaluation-of-cug-policies

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

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

CUG ポリシーの処理と評価を目的とした認証モデルに関連する権限評価には、次の特性が適用されます。

1 つの CUG ポリシーが権限評価に与える影響は、次のように要約できます。

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

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

認証：認証要件の定義 authentication-defining-the-auth-requirement

CUG 機能の認証関連の部分を使用すると、認証が必要なツリーをマークし、必要に応じて専用のログインページを指定できます。 旧バージョンに準じて、新しい実装では、コンテンツリポジトリ内で認証を必要とするツリーをマークできます。また、条件によっては、Sling org.apache.sling.api.auth.Authenticator との同期を有効にして、強制的に要件を適用し、ログインリソースにリダイレクトすることも可能です。

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

専用の Mixin タイプを使用した認証要件の定義 defining-the-authentication-requirement-with-a-dedicated-mixin-type

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

同じことが granite:loginPath プロパティにも当てはまります。認証要件関連の mixin タイプで定義されている場合にのみ考慮されます。 残存しているプロパティをこの名前で非構造化 JCR ノードに追加しても、期待した効果は得られず、OSGi 登録を更新するハンドラーはこのプロパティを無視します。

Sling Authenticator を使用した認証要件およびログインパスの登録 registering-the-authentication-requirement-and-login-path-with-the-sling-authenticator

このタイプの認証要件は、特定の実行モードと、コンテンツリポジトリにあるツリーの小さいサブセットに限定されることが想定されるため、認証要件の mixin タイプおよびログインパスプロパティの追跡すると結果は条件次第となり、サポートパスが定義された該当する設定に関連付けられます（詳しくは、後述の「設定オプション」を参照してください）。したがって、サポートパスの有効範囲内で変更があった場合にのみ、OSGi 登録の更新が実行され、それ以外の場所では、mixin タイプもログインパスプロパティも無視されます。

デフォルトの AEM セットアップでは、この設定を利用できるようにするために、mixin を author 実行モードで設定し、その設定をパブリッシュインスタンスへのレプリケーション時にのみ有効にできるようになりました。Sling での認証要件の強制方法について詳しくは、このページを参照してください。

granite:AuthenticationRequired mixin タイプを設定済みのサポートパス内に追加すると、関係するハンドラーの OSGi 登録が更新され、sling.auth.requirements プロパティを含む新しいエントリが追加されます。特定の認証要件がオプション granite:loginPath プロパティの値は、認証要件から除外するために、Authenticator に「 — 」プレフィックスと共に登録されます。

認証要件の評価と継承 evaluation-and-inheritance-of-the-authentication-requirement

Apache Sling 認証の要件は、ページまたはノード階層を通じて継承されると想定されます。 継承の詳細と、順序や優先順位などの認証要件の評価は実装の詳細と見なされ、この記事には記載されません。

ログインパスの評価 evaluation-of-login-path

認証時の対応リソースへのログインパスとリダイレクトの評価は、現在、Adobe Granite Login Selector Authentication Handler（com.day.cq.auth.impl.LoginSelectorHandler）の詳細で実装されています。このハンドラーは、AEM にデフォルトで設定されている Apache Sling AuthenticationHandler です。

AuthenticationHandler.requestCredentials を呼び出すと、このハンドラーは、ユーザーのリダイレクト先となるマッピングログインページの特定を試みます。これには、次の手順が含まれます。

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

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

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

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

リポジトリでの表現 representation-in-the-repository

リポジトリ内の CUG ポリシー表現 cug-policy-representation-in-the-repository

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

リポジトリの認証要件 authentication-requirement-in-the-repository

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

ログインパスに関連付けられたページは、そのツリーの内部または外部に配置される場合があります。 認証要件から除外されます。

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

CUG ポリシーと認証要件の管理 managing-cug-policies-and-authentication-requirement

CUG ポリシーの管理 managing-cug-policies

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

新しい CUG ポリシーを設定 set-a-new-cug-policy

以前に 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 ポリシーの編集 edit-an-existing-cug-policy

既存の 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 ポリシーの取得 retrieve-effective-cug-policies

JCR アクセス制御管理では、特定のパスで有効なポリシーを取得するためのベストエフォート方式を定義します。 CUG ポリシーの評価は、対応する設定が有効になっているかどうかが条件となるので、特定の CUG ポリシーが特定のインストールで有効かどうかを調べるには、getEffectivePoliciesを呼び出すと簡単です。

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 ポリシーの取得 retrieve-inherited-cug-policies

特定のパスで定義されたネストされた 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);
}

Pincipal による CUG ポリシーの管理 managing-cug-policies-by-pincipal

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

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

認証要件の管理 managing-the-authentication-requirement

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

新しい認証要件の追加 adding-a-new-auth-requirement

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

Node targetNode = [...]

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

ログインパスを使用した新しい認証要件の追加 add-a-new-auth-requirement-with-login-path

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

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

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

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

既存のログインパスの変更 modify-an-existing-login-path

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

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");
}

既存のログインパスの削除 remove-an-existing-login-path

既存のログインパスを削除する手順です。 ログインパスのエントリは、ターゲットノードを含むツリーに 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();
}

認証要件の削除 remove-an-auth-requirement

既存の認証要件を削除する手順です。 この要件は、Apache Sling Authenticator からの登録が解除されるのは、 RequirementHandler は、ターゲットノードを含むツリー用に設定されています。

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

session.save();

有効な認証要件の取得 retrieve-effective-auth-requirements

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

次の画像は、デモコンテンツを含むAEMパブリッシュインスタンスの認証要件を示しています。 強調表示されているコミュニティページのパスは、このドキュメントで説明する実装によって追加された要件が Apache Sling Authenticator にどのように反映されるかを示しています。

有効なログインパスの取得 retrieve-the-effective-login-path

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

ただし、この機能で定義されたログインパス以外に、ログインへのリダイレクトを指定する別の方法があります。この方法は、コンテンツモデルを設計する際や、特定のAEMインストールの認証要件を考慮に入れる必要があります。

継承された認証要件の取得 retrieve-the-inherited-auth-requirement

ログインパスと同様に、コンテンツに定義されている継承された認証要件を取得するパブリック 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 ポリシーと認証要件の組み合わせ combining-cug-policies-and-the-authentication-requirement

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

OSGi コンポーネントと設定 osgi-components-and-configuration

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

また、CUG マッピングに関するドキュメントを参照して、新旧の実装間での設定オプションの全体的な対応関係を確認してください。

承認：セットアップと設定 authorization-setup-and-configuration

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

CUG 認証の設定 setting-up-cug-authorization

CUG 承認のセットアップについては、関連する Apache ドキュメントに詳しく記載されています。デフォルトでは、AEMにはすべての実行モードで CUG 認証がデプロイされています。 別の認証設定が必要なインストールでは、CUG 認証を無効にする手順も使用できます。

リファラーフィルタの設定 configuring-the-referrer-filter

また、CDN やロードバランサーなどを介した AEM へのアクセスに使用できるすべてのホスト名を含む Sling 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 コンポーネントの特性 characteristics-of-osgi-components

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

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

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

設定オプション configuration-options

重要な設定オプションは次の通りです。

CUG-authorization モジュールに関連する使用可能な設定オプションが次の場所にリストされ、詳しく説明されています： Apache Oak ドキュメント.

CUG 評価からのプリンシパルの除外 excluding-principals-from-cug-evaluation

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

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

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

除外する「管理者」グループは、システムコンソールの Apache Jackrabbit Oak CUG Exclude List ​の設定セクションで変更または拡張できます。

また、特殊なニーズがある場合は、CugExclude インターフェイスのカスタム実装を提供、導入して、除外するプリンシパルのセットを調整することもできます。詳しい説明と実装例については、プラグの可／不可に関するドキュメントを参照してください。

認証：セットアップと設定 authentication-setup-and-configuration

新しい認証関連のパーツは、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

設定オプション configuration-options-1

CUG 書き換えの認証関連部分には、AdobeGranite Authentication Requirement および Login Path Handler に関連付けられた 1 つの設定オプションのみが付属しています。

認証要件およびログイン・パス・ハンドラ

AEM 6.3 以降のデフォルト設定 default-configuration-since-aem

AEMの新規インストールでは、デフォルトで、CUG 機能の認証関連部分と認証関連部分の両方に新しい実装が使用されます。 古い実装「AdobeGranite 閉じられたユーザーグループ (CUG) のサポート」は廃止され、すべてのAEMインストールでデフォルトで無効になります。 代わりに、新しい実装は次のように有効になります。

オーサーインスタンス author-instances

パブリッシュインスタンス publish-instances

CUG 認証および認証要件の無効化 disabling-cug-authorization-and-authentication-requirement

特定のインストールで CUG を使用しなかったり、認証と承認に別の手段を使用したりした場合に、新しい実装を完全に無効にすることができます。

CUG 認証を無効にする disable-cug-authorization

詳しくは、 CUG プラグ可能 複合承認設定から CUG 承認モデルを削除する方法の詳細に関するドキュメント。

認証要件の無効化 disable-the-authentication-requirement

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

他のモジュールとのインタラクション interaction-with-other-modules

Apache Jackrabbit API 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

Apache Jackrabbit FileVault の読み込みメカニズムは、タイプ PrincipalSetPolicy のアクセス制御ポリシーに対応するように調整されています。

Apache Sling コンテンツ配布 apache-sling-content-distribution

上記を参照 Apache Jackrabbit FileVault 」セクションに入力します。

AdobeGranite レプリケーション adobe-granite-replication

複数のAEMインスタンス間で CUG ポリシーをレプリケートできるように、レプリケーションモジュールが若干調整されました。

CUG ポリシーのレプリケーションには 1 つ制約があります。対応する Mixin ノードタイプ rep:CugMixin, を削除せずに、特定の CUG ポリシーを削除した場合、レプリケーション時に CUG ポリシーの削除が反映されません。これに対処するには、ポリシーの削除時に常に mixin を削除する必要があります。 ただし、mixin タイプを手動で追加すると、この制限が表示される場合があります。

AdobeGranite 認証ハンドラー adobe-granite-authentication-handler

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

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

AEM ライブコピー aem-livecopy

ライブコピーに関連した CUG の設定は、以下のようにノードとプロパティーを 1 つずつ追加することによってリポジトリーに表示されます。

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

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

新しい CUG 実装に伴う変更 changes-with-the-new-cug-implementation

この節の目的は、CUG 機能に加えられた変更の概要と、古い実装と新しい実装の比較を示すことです。 CUG サポートの設定方法に影響する変更をリストし、リポジトリコンテンツで CUG を管理する方法と方法を説明します。

CUG の設定と設定の違い diferences-in-cug-setup-and-configuration

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

リポジトリコンテンツにおける CUG の管理の違い differences-in-managing-cugs-in-the-repository-content

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

認可に関する違い diferences-with-regards-to-authorization

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

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

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

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

アクセス制御管理での CUG ポリシーの編集

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

ポリシーで定義されたターゲットノード

CUG ポリシーは、読み取りアクセスの制限を受けるサブツリーを定義する JCR ノードで作成される必要があります。 CUG がツリー全体に影響すると想定される場合、これはAEMページになる可能性があります。

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

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

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

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

オンデマンド評価

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

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

前述のように、CUG アクセス制御ポリシーは現在、コンテンツに保存されるようになりましたが、これらのポリシーの結果である有効な権限の評価は、「CUG Evaluation Enabled」が、システムコンソールの Apache Jackrabbit Oak CUG Configuration のシステムコンソールでオンになっている場合のみ適用されます。 デフォルトでは、「パブリッシュ」実行モードでのみ有効になります。

認証に関する相違点 differences-with-regards-to-authentication

認証に関する違いについては、以下で説明します。

認証要件用の専用 Mixin タイプ dedicated-mixin-type-for-authentication-requirement

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

ログインパスを除外するためのプロパティ property-for-excluding-login-path

Mixin タイプは、基本的に cq:cugLoginPage プロパティに対応する、granite:loginPath という名前の単一のオプションプロパティを定義します。以前の実装とは異なり、ログインパスプロパティは、宣言するノードタイプが前述の mixin の場合にのみ考慮されます。 mixin タイプを設定せずにその名前のプロパティを追加しても、効果がなく、新しい要件もログインパスの除外もオーセンティケーターに報告されません。

認証要件の権限 privilege-for-authentication-requirement

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

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

Mixin タイプで定義されたターゲットノード target-node-defined-by-mixin-type

認証要件は、強制的なログインの対象となるサブツリーを定義する JCR ノードで作成される必要があります。 CUG がツリー全体に影響を与え、新しい実装の UI が結果としてページノードに auth-requirement mixin タイプを追加する場合、これはAEMページの可能性が高くなります。

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

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

設定済みのサポート対象パス configured-supported-paths

granite:AuthenticationRequired mixin タイプと granite:loginPath プロパティは、Adobe Granite Authentication Requirement and Login Path Handler で提供される「サポートされているパス」設定オプションによって定義される適用範囲内でのみ考慮されます。これらのパスが指定されていないと、認証要件機能は全体で無効になります。その場合、Mixin タイプやプロパティを追加しても、特定の JCR ノードに設定しても、どちらも有効になりません。

JCR コンテンツ、OSGi サービスおよび設定のマッピング mapping-of-jcr-content-osgi-services-and-configurations

次のドキュメントでは、新旧の実装間での OSGi サービス、設定およびリポジトリコンテンツの包括的な対応関係について説明します。

AEM 6.3 以降の CUG の対応関係

ファイルを入手

CUG をアップグレード upgrade-cug

非推奨の CUG を使用した既存のインストール existing-installations-using-the-deprecated-cug

古い CUG サポート実装は廃止され、今後のバージョンでは削除される予定です。 AEM 6.3 より前のバージョンからアップグレードする場合は、新しい実装に移行することをお勧めします。

アップグレードされたAEMのインストールでは、1 つの CUG 実装のみが有効になっていることを確認することが重要です。 新しい CUG サポートと廃止された古い CUG サポートの組み合わせはテストされておらず、望ましくない動作を引き起こす可能性が高くなります。

既存の CUG コンテンツの移行 migrating-existing-cug-content

Adobeは、新しい CUG 実装に移行するためのツールを提供します。 この機能を使用するには、次の手順に従います。