AEM中的封閉使用者群組 closed-user-groups-in-aem

簡介 introduction

自AEM 6.3起，推出新的封閉使用者群組實作，旨在解決現有實作中存在的效能、延展性和安全性問題。

新實作的目標是視需要涵蓋現有功能，同時解決舊版的問題和設計限制。 結果為新的CUG設計，具有以下特點：

新的自訂使用者群組實作 the-new-custom-user-group-implementation

AEM內容中稱為CUG的步驟如下：

新的實施旨在在驗證和授權元素之間划出一條線。 自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策略始終被識別並視為訪問控制內容。 這表示使用JCR存取控制管理API來建立和編輯這些API。 如需詳細資訊，請參閱 管理CUG策略 區段。

CUG策略的權限評估 permission-evaluation-of-cug-policies

除了CUG專用的訪問控制管理之外，新授權模型允許有條件地啟用對其策略的權限評估。 這可讓您在預備環境中設定CUG原則，並且只有在將有效權限複製到生產環境後，才能啟用評估。

CUG政策的權限評估以及與預設或任何其他授權模型的互動，會遵循Apache Jackrabbit Oak中為多個授權機制所設計的模式：只有在所有模型都授予存取權時，才會授予指定的一組權限。 請參閱 本頁 以取得更多詳細資訊。

下列特性適用於與用於處理和評估CUG策略的授權模型相關的權限評估：

單個CUG策略對權限評估的影響可概括如下：

最佳做法 best-practices

在定義通過CUG的受限讀取權限時，應考慮以下最佳做法：

驗證：定義驗證需求 authentication-defining-the-auth-requirement

CUG功能的認證相關部分允許標籤需要認證的樹並可選地指定專用的登錄頁。 根據前一版本，新實施允許標籤需要在內容儲存庫中進行身份驗證的樹，並有條件地啟用與 Sling org.apache.sling.api.auth.Authenticator負責最終強制執行要求並將重新導向至登入資源。

這些要求會透過提供以下功能的OSGi服務向驗證者註冊 sling.auth.requirements 註冊屬性。 然後，這些屬性將用於動態擴展驗證需求。 如需詳細資訊，請參閱 Sling檔案.

使用專用混頻類型定義驗證需求 defining-the-authentication-requirement-with-a-dedicated-mixin-type

基於安全理由，新實作會以稱為的專用混合類型取代剩餘JCR屬性的使用 granite:AuthenticationRequired，定義登入路徑的單一選用屬性類型STRING granite:loginPath. 只有與此混合類型相關的內容變更才會更新Apache Sling Authenticator註冊的需求。 持續保留任何暫時性修改時就會追蹤修改，因此需要 javax.jcr.Session.save() 呼籲生效。

同樣適用於 granite:loginPath 屬性。 只有由驗證要求相關的混合類型定義時，才會接受。 在非結構化JCR節點上添加具有此名稱的剩餘屬性將不會顯示所需的效果，而負責更新OSGi註冊的處理程式將忽略該屬性。

向Sling Authenticator註冊驗證要求和登錄路徑 registering-the-authentication-requirement-and-login-path-with-the-sling-authenticator

由於此類型的身份驗證需求預計將限於某些運行模式以及內容儲存庫內的一小部分樹，因此，對需求混合類型和登錄路徑屬性的跟蹤是有條件的，並綁定到定義受支援路徑的相應配置（請參閱下面的配置選項）。 因此，只有這些受支援路徑範圍內的更改才會觸發OSGi註冊的更新，在其他地方，mixin類型和屬性都將被忽略。

預設AEM設定現在可允許在製作執行模式中設定mixin，但只讓mixin在復寫至發佈執行個體時生效，以利用此設定。 請參閱 本頁 如需詳細資訊，請參閱Sling如何執行驗證要求。

新增 granite:AuthenticationRequired 配置的支援路徑中的mixin類型將導致負責處理程式的OSGi註冊更新，該處理程式包含新的附加條目，該條目包含 sling.auth.requirements 屬性。 如果指定的身份驗證要求指定了可選 granite:loginPath 屬性，則值會以「 — 」首碼額外註冊給驗證器，以便從驗證需求中排除。

認證需求的評價與繼承 evaluation-and-inheritance-of-the-authentication-requirement

