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建立和編輯的。 如需詳細資訊，請參閱管理CUG原則區段。

CUG原則的許可權評估 permission-evaluation-of-cug-policies

除了CUG的專用存取控制管理外，新的授權模型可讓您有條件地啟用其原則的許可權評估。 這可讓您在中繼環境中設定CUG原則，並且只允許在複製到生產環境後評估有效許可權。

CUG原則的許可權評估以及與預設或任何其他授權模型的互動，遵循為Apache Jackrabbit Oak中的多個授權機制設計的模式。 也就是說，若且唯若所有模型都授予存取權時，才授予一組特定許可權。 如需詳細資訊，請參閱Jackrabbit Oak檔案。

下列特性適用於與授權模型相關的許可權評估，這些授權模型設計用來處理和評估CUG原則：

單一CUG原則對許可權評估的影響可概括如下：

最佳做法 best-practices

下列最佳實務應說明如何定義透過CUG的限制讀取存取權：

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

CUG功能的認證相關部分可讓您標籤需要認證的樹狀結構，並選擇性地指定專用登入頁面。 根據舊版，新的實作可讓您在內容存放庫中標籤需要驗證的樹狀結構。 它也會有條件地啟用與Sling org.apache.sling.api.auth.Authenticator的同步處理，負責最終強制要求並重新導向至登入資源。

這些需求是由提供sling.auth.requirements註冊屬性的OSGi服務向驗證者註冊。 這些屬性接著可用來動態擴充驗證需求。 如需詳細資訊，請參閱Sling檔案。

使用專用的Mixin型別定義驗證需求 defining-the-authentication-requirement-with-a-dedicated-mixin-type

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

同樣適用於granite:loginPath屬性。 只有當它是由驗證需求相關的mixin型別定義時，才會被遵守。 在非結構化JCR節點中新增具有此名稱的剩餘屬性不會顯示所需的效果，並且負責更新OSGi註冊的處理常式會忽略該屬性。

向Sling驗證者註冊驗證需求和登入路徑 registering-the-authentication-requirement-and-login-path-with-the-sling-authenticator

由於此型別的驗證需求應限製為某些執行模式，以及內容存放庫中的一小部分樹狀結構，因此追蹤需求mixin型別和登入路徑屬性是有條件的。 而且，它繫結到定義受支援路徑的對應配置（請參閱下面的配置選項）。 因此，只有這些支援路徑範圍內的變更才會觸發OSGi註冊的更新，其他地方mixin型別和屬性都會被忽略。

預設AEM設定現在會使用此設定，允許以製作執行模式設定mixin，但只有在複製到發佈執行個體時才會生效。 請參閱Sling驗證 — 架構檔案，以瞭解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)的實作詳細資料，這是預設以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

Oak檔案說明新的CUG政策在存放庫內容中的反映方式。 如需詳細資訊，請參閱有關使用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

使用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 (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原則是有條件的，而且取決於要啟用的對應組態，所以呼叫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，無論其是否生效。 如需詳細資訊，請參閱組態選項區段。

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驗證器登入需求。

Node targetNode = [...]

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

使用登入路徑新增驗證需求 add-a-new-auth-requirement-with-login-path

建立包含登入路徑的驗證要求的步驟。 登入路徑的需要和排除只有在包含目標節點的樹狀結構已設定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();

修改現有登入路徑 modify-an-existing-login-path

變更現有登入路徑的步驟詳述如下。 只有為包含目標節點的樹狀結構設定了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");
}

移除現有的登入路徑 remove-an-existing-login-path

移除現有登入路徑的步驟。 只有在已針對包含目標節點的樹狀結構設定RequirementHandler時，登入路徑專案才會從Apache Sling驗證程式取消註冊。 與目標節點相關聯的驗證需求不受影響。

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驗證程式取消登入要求。

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驗證器中。

擷取有效登入路徑 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 Authorization ​套件( org.apache.jackrabbit.oak-authorization-cug)中，這是AEM預設安裝的一部分。 該套件定義了一個獨立的授權模型，旨在部署為管理讀取存取權的額外方法。

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

在相關Apache檔案中詳細說明設定CUG授權。 依預設，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-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排除清單 ​之設定區段中的系統主控台中，變更或擴充「管理員」群組的排除。

或者，可以提供並部署CugExclude介面的自訂實作，以在有特殊需求時調整排除的主體集。 如需詳細資訊和實作範例，請參閱CUG可插拔性的相關檔案。

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

新的驗證相關部分包含在​ AdobeGranite驗證處理常式 ​套件（ com.adobe.granite.auth.authhandler版本5.6.48）中。 此套件組合是AEM預設安裝的一部分。

若要設定取代已棄用CUG支援的驗證需求，在指定的AEM安裝中，必須存在且作用中的部分OSGi元件。 如需詳細資訊，請參閱下方的​ OSGi元件的特性。

OSGi元件的特性

下列兩個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功能的授權和驗證相關部分。 舊版實作「AdobeGranite封閉使用者群組(CUG)支援」已過時，並預設會在所有AEM安裝中停用。 新的實作將改為啟用，如下所示：

作者執行個體 author-instances

Publish例項 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已擴充。 因為jackrabbit-api模組的2.11.0版定義了一個名為org.apache.jackrabbit.api.security.authorization.PrincipalSetPolicy的新介面，從javax.jcr.security.AccessControlPolicy延伸。

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政策有一個限制。 如果未移除對應的mixin節點型別rep:CugMixin,就移除指定的CUG原則，則復寫時將不會反映移除。 原則移除後，一律移除mixin即可解決此問題。 不過，如果手動新增mixin型別，則可能會顯示此限制。

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

