AEM 6.3 以降には、新しい閉じられたユーザーグループ実装があり、既存の実装に存在するパフォーマンス、拡張性、セキュリティの問題に対処することを目的としています。
簡潔にするために、このドキュメント全体で CUG の省略形が使用されます。
この新しい実装の目的は、必要に応じて既存の機能をカバーすると同時に、旧バージョンからの問題や設計上の制限に対応することです。その結果、次の特性を持つ新しい CUG デザインが作成されます。
CUG は、AEMのコンテキストで知られているもので、次の手順で構成されます。
新しい実装は、認証要素と承認要素の間に線を引くように設計されています。 AEM 6.3 以降では、認証要件を明示的に追加することなく、読み取りアクセスを制限できます。 例えば、特定のインスタンス全体で認証が必要な場合や、特定のツリーが既に認証が必要なサブツリー内に存在する場合などです。
同様に、有効な権限設定を変更しなくても、特定のツリーに認証要件をマークできます。組み合わせと結果は、 CUG ポリシーと認証要件の組み合わせ 」セクションに入力します。
CUG の主な機能は、選択したプリンシパル以外のすべてのユーザーに対して、コンテンツリポジトリ内の特定のツリーに対する読み取りアクセスを制限することです。 デフォルトのアクセス制御コンテンツをその場で操作する代わりに、CUG を表す専用のアクセス制御ポリシーを定義することで、新しい実装では異なるアプローチを取ります。
この新しいタイプのポリシーには、次の特徴があります。
CUG の表現に使用される PrincipalSetPolicy の実装は、さらに次も定義します。
これらの CUG ポリシーは、oak-authorization-cug と呼ばれる別の認証モジュールを介して、AEM インスタンスに導入されます。このモジュールは、独自のアクセス制御管理および権限評価に付属しています。つまり、デフォルトのAEM設定には、複数の認証メカニズムを組み合わせた Oak コンテンツリポジトリ設定が付属しています。 詳しくは、この Apache Oak ドキュメントページを参照してください。
この複合セットアップでは、新しい CUG は、ターゲットノードに適用されている既存のアクセス制御コンテンツを置き換えません。ただし、この CUG は、元のアクセス制御に影響を与えずに後で削除可能な補助的要素として設計されており、AEM ではデフォルトでアクセス制御リストになります。
以前の実装とは異なり、新しい CUG ポリシーは常にアクセス制御コンテンツとして認識され、扱われます。 これは、JCR アクセス制御管理 API を使用して作成および編集されることを意味します。 詳しくは、CUG ポリシーの管理の節を参照してください。
CUG 専用のアクセス制御管理に加え、新しい承認モデルを使用すると、ポリシーの権限評価を条件付きで有効にできます。 これにより、ステージング環境で CUG ポリシーを設定し、実稼動環境にレプリケートされた後にのみ有効な権限の評価を有効にすることができます。
CUG ポリシーの権限評価と、デフォルトまたは追加の承認モデルとの連携は、Apache Jackrabbit Oak の複数の承認メカニズム用に設計されたパターンに従います。つまり、すべてのモデルがアクセスを付与する場合にのみ、特定の権限セットが付与されます。詳しくは、このページを参照してください。
CUG ポリシーの処理と評価を目的とした承認モデルに関連する権限評価には、次の特性が適用されます。
1 つの CUG ポリシーが権限評価に与える影響は、次のように要約できます。
CUG を介した制限付き読み取りアクセスを定義する際には、次のベストプラクティスを考慮する必要があります。
CUG は、読み取りアクセスの制限のために必要なのか、認証要件のために必要なのかを判断します。後者の場合、または両方が必要な場合は、認証要件の詳細について「ベストプラクティス」の節を参照してください
脅威の境界を特定し、データの機密性と、許可されたアクセスに関連する役割を明確に把握するために、保護する必要のあるデータまたはコンテンツの脅威モデルを作成します
一般的な認証関連の側面とベストプラクティスを念頭に置いて、リポジトリコンテンツと CUG をモデル化します。
CUG ポリシーでサポートされるパスをリポジトリ内のいくつかのツリーに制限して、パフォーマンスの最適化を可能にします。 例えば、AEM 6.3 以降のデフォルト値として出荷された/content ノードの下の CUG のみを許可します。
CUG ポリシーは、小さなプリンシパルのセットに対して読み取りアクセスを許可するように設計されています。 多数のプリンシパルが必要な場合は、コンテンツやアプリケーションのデザインの問題を強調表示する可能性があるので、再度検討する必要があります。
CUG 機能の認証関連の部分を使用すると、認証が必要なツリーにマークを付けたり、専用のログインページを任意で指定したりできます。 以前のバージョンに従って、新しい実装では、コンテンツリポジトリで認証が必要なツリーをマークし、条件付きで Sling org.apache.sling.api.auth.Authenticator
は、最終的に要件を強制し、ログインリソースにリダイレクトする役割を果たします。
これらの要件は、sling.auth.requirements
登録プロパティを提供する OSGi サービスによって Authenticator に登録されます。次に、これらのプロパティを使用して、認証要件を動的に拡張します。 詳しくは、 Sling ドキュメント.
セキュリティ上の理由から、新しい実装では、残存している JCR プロパティを、granite:AuthenticationRequired
という名前の専用の mixin タイプで置き換えます。この mixin タイプは、ログインパス granite:loginPath
に、STRING タイプの単一のオプションプロパティを定義します。この mixin タイプに関連するコンテンツが変更された場合にのみ、Apache Sling Authenticator に登録される要件が更新されます。この変更は、一時的な変更を永続化する際に追跡されるので、有効にするには javax.jcr.Session.save()
を呼び出す必要があります。
同じことが granite:loginPath
プロパティにも当てはまります。このプロパティは、認証要件に関連する mixin タイプによって定義される場合にのみ考慮されます。残存しているプロパティをこの名前で非構造化 JCR ノードに追加しても、期待した効果は得られず、OSGi 登録を更新するハンドラーはこのプロパティを無視します。
ログインパスプロパティの設定はオプションで、認証が必要なツリーがデフォルトのログインページや継承されたログインページにフォールバックできない場合にのみ必要です。 詳しくは、 ログインパスの評価 下
このタイプの認証要件は、特定の実行モードと、コンテンツリポジトリにあるツリーの小さいサブセットに限定されることが想定されるため、認証要件の mixin タイプおよびログインパスプロパティの追跡すると結果は条件次第となり、サポートパスが定義された該当する設定に関連付けられます(詳しくは、後述の「設定オプション」を参照してください)。したがって、サポートパスの有効範囲内で変更があった場合にのみ、OSGi 登録の更新が実行され、それ以外の場所では、mixin タイプもログインパスプロパティも無視されます。
デフォルトの AEM セットアップでは、この設定を利用できるようにするために、mixin を author 実行モードで設定し、その設定をパブリッシュインスタンスへのレプリケーション時にのみ有効にできるようになりました。Sling での認証要件の強制方法について詳しくは、このページを参照してください。
の追加 granite:AuthenticationRequired
設定されたサポート対象パス内の mixin タイプを使用すると、応答ハンドラーの OSGi 登録が更新され、 sling.auth.requirements
プロパティ。 特定の認証要件でオプション granite:loginPath
プロパティの場合、値は Authenticator に追加で「 — 」プレフィックスと共に登録され、認証要件から除外されます。
Apache Sling 認証の要件は、ページまたはノード階層を通じて継承されると想定されます。 継承の詳細と、順序や優先順位などの認証要件の評価は実装の詳細と見なされ、この記事には記載されません。
認証時の対応リソースへのログインパスとリダイレクトの評価は、現在、Adobe Granite Login Selector Authentication Handler(com.day.cq.auth.impl.LoginSelectorHandler
)の詳細で実装されています。このハンドラーは、AEM にデフォルトで設定されている Apache Sling AuthenticationHandler です。
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
に関連付けられるグローバルなログインパス設定(デフォルトとマッピングの両方)に設定する必要があるログインパスを識別してください。新しい CUG ポリシーがリポジトリコンテンツにどのように反映されるかについては、Oak のドキュメントに記載されています。詳しくは、 このページ.
個別の認証要件の必要性は、ターゲットノードに配置された専用の mixin ノードタイプでリポジトリコンテンツに反映されます。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 (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 ポリシーを編集するには、次の手順が必要です。 変更したポリシーを書き戻し、次を使用して変更を保持する必要があります: 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 を、それらが有効かどうかに関係なく検索する。 詳しくは、 設定オプション 」セクションに入力します。
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 Authenticator に反映されます(「設定オプション」の節を参照してください)。
詳しくは、「[Mixin ノードタイプの割り当て]」(https://docs.adobe.com/docs/en/spec/jcr/2.0/10_Writing.html#10.10.3 Mixin ノードタイプの割り当て)および 「[ノードの追加とプロパティの設定]」(https://docs.adobe.com/docs/en/spec/jcr/2.0/10_Writing.html#10.4 ノードの追加とプロパティの設定)を参照してください。
認証要件を作成する手順については、以下で詳しく説明します。 この要件は、Apache Sling Authenticator に登録されている場合、 RequirementHandler
は、ターゲットノードを含むツリー用に設定されています。
Node targetNode = [...]
targetNode.addMixin("granite:AuthenticationRequired");
session.save();
ログインパスを含む認証要件を作成する手順です。 新しい認証要件と除外されるログインパスは、ターゲットノードを含むツリーに 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();
既存のログインパスを変更する手順については、以下で詳しく説明します。 変更結果は、ターゲットノードを含むツリーに 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");
}
既存のログインパスを削除する手順です。 ログインパスのエントリは、ターゲットノードを含むツリーに 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 Authenticator から登録が解除されます。
Node targetNode = [...]
targetNode.removeMixin("granite:AuthenticationRequired");
session.save();
Apache Sling Authenticator に登録されている有効なすべての認証要件を読み取る専用のパブリック API はありません。ただし、リストは、https://<serveraddress>:<serverport>/system/console/slingauth
のシステムコンソール、「認証要件の設定」セクションで公開されています。
次の画像は、デモコンテンツを含む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();
}
}
次の表に、CUG ポリシーの有効な組み合わせと、両方のモジュールが設定を通じて有効になっているAEMインスタンスでの認証要件を示します。
認証が必要 | ログインパス | 制限付き読み取りアクセス | 予想される効果 |
---|---|---|---|
はい | はい | はい | 有効な権限評価によってアクセス権が付与されている場合、ユーザーによっては CUG ポリシーのマークが付いたサブツリー以外、表示できなくなる場合があります。認証されていないユーザーは、指定のログインページにリダイレクトされます。 |
はい | いいえ | はい | 有効な権限評価によってアクセス権が付与されている場合、ユーザーによっては CUG ポリシーのマークが付いたサブツリー以外、表示できなくなる場合があります。認証されていないユーザーは、継承されたデフォルトのログインページにリダイレクトされます。 |
はい | はい | いいえ | 認証されていないユーザーは、指定のログインページにリダイレクトされます。認証要件でマークされたツリーの表示が許可されているかどうかは、そのサブツリーに含まれる個々の項目の有効な権限によって異なります。 読み取りアクセスを制限する専用の CUG が存在しない。 |
はい | いいえ | 不可 | 認証されていないユーザーは、継承されたデフォルトのログインページにリダイレクトされます。認証要件でマークされたツリーの表示が許可されるかどうかは、そのサブツリーに含まれる個々の項目の有効な権限によって異なります。 読み取りアクセスを制限する専用の CUG が存在しない。 |
いいえ | いいえ | はい | 有効な権限評価によってアクセス権が付与されている場合、認証されたユーザー、認証されていないユーザーはいずれも CUG ポリシーのマークが付いたサブツリー以外、表示できなくなる場合があります。未認証ユーザーは同じように扱われ、ログインにリダイレクトされません。 |
「ログインパス」は、認証要件に関連するオプションの属性なので、「認証要件」 = なし、「ログインパス」 = ありの組み合わせは存在しません。mixin タイプの定義を追加せずに JCR プロパティを名前で指定するだけでは、そのプロパティは有効にならず、対応するハンドラーによって無視されます。
この節では、OSGi コンポーネントと、新しい CUG 実装で導入された個々の設定オプションの概要を説明します。
古い実装と新しい実装の間の設定オプションの包括的なマッピングについては、 CUG マッピングのドキュメントも参照してください。
新しい承認関連のパーツは、 Oak CUG 認証 バンドル ( org.apache.jackrabbit.oak-authorization-cug
) です。これは、AEMのデフォルトインストールの一部です。 このバンドルは、読み取りアクセスを管理する追加の方法としてデプロイすることを目的とした、個別の認証モデルを定義します。
CUG 承認のセットアップについては、関連する Apache ドキュメントに詳しく記載されています。デフォルトでは、AEMにはすべての実行モードで CUG 認証がデプロイされています。 手順に従って、別の認証設定が必要なインストールで CUG 認証を無効にすることもできます。
また、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
認証要件を定義し、専用のログインパスを指定するために、次の 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-authorization モジュールに関連する使用可能な設定オプションが次の場所にリストされ、詳しく説明されています。詳しくは、 Apache Oak ドキュメント.
CUG 評価の個々のプリンシパルの除外は、前の実装から適用されています。 新しい CUG 認承では、CugExclude という名前の専用インターフェイスを使用してこれを説明します。Apache Jackrabbit Oak 1.4 には、固定プリンシパルのセットと個々のプリンシパル名を設定できる拡張実装を除くデフォルトの実装が付属しています。 後者は、AEMパブリッシュインスタンスで設定されます。
AEM 6.3 以降のデフォルトでは、次のプリンシパルは CUG ポリシーの影響を受けません。
詳しくは、 AEM 6.3 以降のデフォルト設定 」の節を参照してください。
除外する「管理者」グループは、システムコンソールの Apache Jackrabbit Oak CUG Exclude Listの設定セクションで変更または拡張できます。
また、特別なニーズがある場合は、CugExclude インターフェイスのカスタム実装を提供してデプロイし、除外されたプリンシパルのセットを調整することもできます。 詳しい説明と実装例については、プラグの可/不可に関するドキュメントを参照してください。
新しい認証関連の部分は、 AdobeGranite 認証ハンドラー バンドル ( 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
ラベル | - |
説明 | LoginSelectorHandler に公開される、認証要件(granite:AuthenticationRequirement Mixin タイプを通して)に影響を与えるコンテンツの変更の監視者、およびログインパスを登録する認証要件専用の OSGi サービス。 |
設定プロパティ | - |
設定ポリシー | ConfigurationPolicy.OPTIONAL |
参照 |
|
com.adobe.granite.auth.requirement.impl.DefaultRequirementHandler
ラベル | Adobe Granite 認証要件とログインパスハンドラー |
---|---|
説明 | Apache Sling 認証の要件と、関連するログインパスに対応する除外を更新するRequirementHandler 実装。 |
設定プロパティ | supportedPaths |
設定ポリシー | ConfigurationPolicy.REQUIRE |
参照 | 該当なし |
CUG 書き換えの認証関連の部分には、Granite Authentication Requirement および Login Path HandlerAdobeに関連付けられた 1 つの設定オプションのみが付属しています。
「認証要件とログインパスハンドラー」
プロパティ | タイプ | デフォルト値 | 説明 |
ラベル = サポートされているパス 名前 = 「supportedPaths」 |
Set<String> | - | このハンドラーにより認証要件が適用されるパス。granite:AuthenticationRequirement Mixin タイプをノードに適用せずに追加する場合は(例えばオーサーインスタンスで)、この設定を未設定のままにしてください。未設定にしておくと、この機能は無効になります。 |
AEMの新規インストールでは、デフォルトで、CUG 機能の認証関連部分と認証関連部分の両方に新しい実装が使用されます。 旧実装「Adobe Granite Closed User Group (CUG) Support」は廃止されており、すべての AEM インストールでデフォルトで無効になります。代わりに、新しい実装は次のように有効になります。
「Apache Jackrabbit Oak CUG 設定」 | 説明 |
---|---|
サポートされているパス /content |
CUGpolicies のアクセス制御管理が有効になっています。 |
CUG 評価が有効の FALSE | 権限の評価は無効になっています。CUG ポリシーは無効です。 |
ランキング | 200 |
次の設定がありません: Apache Jackrabbit Oak CUG 除外リスト および AdobeGranite 認証要件およびログインパスハンドラー は、デフォルトのオーサリングインスタンスに存在します。
「Apache Jackrabbit Oak CUG 設定」 | 説明 |
---|---|
サポートされているパス /content |
CUG ポリシーのアクセス制御管理は、設定されたパスの下で有効になります。 |
CUG 評価が有効の TRUE | 権限の評価は、設定されたパスの下で有効になります。CUG ポリシーは Session.save() で有効になります。 |
ランキング | 200 |
「Apache Jackrabbit Oak CUG 除外リスト」 | 説明 |
---|---|
プリンシパル名の管理者 | CUG 評価から管理者プリンシパルを除外します。 |
「Adobe Granite 認証要件とログインパスハンドラー」 | 説明 |
---|---|
サポートされているパス /content |
granite:AuthenticationRequired Mixin タイプを使用してリポジトリで定義された認証要件は、Session.save() で /content の下で有効になります。Sling Authenticator が更新されます。 サポートされているパスの外側に mixin タイプを追加することは無視されます。 |
特定のインストールで CUG が使用されない場合や、認証と承認に別の手段を使用する場合は、新しい実装を完全に無効にすることができます。
詳しくは、 CUG プラグ可能 複合承認設定から CUG 承認モデルを削除する方法の詳細に関するドキュメントです。
で指定されている認証要件のサポートを無効にするには granite.auth.authhandler
モジュールは、 AdobeGranite 認証要件およびログインパスハンドラー.
ただし、設定を削除しても、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 つ制約があります。対応する Mixin ノードタイプ rep:CugMixin,
を削除せずに、特定の CUG ポリシーを削除した場合、レプリケーション時に CUG ポリシーの削除が反映されません。これに対処するには、ポリシーの削除時に常に mixin を削除する必要があります。 ただし、mixin タイプを手動で追加すると、この制限が表示される場合があります。
バンドルに付属する認証ハンドラー Adobe Granite HTTP Header Authentication Handlercom.adobe.granite.auth.authhandler
は、同じモジュールによって定義される CugSupport
インターフェイスへの参照を保持します。これは、特定の環境内での「領域」の計算に使用され、このハンドラーによって設定される領域にフォールバックします。
これは、 CugSupport
任意の設定で非推奨の実装を再度有効にする場合に、最大限の後方互換性を確保するためのオプションです。 その実装を使用するインストールでは、CUG 実装から領域が抽出されることはありませんが、Adobe Granite HTTP Header Authentication Handler によって定義される領域が常に表示されます。
デフォルトでは、Adobe Granite HTTP Header Authentication Handler は、「Disable Login Page」(auth.http.nologin
)オプションが有効になっているパブリッシュ実行モードでのみ設定されます。
ライブコピーに関連した CUG の設定は、以下のようにノードとプロパティーを 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 コンポーネント AdobeGranite 閉じられたユーザーグループ (CUG) のサポート ( com.day.cq.auth.impl.cug.CugSupportImpl
) は、以前の CUG 機能の認証と認証に関連する部分を個別に処理できる新しいコンポーネントに置き換えられました。
以下の節では、実装とセキュリティの観点から、古い実装と新しい実装の違いを説明します。 新しい実装は同じ機能を提供することを目的としていますが、新しい CUG を使用する際に知っておくべき微妙な変更点があります。
承認の観点からの主な違いを以下にまとめます。
CUG 専用のアクセス制御コンテンツ
古い実装では、デフォルトの承認モデルを使用して、公開時にアクセス制御リストポリシーを操作し、CUG が要求する設定で既存の ACE を置き換えていました。 これは、公開時に解釈された通常の残存 JCR プロパティを書き込むことでトリガーされました。
新しい実装では、デフォルトの承認モデルのアクセス制御設定は、作成、変更、または削除された CUG の影響を受けません。 代わりに、PrincipalSetPolicy
という名前の新しいタイプのポリシーが、追加のアクセス制御コンテンツとして、ターゲットノードに適用されます。この追加ポリシーは、ターゲットノードの子として配置され、デフォルトのポリシーノードがある場合はその兄弟になります。
アクセス制御管理での CUG ポリシーの編集
この変更は、残りの JCR プロパティから専用のアクセス制御ポリシーに移行した場合、CUG 機能の承認部分を作成または変更するために必要な権限に影響を与えます。 これは、アクセス制御コンテンツの変更と見なされるので、 jcr:readAccessControl
および jcr:modifyAccessControl
リポジトリに書き込む権限。 したがって、このコンテンツを設定または変更できるのは、ページのアクセス制御コンテンツを変更する権限を持つコンテンツ作成者のみです。 これは、通常の JCR プロパティを書き込む機能で十分だった古い実装とは対照的で、結果として権限のエスカレーションがおこなわれます。
ポリシーで定義されたターゲットノード
読み取りアクセスの制限を受けるサブツリーを定義する JCR ノードで CUG ポリシーを作成します。 CUG がツリー全体に影響を与えると想定される場合、これはAEMページになる可能性が高くなります。
CUG ポリシーを指定のページの下にある jcr:content ノードにのみ適用すると、指定のページのコンテンツ s.str へのアクセスのみが制限され、兄弟ページや子ページには影響しません。これは有効な使用例である場合があり、アクセスコンテンツのきめ細かい設定を適用できるリポジトリエディターを使用して実現できます。 ただし、前の実装とは対照的に、jcr:content ノードに cq:cugEnabled プロパティを配置すると、内部的にページノードに再マッピングされます。 このマッピングは実行されなくなりました。
CUG ポリシーによる権限評価
古い CUG サポートから追加の承認モデルに移行したことで、有効な読み取り権限の評価方法が変更されています。Jackrabbit のドキュメントに記載されているように、Oak リポジトリに設定されるすべてのモデルの権限評価から読み取りアクセスが付与される場合にのみ、CUGcontent
の表示が許可された特定のプリンシパルに読み取りアクセスが付与されます。
つまり、有効な権限の評価では、CUGPolicy
とデフォルトのアクセス制御エントリの両方が考慮され、CUG コンテンツに対する読み取りアクセスは、両方のタイプのポリシーによって付与される場合にのみ付与されます。/content
ツリー全体への読み取りアクセスが全員に付与されるデフォルトの AEM パブリッシュインストールでは、CUG ポリシーの効果は、古い実装のものと同じです。
オンデマンド評価
CUG 承認モデルを使用すると、アクセス制御管理と権限評価を個別にオンにできます。
CUG ポリシーの新しいAEMのデフォルト設定評価では、「publish」実行モードでのみ有効になります。 詳細は、 AEM 6.3 以降のデフォルト設定 を参照してください。 これは、コンテンツに保存されるポリシーへの特定のパスに対する有効なポリシーを比較することで検証できます。有効なポリシーは、CUG の権限評価が有効になっている場合にのみ表示されます。
前述のように、CUG アクセス制御ポリシーは現在、コンテンツに保存されるようになりましたが、これらのポリシーの結果である有効な権限の評価は、「CUG Evaluation Enabled」が、システムコンソールの Apache Jackrabbit Oak CUG Configuration のシステムコンソールでオンになっている場合のみ適用されます。 デフォルトでは、「パブリッシュ」実行モードでのみ有効になります。
認証に関する違いを以下に示します。
前の実装では、CUG の承認と認証に関連するパーツは、単一の JCR プロパティ(cq:cugEnabled
)によって呼び出されました。認証に関する限り、これによって、Apache Sling Authenticator 実装で保存される認証要件の更新リストが得られました。新しい実装では、これと同じことが、専用の mixin タイプ(granite:AuthenticationRequired
)でターゲットノードをマークすることで達成されます。
Mixin タイプは、基本的に cq:cugLoginPage
プロパティに対応する、granite:loginPath
という名前の単一のオプションプロパティを定義します。以前の実装とは異なり、ログインパスプロパティは、宣言するノードタイプが前述の mixin の場合にのみ考慮されます。 mixin タイプを設定せずにその名前のプロパティを追加しても、効果がなく、新しい要件もログインパスの除外もオーセンティケーターに報告されません。
mixin タイプを追加または削除するには、jcr:nodeTypeManagement
権限が付与されている必要があります。前の実装では、残余プロパティの編集には jcr:modifyProperties
権限が使用されました。
に関しては granite:loginPath
は、プロパティの追加、変更、削除に同じ権限が必要です。
JCR ノードで認証要件を作成し、強制的なログインの対象となるサブツリーを定義します。 CUG がツリー全体に影響を与え、新しい実装の UI が結果としてページノードに auth-requirement mixin タイプを追加する場合、これはAEMページの可能性が高くなります。
CUG ポリシーを特定のページの下にある jcr:content ノードにのみ配置すると、コンテンツへのアクセスは制限されますが、ページノード自体や子ページには影響しません。
場合によってはこうしたケースも有効で、任意のノードに mixin を配置できるリポジトリエディターによって達成できます。ただし、この動作は、cq:cugEnabled プロパティや cq:cugLoginPage プロパティを jcr:content ノードに配置することが、内部でページノードに再マッピングされた前の実装とは対照的です。このマッピングは実行されなくなりました。
granite:AuthenticationRequired
mixin タイプと granite:loginPath プロパティは、Adobe Granite Authentication Requirement and Login Path Handler で提供される「サポートされているパス」設定オプションによって定義される適用範囲内でのみ考慮されます。パスが指定されていない場合、認証要件機能は完全に無効になります。 その場合、Mixin タイプやプロパティを追加しても、特定の 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
にある特定のロガーをデバッグレベルに設定することが可能です。詳細については、ロギングを参照してください。