Apache Sling驗證需求應透過頁面或節點階層繼承。 繼承和驗證要求評估的詳細資訊（如順序和優先順序）被視為實施詳細資訊，本文不予記錄。

登錄路徑評估 evaluation-of-login-path

評估登入路徑並在驗證時重新導向至對應資源，目前是AdobeGranite登入選取器驗證處理常式( com.day.cq.auth.impl.LoginSelectorHandler)，此元件為Apache Sling AuthenticationHandler，預設會以AEM設定。

呼叫時 AuthenticationHandler.requestCredentials 此處理常式會嘗試判斷要將使用者重新導向的對應登入頁面。 這包括下列步驟：

本檔案的目標是評估內部公開的登入路徑 LoginPathProvider 介面。 自AEM 6.3起提供的實作如下：

此 LoginPathProvider 如Granite中新的驗證需求支援所實作，會公開由 granite:loginPath 屬性，而屬性又由如上所述的mixin類型定義。 保存登錄路徑的資源路徑和屬性值本身的映射被保存在記憶體中，並將被評估以為層次中的其他節點尋找合適的登錄路徑。

最佳做法 best-practices-1

定義驗證需求時，應考量下列最佳實務：

在儲存庫中的表示 representation-in-the-repository

CUG在儲存庫中的策略表示 cug-policy-representation-in-the-repository

Oak檔案涵蓋新CUG原則在存放庫內容中的反映方式。 如需詳細資訊，請參閱 本頁.

儲存庫中的驗證需求 authentication-requirement-in-the-repository

在存放庫內容中反映了對單獨驗證需求的需求，其中目標節點處放置了專用的混合節點類型。 mixin類型定義了可選屬性，用於為目標節點定義的樹指定專用的登錄頁。

與登錄路徑相關聯的頁面可以位於該樹內或外部。 它將從驗證需求中排除。

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

管理CUG策略和身份驗證要求 managing-cug-policies-and-authentication-requirement

管理CUG策略 managing-cug-policies

使用JCR訪問控制管理API來管理用於限制CUG讀訪問的新類型的訪問控制策略，並遵循以下機制描述 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策略的評估是有條件的，並且取決於要啟用的相應配置，請調用 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策略 retrieve-inherited-cug-policies

無論CUG是否生效，都會在指定路徑上找到已定義的所有巢狀CUG。 如需詳細資訊，請參閱 配置選項 區段。

String path = [...]

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

按主管管理CUG策略 managing-cug-policies-by-pincipal

由定義的擴充功能 JackrabbitAccessControlManager 允許按主體編輯訪問控制策略的策略沒有通過CUG訪問控制管理實現，因為根據定義，CUG策略始終影響所有主體：那些跟 PrincipalSetPolicy 將被授予讀取訪問權限，而所有其他主體將被阻止讀取目標節點定義的樹中的內容。

相應的方法始終返回空策略陣列，但不會引發異常。

管理驗證需求 managing-the-authentication-requirement

通過改變目標節點的有效節點類型來實現新認證需求的建立、修改或移除。 然後，可使用一般JCR API寫入選用的登入路徑屬性。

新增驗證需求 adding-a-new-auth-requirement

建立新驗證需求的步驟如下所述。 請注意，若符合以下條件，則需向Apache Sling Authenticator註冊 RequirementHandler 已為包含目標節點的樹配置。

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 已為包含目標節點的樹配置。 先前的登錄路徑值將從註冊中刪除。 與目標節點相關聯的驗證要求不會受此修改影響。

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 已為包含目標節點的樹配置。 與目標節點相關聯的驗證需求不受影響。

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 已針對包含目標節點的樹進行配置。

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

session.save();

檢索有效驗證要求 retrieve-effective-auth-requirements

沒有專用的公用API可讀取向Apache Sling Authenticator註冊的所有有效驗證需求。 不過，此清單會公開於 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

本節概述OSGi元件，以及新CUG實作引入的個別設定選項。

另請參閱CUG對應檔案，以取得舊實作與新實作之間組態選項的完整對應。

授權：設定與設定 authorization-setup-and-configuration

新的授權相關部分包含在 Oak CUG授權 捆綁( org.apache.jackrabbit.oak-authorization-cug)，此為AEM預設安裝的一部分。 該捆綁定義了一個分離的授權模型，該授權模型旨在作為管理讀取訪問的一種附加方法進行部署。

