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 は、ターゲットノードにアタッチされている既存のアクセス制御コンテンツには置き換わりません。 それどころかこれは補足であり、元のアクセス制御に影響を与えずに後で削除することもできます。AEM のデフォルトでは、アクセス制御リストになります。

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

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

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

CUG ポリシーの権限評価と、デフォルトまたは追加の承認モデルとのやり取りは、Apache Jackrabbit Oak の複数の承認メカニズム用に設計されたパターンに従います。 つまり、すべてのモデルがアクセス権を付与する場合にのみ、特定の権限セットが付与されます。 詳しくは、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 での認証要件の強制方法について詳しくは、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 のドキュメントに記載されています。 詳しくは、CUG によるアクセスの管理に関するJackrabbit 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 (for example,
                                                   // 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);
}

プリンシパルによる 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

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

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

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

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

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

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

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

また、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 認証モジュールに関連する設定オプションのリストとその詳細については、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 サポートの代わりとなる認証要件を設定するには、特定の AEM インストールにいくつかの OSGi コンポーネントが存在し、アクティブになっている必要があります。 詳しくは、後述の OSGi コンポーネントの特性​を参照してください。

OSGi コンポーネントの特性

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

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

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

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

CUG の書き換えの認証関連のパーツは、Adobe Granite 認証要件とログインパスハンドラーに関連する単一の設定オプションにのみ付属しています。

「認証要件とログインパスハンドラー」

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

AEM の新規インストールでは、デフォルトで、CUG 機能の承認関連と認証関連のパーツの両方で新しい実装を使用します。 旧実装「Adobe Granite Closed User Group (CUG) Support」は廃止されており、すべての 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 認証要件とログインパスハンドラー​に関連する設定を削除するだけで十分です。

他のモジュールの操作 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 の節を参照してください。

Adobe Granite Replication adobe-granite-replication

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

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

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

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

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

AEM ライブコピー aem-livecopy

ライブコピーへの CUG の設定は、次のようにノードとプロパティを 1 つずつ追加することでリポジトリに表現されます。

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

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

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

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

CUG のセットアップと設定の違い differences-in-cug-setup-and-configuration

廃止された OSGi コンポーネント Adobe Granite の閉じられたユーザーグループ（CUG）のサポート（com.day.cq.auth.impl.cug.CugSupportImpl）は、新しいコンポーネントに置き換えられ、以前の CUG 機能の承認関連のパーツと認証関連のパーツを個別に扱えるようになりました。

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

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

認証に関する違い differences-with-regards-to-authorization

承認の観点からの主な違いを以下にまとめます。

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

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

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

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

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

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

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

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

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

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

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

オンデマンド評価

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

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

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

認証の違い 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 がツリー全体に影響すると見込まれる場合は、これが AEM ページになる可能性が高いので、新しい実装の UI では、そのページノードに認証要件 mixin タイプを追加します。

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

場合によっては、こうしたケースも有効なシナリオであり、任意のノードに mixin を配置できるリポジトリエディターを使用して実現できます。 ただし、この動作は、jcr:content ノード上にcq:cugEnabledまたはcq:cugLoginPage プロパティを配置すると、最終的にページノードに内部的に再マッピングされる以前の実装とは対照的です。 こうしたマッピングは今後は行われません。

設定済みのサポートパス 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

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