AEM 6.3 より、「閉じられたユーザーグループ」という新しい実装が組み込まれています。これは、既存の実装が抱えていたパフォーマンス、スケーラビリティおよびセキュリティ上の問題を解決するためのものです。
このドキュメントでは、説明を簡略にするために、閉じられたユーザーグループ(Closed User Group)を「CUG」という略語で表記します。
新しい実装の目標は、必要に応じて既存の機能を対象とし、古いバージョンの問題や設計上の制限に対処することです。 その結果として、次の特性を持つ新しい CUG デザインが生まれました。
CUG は、AEM のコンテキストで知られるように、次の手順で構成されます。
この新しい実装では、認証要素と承認要素が切り離されています。AEM 6.3 の時点では、認証要件を明示的に追加しなくても、読み取りアクセスを制限できます。例えば、特定のインスタンス全体で認証が必要な場合や、既に認証を必要としているサブツリー内に特定のツリーが既に存在している場合はそうです。
同様に、有効な権限設定を変更せずに、特定のツリーに認証要件をマークすることもできます。 これらの組み合わせと結果については、CUG ポリシーと認証要件の組み合わせの節に示します。
CUG の重要な機能は、コンテンツリポジトリ内の特定のツリーに対する読み取りアクセスを制限することです(選択されたプリンシパルを除く)。新しい実装では、実行中にデフォルトのアクセス制御コンテンツを操作しません。これまでとは異なるアプローチとして、CUG を表す専用のアクセス制御ポリシータイプを定義します。
この新しいタイプのポリシーは、次の特性を持ちます。
CUGを表すために使用されるPrincipalSetPolicyの実装には、次の定義も含まれます。
これらのCUGポリシーは、oak-authorization-cugと呼ばれる別の認証モジュールを介してAEMインスタンスにデプロイされます。 このモジュールは、独自のアクセス制御管理および権限評価に付属しています。つまり、デフォルトの AEM のセットアップには、複数の承認メカニズムを組み合わせた Oak コンテンツリポジトリ設定が付属しています。詳しくは、Apache Oak Documentation](https://jackrabbit.apache.org/oak/docs/security/authorization/composite.html)の[このページを参照してください。
この複合セットアップでは、新しいCUGは、ターゲットノードにアタッチされた既存のアクセス制御コンテンツを置き換えませんが、補助として設計されており、AEMではデフォルトでアクセス制御リストとなり、元のアクセス制御に影響を与えずに後で削除できます。
前の実装とは対照的に、新しい CUG ポリシーは常にアクセス制御コンテンツとして認識、処理されます。つまり、新しい CUG ポリシーは、JCR アクセス制御管理 API を使用して作成、編集されるということです。詳しくは、CUGポリシーの管理の節を参照してください。
CUG の専用アクセス制御管理とは別に、新しい承認モデルでは、CUG ポリシーの権限評価を条件付きで有効にできます。このモデルでは、CUG ポリシーをステージング環境に設定しておき、実稼動環境にレプリケーションされた後で、有効な権限の評価を有効にするという手法を使用できます。
CUG ポリシーの権限評価と、デフォルトまたは追加の承認モデルとの連携は、Apache Jackrabbit Oak の複数の承認メカニズム用に設計されたパターンに従います。つまり、すべてのモデルがアクセスを付与する場合にのみ、特定の権限セットが付与されます。詳しくは、このページを参照してください。
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 に関するドキュメントを参照してください。
セキュリティ上の理由から、新しい実装は、残りのJCRプロパティの使用をgranite:AuthenticationRequired
と呼ばれる専用のmixin型に置き換えます。この型は、ログインパスgranite:loginPath
にSTRING型の1つのオプションのプロパティを定義します。 この mixin タイプに関連するコンテンツが変更された場合にのみ、Apache Sling Authenticator に登録される要件が更新されます。一時的な変更が行われると、変更が追跡されるので、有効にするにはjavax.jcr.Session.save()
呼び出しが必要です。
granite:loginPath
プロパティにも同様です。 認証要件に関連するミックスインの種類で定義されている場合にのみ考慮されます。 この名前を持つ残存のプロパティを非構造化JCRノードに追加しても、望ましい効果は表示されず、OSGi登録を更新するハンドラによってそのプロパティは無視されます。
ログインパスプロパティの設定はオプションです。ログインパスプロパティは、認証を必要とするツリーがデフォルトまたは継承されたログインページにフォールバックできない場合にのみ設定する必要があります。詳しくは、後述のログインパスの評価を参照してください。
この認証要件は、特定の実行モードとコンテンツリポジトリ内の小さなツリーのサブセットに限定されると考えられるので、要件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から、LoginSelectorHandler
で定義される「ログインページのマッピング」からLoginSelectorHandler
で定義されている「デフォルトログインページ」にフォールバックします。前述の呼び出しから有効なログインパスが取得されると、ユーザーのリクエストはすぐに、そのページにリダイレクトされます。
このドキュメントのターゲットは、内部LoginPathProvider
インターフェイスで公開されるログインパスの評価です。 AEM 6.3 以降に付属する実装は、次のように動作します。
ログインパスの登録は、リダイレクトの理由が、パスワードの失効であるか、通常のログインに必要な処理であるかによって異なります。
通常のログインに必要な処理である場合は、ログインパスを取得できるかどうかを、以下の順序で確認します。
com.adobe.granite.auth.requirement.impl.RequirementService
が実装したLoginPathProvider
から、LoginSelectorHandler
で定義されている「ログインページのマッピング」からLoginSelectorHandler
で定義されている「デフォルトログインページ」にフォールバックします。前述の呼び出しから有効なログインパスが取得されると、ユーザーのリクエストはすぐに、そのページにリダイレクトされます。
Graniteの新しい認証要件サポートによって実装されたLoginPathProvider
は、granite:loginPath
プロパティで定義されたログインパスを公開します。その後、上記のmixinタイプで定義されます。 ログインパスとプロパティ値自体を保持するリソースパスのマッピングはメモリ内に保存され、階層内にある他のノードの適切なログインパスを検出するために評価されます。
この評価は、設定済みのサポートパス内に存在するリソースに関連付けられているリクエストに対してのみ実行されます。それ以外のリクエストについては、ログインパスを判定する別の方法が評価されます。
認証要件を定義する際は、次のベストプラクティスを考慮する必要があります。
認証要件のネストを回避します。ツリーの先頭部に認証要件マーカーを 1 つ配置するだけで十分です。そのマーカーは、ターゲットノードによって定義されるサブツリー全体に継承されます。そのツリー内に他の認証要件があると、Apache Sling 内で認証要件を評価する際にパフォーマンス上の問題となる可能性があります。承認と認証に関連する CUG エリアを切り離すことで、CUG やその他のポリシーによって読み取りアクセスを制限すると同時に、ツリー全体に認証を適用できます。
ネストされたサブツリーを再度要件から除外する必要なく、認証要件がツリー全体に適用されるようなモデルリポジトリコンテンツ。
余分なログインパスの指定を回避するには、次のようにします。
LoginSelectorHandler
に関連付けられるグローバルなログインパス設定(デフォルトとマッピングの両方)に設定する必要があるログインパスを識別してください。Oakのドキュメントでは、新しいCUGポリシーがリポジトリのコンテンツにどのように反映されるかについて説明します。 詳しくは、このページを参照してください。
個別の認証要件の必要性は、専用のミックスインノードタイプをターゲットノードに配置したリポジトリコンテンツに反映されます。 この mixin タイプは、オプションのプロパティを定義して、ターゲットノードによって定義されるツリーの専用ログインページを指定します。
ログインパスに関連付けられるページは、ツリーの内部または外部のいずれにでも配置できます。このページは、認証要件から除外されます。
[granite:AuthenticationRequired]
mixin
- granite:loginPath (STRING)
CUGの読み取りアクセスを制限する新しいタイプのアクセス制御ポリシーは、JCRアクセス制御管理APIを使用して管理され、JCR 2.0仕様で説明されているメカニズムに従います。
次のコードは、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 ポリシーを編集するには、次の手順が必要です。変更したポリシーを書き戻す必要があり、変更は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");
}
JCR アクセス制御管理では、特定のパスで有効なポリシーを取得する最善の方法を定義します。CUGポリシーの評価は条件付きで、有効にする対応する設定に依存するため、getEffectivePolicies
を呼び出すと、特定の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 を検出します。詳しくは、設定オプションの節を参照してください。
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);
}
プリンシパルによるアクセス制御ポリシーの編集を許可するJackrabbitAccessControlManager
によって定義される拡張は、CUGアクセス制御管理では実装されません。CUGポリシーは常にすべてのプリンシパルに影響を与えます。PrincipalSetPolicy
と共にリストされるプリンシパルは読み取りアクセス権を付与されますが、ターゲットノードによって定義されるツリー内のコンテンツを他のプリンシパルが読み取ることはできません。
これらに対応するメソッドは常に、空のポリシー配列を返しますが、例外はスローしません。
新しい認証要件の作成、変更、または削除は、ターゲットノードの有効なノードタイプを変更することで達成される。 その後、オプションのログインパスプロパティへの書き込みには、通常の JCR API を使用できます。
上述の特定のターゲットノードに対する変更は、RequirementHandler
が設定され、ターゲットがサポートされるパスで定義されたツリーに含まれている場合にのみ、Apache Sling認証子に反映されます(「設定オプション」を参照)。
詳しくは、[Mixinノードタイプの割り当て](https://docs.adobe.com/docs/en/spec/jcr/2.0/10_Writing.html#10.10.3 Mixinノードタイプの割り当て)およびノードの追加とプロパティの設定を参照してください。
次に、新しい認証要件の作成手順を示します。ターゲットノードを含むツリーに対して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 にどのように反映されるかを示しています。
この例では、オプションのログインパスプロパティは設定されていません。したがって、認証に登録される 2 番目のエントリはありません。
現在、認証が必要なリソースに匿名でアクセスした場合に有効となるログインパスを取得するパブリック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();
}
}
次の表に、両方のモジュールが設定を介して有効になっている AEM インスタンスでの、CUG ポリシーと認証要件の有効な組み合わせを示します。
認証が必要です | ログインパス | 制限付き読み取りアクセス | 期待効果 |
---|---|---|---|
可 | 可 | 可 | 有効な権限評価でアクセスが許可されている場合、特定のユーザーがCUGポリシーでマークされたサブツリーの表示のみを実行できます。 未認証ユーザーは、指定されたログインページにリダイレクトされます。 |
可 | 不可 | 可 | 有効な権限評価でアクセスが許可されている場合、特定のユーザーがCUGポリシーでマークされたサブツリーの表示のみを実行できます。 認証されていないユーザーは、継承されたデフォルトのログインページにリダイレクトされます。 |
可 | 可 | 不可 | 未認証ユーザーは、指定されたログインページにリダイレクトされます。 認証要件でマークされているツリーを表示できるかどうかは、そのサブツリーに含まれる個々のアイテムの有効な権限に応じます。読み取りアクセスを制限する専用の CUG はありません。 |
可 | 不可 | いいえ | 認証されていないユーザーは、継承されたデフォルトのログインページにリダイレクトされます。認証要件でマークされているツリーを表示できるかどうかは、そのサブツリーに含まれる個々のアイテムの有効な権限に応じます。読み取りアクセスを制限する専用の CUG はありません。 |
不可 | 不可 | 可 | 特定の認証済みユーザーまたは未認証ユーザーは、有効な権限評価によってアクセスが許可される場合にのみ、CUGポリシーでマークされたサブツリーを表示できます。 認証されていないユーザーも同じように処理され、ログインにリダイレクトされません。 |
「ログインパス」は、認証要件に関連するオプションの属性なので、「認証要件」 = なし、「ログインパス」 = ありの組み合わせは存在しません。定義するmixin型を追加せずにJCRプロパティをその名前で指定しても、影響はなく、対応するハンドラーでは無視されます。
この節では、新しい CUG 実装によって導入された OSGi コンポーネントと個々の設定オプションの概要を示します。
古い実装と新しい実装の設定オプションの包括的なマッピングについては、CUGマッピングのドキュメントも参照してください。
新しい承認関連のパーツは、AEM のデフォルトインストールの一部である Oak CUG Authorization バンドル(org.apache.jackrabbit.oak-authorization-cug
)に含まれています。このバンドルは、読み取りアクセスを管理する追加の方法として導入される、別の承認モデルを定義します。
CUG認証の設定については、関連するApacheドキュメントで詳しく説明しています。 AEM ではデフォルトで、CUG 承認はすべての実行モードに導入されています。別の承認セットアップを必要とするインストールでは、CUG 承認を無効にすることもできます。
また、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
認証要件を定義して、専用のログインパスを指定するために、次の 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権限の設定と評価に専用の認証設定。 |
設定プロパティ |
また、下記の設定オプションも参照してください。 |
構成ポリシー | ConfigurationPolicy.REQUIRE |
参照 | CugExclude (ReferenceCardinality.OPTIONAL_UNARY) |
org.apache.jackrabbit.oak.spi.security.authorization.cug.impl.CugExcludeImpl
ラベル | Apache Jackrabbit Oak CUG除外リスト |
説明 | 設定された名前を持つプリンシパルをCUG評価から除外できます。 |
設定プロパティ |
後述の「設定オプション」セクションも参照してください。 |
構成ポリシー | ConfigurationPolicy.REQUIRE |
参照 | 該当なし |
主な設定オプションは次のとおりです。
cugSupportedPaths
:CUG を含むことができるサブツリーを指定します。デフォルト値は設定されません。cugEnabled
:現在の CUG ポリシーに対して権限評価を有効にする設定オプション。CUG 承認モジュールに関連する設定オプションの一覧と、その詳細な説明については、Apache Oak ドキュメントを参照してください。
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 コンポーネントの特性を参照してください。
RequirementHandler による必須の設定オプションがあるので、認証関連のパーツは、サポートパスのセットを指定することで、この機能が有効になっている場合にのみアクティブになります。AEM の標準インストールの場合、この機能はオーサー実行モードでは無効で、パブリッシュ実行モードでは /content に対して有効になります。
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 |
参照 |
|
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 の新規インストールでは、デフォルトで、CUG 機能の承認関連と認証関連のパーツの両方で新しい実装を使用します。旧実装「Adobe Granite Closed User Group (CUG) Support」は廃止されていて、すべての AEM インストールでデフォルトで無効になります。代わりに、新しい実装は、次のように有効になります。
"Apache Jackrabbit Oak CUG Configuration" | 説明 |
---|---|
サポートされるパス/content |
CUGポリシーのアクセス制御管理が有効になっています。 |
CUG評価が有効なFALSE | 権限の評価が無効になっています。 CUG ポリシーは無効です。 |
ランキング | 200 |
デフォルトのオーサリングインスタンスに、Apache Jackrabbit Oak CUG Exclude List と Adobe Granite Authentication Requirement and Login Path Handler の設定は提供されません。
"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 承認モデルを削除する方法について詳しくは、プラグの可/不可に関するドキュメントを参照してください。
granite.auth.authhandler
モジュールが提供する認証要件のサポートを無効にするには、Adobe Granite Authentication Requirement and Login Path Handler に関連する設定を削除するだけで十分です。
設定を削除しても mixin タイプの登録は解除されません。mixin タイプは、有効にしなくても引き続きノードに適用可能です。
CUG 承認モデルで使用する新しいタイプのアクセス制御ポリシーを強化するために、Apache Jackrabbit で定義される API が拡張されています。jackrabbit-api
モジュールのバージョン2.11.0以降では、javax.jcr.security.AccessControlPolicy
から拡張するorg.apache.jackrabbit.api.security.authorization.PrincipalSetPolicy
と呼ばれる新しいインターフェイスが定義されています。
Apache Jackrabbit FileVaultのインポートメカニズムは、PrincipalSetPolicy
型のアクセス制御ポリシーに対応するように調整されました。
詳しくは、前述の Apache Jackrabbit FileVault の節を参照してください。
このレプリケーションモジュールは、異なる 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 HTTP Header Authentication Handlercom.adobe.granite.auth.authhandler
は、同じモジュールによって定義される CugSupport
インターフェイスへの参照を保持します。これは、特定の環境内での「領域」の計算に使用され、このハンドラーによって設定される領域にフォールバックします。
このモジュールは、CugSupport
への参照をオプションとして使用できるように調整されました。この調整により、既に廃止されている実装を特定のセットアップで再度有効にしても、最大限の後方互換性を確保できます。実装を使用したインストールでは、CUG実装から抽出された領域は取得されなくなりますが、AdobeGranite HTTP Header Authentication Handlerで定義された領域が常に表示されます。
デフォルトでは、Adobe Granite HTTP Header Authentication Handler は、「Disable Login Page」(auth.http.nologin
)オプションが有効になっているパブリッシュ実行モードでのみ設定されます。
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 グループをブループリントからライブコピーにロールバックすることはできません。ライブコピーを設定するときはご注意ください。
この節では、CUG 機能に加えられた変更点の概要を示し、新旧の実装を比較します。CUG サポートの設定方法に影響する変更点を挙げます。また、リポジトリコンテンツにおける CUG の管理方法とその管理者についても説明します。
廃止された OSGi コンポーネント Adobe Granite Closed User Group (CUG) Support(com.day.cq.auth.impl.cug.CugSupportImpl
)は、新しいコンポーネントに置き換えられ、前の 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 承認モデルでは、アクセス制御管理と権限評価を個別にオンにできます。
新しい AEM のデフォルトセットアップにおける CUG ポリシーの評価では、オンデマンド評価は「パブリッシュ」実行モードでのみ有効になります。詳しくは、AEM 6.3 以降のデフォルト設定を参照してください。これは、特定のパスに対する有効なポリシーと、コンテンツに保存されたポリシーとを比較することで検証できます。 有効なポリシーは、CUG の権限評価が有効になっている場合にのみ表示されます。
上述のように、CUGアクセス制御ポリシーは常にコンテンツに保存されますが、これらのポリシーによる有効な権限の評価は、Apache Jackrabbit Oak CUG Configurationのシステムコンソールで CUG Evaluation Enabled がオンになった場合にのみ実行されます。 デフォルトでは、「公開」実行モードでのみ有効になります。
以下では、認証の違いを説明します。
前の実装では、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
に関する限り、残余プロパティを追加、変更または削除するには同じ権限が必要です。
認証要件は、通常は、強制的なログインの対象となるサブツリーを定義する 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ノードに追加または設定されると有効になります。
以下のドキュメントでは、OSGiサービス、設定、およびリポジトリの内容を、以前の実装と新しい実装の間で包括的にマッピングしています。
AEM 6.3 以降の CUG の対応関係
古い CUG サポートの実装は廃止され、将来のバージョンでは削除されます。AEM 6.3 より前のバージョンからのアップグレード時に新しい実装に移行することが推奨されます。
アップグレードされた AEM のインストールには、1 つの CUG 実装のみが有効であることを確認してください。新しい CUG サポートと廃止された CUG サポートの組み合わせはテストされていないので、次のような問題が発生する場合があります。
Adobe は、新しい CUG 実装への移行ツールを提供しています。このツールを使用するには、次の手順をおこないます。
https://<serveraddress>:<serverport>/system/console/cug-migration
に移動してツールにアクセスします。問題が発生した場合、特定のロガーをcom.day.cq.auth.impl.cug
のDEBUGレベルに設定して、移行ツールの出力を取得できます。 詳細については、ロギングを参照してください。