設定CUG授權 setting-up-cug-authorization

如需設定CUG授權的詳細說明，請參閱 相關Apache檔案. 依預設，AEM在所有執行模式中都部署了CUG授權。 該逐步指令還可用於在那些需要不同授權設定的安裝中禁用CUG授權。

設定反向連結篩選 configuring-the-referrer-filter

您也需要設定 Sling反向連結篩選器 包含所有可用來存取AEM的主機名稱；例如，透過CDN、負載平衡器等。

如果未設定反向連結篩選器，則當使用者嘗試登入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

引入下列兩個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排除清單.

或者，您也可以提供並部署CugExclude介面的自訂實作，以因應特殊需求調整排除的主體集合。 請參閱 CUG可插拔性 以取得詳細資訊和範例實作。

驗證：設定與設定 authentication-setup-and-configuration

新的驗證相關部分包含在 AdobeGranite驗證處理常式 捆綁( 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重寫的身份驗證相關部分僅附帶與AdobeGranite身份驗證要求和登錄路徑處理程式關聯的單個配置選項：

"驗證要求和登錄路徑處理程式"

自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 模組，足以移除與 AdobeGranite驗證需求和登入路徑處理常式.

與其他模組的互動 interaction-with-other-modules

Apache Jackrabbit API apache-jackrabbit-api

為了反映CUG授權模型所使用的新類型存取控制政策，已擴充Apache Jackrabbit所定義的API。 自2.11.0版 jackrabbit-api 模組定義新介面，稱為 org.apache.jackrabbit.api.security.authorization.PrincipalSetPolicy，從 javax.jcr.security.AccessControlPolicy.

Apache Jackrabbit FileVault apache-jackrabbit-filevault

Apache Jackrabbit FileVault的匯入機制已調整，以處理類型的存取控制政策 PrincipalSetPolicy.

Apache Sling Content Distribution apache-sling-content-distribution

請參閱上述 Apache Jackrabbit FileVault 區段。

AdobeGranite復寫 adobe-granite-replication

復寫模組已稍作調整，以便能夠在不同AEM執行個體之間複製CUG原則：

複製CUG策略有一個限制。 如果刪除給定的CUG策略，而不刪除相應的混合節點類型 rep:CugMixin, 復寫時不會反映移除。 此問題已通過始終在刪除策略時刪除mixin來解決。 不過，如果手動新增混合類型，則可能會顯示限制。

AdobeGranite驗證處理常式 adobe-granite-authentication-handler

驗證處理常式 AdobeGranite HTTP標題驗證處理常式 隨 com.adobe.granite.auth.authhandler 捆綁包含對的引用 CugSupport 由相同模組定義的介面。 它用於在某些情況下計算「領域」，並回退到配置有處理程式的領域。

此項已調整，以參考 CugSupport 若指定的設定決定重新啟用已棄用的實施，則可選，以確保最大的回溯相容性。 使用實作的安裝將不再從CUG實作中擷取領域，但一律會依照定義顯示領域 AdobeGranite HTTP標題驗證處理常式.

AEM LiveCopy aem-livecopy

配置CUG與LiveCopy結合時，會添加一個額外節點和一個額外屬性，如下所示：

這兩個元素都會在 cq:Page. 透過目前的設計，MSM只會處理位於 cq:PageContent (jcr:content)節點。

因此，CUG組無法從Blueprint轉出到Live Copy。 設定Live Copy時，請針對此進行規劃。

新CUG實作的變更 changes-with-the-new-cug-implementation

本節旨在概述對CUG功能所做的變更，並比較舊實作和新實作。 它列出了影響CUG支援配置方式的更改，並描述了在儲存庫內容中管理CUG的方式和方式。

CUG設定和配置中的差異 diferences-in-cug-setup-and-configuration

已棄用的OSGi元件 AdobeGranite封閉使用者群組(CUG)支援 ( 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節點建立，該節點定義要受限制讀取訪問限制的子樹。 這可能是AEM頁面，以防CUG影響整個樹。

請注意，將CUG原則僅放在指定頁面下方的jcr:content節點，只會限制對指定頁面內容的存取，但不會對任何同層頁面或子頁面生效。 這可能是有效的使用案例，而且可以使用允許套用微調存取內容內容的存放庫編輯器來達成。 不過，它會與前一個實施作比較，前者將cq:cugEnabled屬性放置在jcr:content節點上，會在內部重新對應至頁面節點。 不再執行此對應。

使用CUG策略進行權限評估

從舊的CUG支援移至其他授權模型，會變更評估有效讀取權限的方式。 如 Jackrabbit檔案，指定的主體可檢視 CUGcontent 只有在Oak存放庫中所設定模型的權限評估已授予讀取存取權時，才會授予讀取存取權。

換言之，為評估有效權限， CUGPolicy 並且，將考慮預設訪問控制項條目，並且只有在CUG內容被兩種策略授予時，才授予該內容的讀訪問權。 在預設的AEM發佈安裝中，讀取完成的存取權 /content 樹授予每個人，CUG政策的效果將與舊實施相同。

按需評估

CUG授權模型允許單獨開啟訪問控制管理和權限評估：

在新的AEM預設CUG策略設定評估中，它只會以「發佈」執行模式啟用。 請參閱 自AEM 6.3起的預設設定 以取得更多詳細資訊。 這可以通過將給定路徑的有效策略與儲存在內容中的策略進行比較來驗證。 只有在啟用CUG的權限評估時，才會顯示有效策略。

如上所述，CUG訪問控制策略現在始終儲存在內容中，但只有在 啟用CUG評估 在Apache Jackrabbit Oak的系統主控台中開啟 CUG配置。 依預設，僅以「發佈」執行模式啟用。

與驗證的差異 differences-with-regards-to-authentication

與驗證有關的差異如下。

用於認證需求的專用混合類型 dedicated-mixin-type-for-authentication-requirement

在前一實施中，CUG的授權和驗證方面都是由單一JCR屬性( cq:cugEnabled)。 就驗證而言，這會導致更新Apache Sling Authenticator實作所儲存的驗證需求清單。 通過使用專用混合類型標籤目標節點( granite:AuthenticationRequired)。

用於排除登錄路徑的屬性 property-for-excluding-login-path

mixin類型定義了名為的單一選用屬性 granite:loginPath，這與 cq:cugLoginPage 屬性。 與先前的實施相反，只有在其聲明節點類型為上述mixin時，登入路徑屬性才會受到尊重。 在未設定mixin類型的情況下添加具有該名稱的屬性將無效，並且不會向驗證器報告登錄路徑的新要求或排除。

身份驗證要求的權限 privilege-for-authentication-requirement

添加或刪除混合類型需要 jcr:nodeTypeManagement 被授予權限。 在先前的實作中， jcr:modifyProperties 權限用於編輯剩餘屬性。

至 granite:loginPath 關注在添加、修改或刪除屬性時需要相同的權限。

由Mixin類型定義的目標節點 target-node-defined-by-mixin-type

驗證需求應建立在JCR節點，定義要受強制登入約束的子樹。 如果CUG預計會影響整個樹狀結構，則這可能是AEM頁面，而新實作的UI隨後會在頁面節點上新增驗證需求mixin類型。

將CUG原則僅放在指定頁面下方的jcr:content節點，只會限制對內容的存取，但不會影響頁面節點本身或任何子頁面。

這可能是有效的案例，而且使用允許將mixin放置在任何節點的儲存庫編輯器是可能的。 不過，此行為與前一個實作有所差異，即將cq:cugEnabled或cq:cugLoginPage屬性放置於jcr:content節點上，最終會在內部重新對應至頁面節點。 不再執行此對應。

配置的支援路徑 configured-supported-paths

兩者 granite:AuthenticationRequired mixin類型和granite:loginPath屬性只會在由 支援的路徑 設定選項與 AdobeGranite驗證需求和登入路徑處理常式. 如果未指定路徑，則完全禁用身份驗證要求功能。 在此情況下，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安裝，請務必確保僅啟用一個CUG實作。 新的和舊的、過時的CUG支援的組合不會經過測試，並且可能會導致不適當的行為：

移轉現有CUG內容 migrating-existing-cug-content

Adobe提供移轉至新CUG實作的工具。 若要使用，請執行下列步驟：