與com.adobe.granite.auth.authhandler組合隨附的驗證處理常式​ AdobeGranite HTTP標頭驗證處理常式 ​儲存相同模組所定義的CugSupport介面的參考。 在特定情況下，它可用來計算「範圍」，並歸入使用處理常式設定的範圍。

此設定已經過調整，以使CugSupport的參考成為選用，以便在指定設定決定重新啟用已棄用的實作時，確保最大的回溯相容性。 使用實作的安裝將不會再取得從CUG實作擷取的領域，但將一律顯示使用​ AdobeGranite HTTP標頭驗證處理常式 ​定義的領域。

AEM LiveCopy aem-livecopy

使用LiveCopy設定CUG時，在存放庫中會以新增一個額外節點和一個額外屬性的方式表示，如下所示：

這兩個元素都是在cq:Page下建立。 使用目前的設計，MSM只會處理cq:PageContent (jcr:content)節點下的節點和屬性。

因此，CUG群組無法從Blueprint轉出至即時副本。 設定即時副本時，請對此進行規劃。

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

本節旨在提供對CUG功能所做變更的概述，以及舊實作與新實作的比較。 其中列出影響CUG支援設定方式的變更，並說明CUG在存放庫內容中的管理方式及管理者。

CUG設定和設定的差異 differences-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時需瞭解一些重要的細微變更。

與授權相關的差異 differences-with-regards-to-authorization

授權視角的主要差異概述於以下清單：

CUG的​ 專用存取控制內容

在舊版實作中，預設授權模型用於操控發佈上的存取控制清單原則，以CUG強制執行的設定取代任何現有的ACE。 觸發此問題的原因是寫入了在發佈時解譯的規則剩餘JCR屬性。

在新實作中，預設授權模型的存取控制設定不受任何建立、修改或移除的CUG影響。 而是將名為PrincipalSetPolicy的新原則型別套用為目標節點的額外存取控制內容。 此額外原則位於目標節點的子節點中，如果存在，則為預設原則節點的同層級。

在存取控制管理中編輯CUG原則

這種從剩餘JCR屬性到專用存取控制政策的移動會影響建立或修改CUG功能的授權部分所需的許可權。 由於這被視為存取控制內容的修改，因此需要將jcr:readAccessControl和jcr:modifyAccessControl許可權寫入存放庫。 因此，只有有權修改頁面存取控制內容的內容作者才能設定或修改此內容。 這與舊版實作形成對比，舊版實作中寫入一般JCR屬性的能力已足夠，導致許可權提升。

由原則 ​定義的目標節點

在JCR節點建立CUG原則，定義要接受受限讀取存取的子樹狀結構。 這可能是個AEM頁面，以防CUG可能影響整個樹狀結構。

將CUG原則僅置於指定頁面下方的jcr：content節點會限制對指定頁面內容s.str的存取，但不會影響任何同級頁面或子頁面。 這可能是有效的使用案例，並且可以使用存放庫編輯器來完成，該編輯器可讓您套用精細存取內容。 然而，它與以前的實作不同，在以前的實作中，在jcr：content節點上放置cq：cugEnabled屬性會在內部重新對應至頁面節點。 不再執行此對應。

使用CUG原則進行​ 許可權評估

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

換句話說，為了評估有效許可權，CUGPolicy和預設存取控制專案都會被考慮，而且只有在這兩種原則都授與的情況下，才會授與CUG內容的讀取存取權。 在預設AEM發佈安裝中，其中向所有人授予完整/content樹狀結構的讀取存取權，CUG政策的效果與舊實作相同。

隨選評估

CUG授權模型可讓您個別開啟存取控制管理和許可權評估：

在CUG原則的新AEM預設設定評估中，它僅在「發佈」執行模式中啟用。 如需詳細資訊，請參閱AEM 6.3🔗之後的預設設定詳細資料。 這可透過比較給定路徑的有效原則與內容中儲存的原則來驗證。 只有啟用CUG的許可權評估時，才會顯示有效原則。

如上所述，CUG存取控制原則現在一律會儲存在內容中，但是只有在Apache Jackrabbit Oak CUG組態的系統主控台中開啟 ​啟用CUG評估​ 時，才會強制執行這些原則所產生的有效許可權評估。 ​依預設，它僅以'publish'執行模式啟用。

與驗證相關的差異 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型別定義了一個稱為granite:loginPath的選擇性屬性，基本上與cq:cugLoginPage屬性對應。 相較於先前的實作，只有當其宣告節點型別是上述的mixin時，才會考量登入路徑屬性。 在不設定mixin型別的情況下新增具有該名稱的屬性不會產生任何效果，並且不會向驗證者報告針對登入路徑的新要求或排除。

驗證要求的許可權 privilege-for-authentication-requirement

新增或移除mixin型別需要授予jcr:nodeTypeManagement許可權。 在上一個實作中，jcr:modifyProperties許可權是用來編輯剩餘屬性。

就granite:loginPath而言，新增、修改或移除屬性需要相同的許可權。

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

在JCR節點建立驗證需求，定義要強制登入的子樹狀結構。 這可能是個AEM頁面，以防CUG預期會影響整個樹狀結構，以及新實作的UI，因此會在頁面節點上新增驗證需求mixin型別。

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

這可能是有效的案例，並且可在存放庫編輯器中讓您將mixin放置在任何節點上。 不過，此行為與之前的實施相反，也就是在jcr：content節點上放置cq：cugEnabled或cq：cugLoginPage屬性最終會在內部重新對應至頁面節點。 不再執行此對應。

已設定的支援路徑 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實作的工具。 若要使用，請執行下列步驟：