中的AEM已關閉用戶組

簡介

自AEM6.3以來，已關閉的使用者群組實作旨在解決現有實作的效能、延展性與安全性問題。

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

• 可單獨使用或組合使用的驗證和授權要素明確分開；
• 專用授權模型，在配置的CUG樹上反映受限讀取訪問，而不干擾其他訪問控制設定和權限要求；
• 在編寫實例時通常需要的受限讀訪問權限控制設定和發佈時通常需要的權限評估之間分離；
• 編輯受限讀取存取權，而無權限竊取；
• 專用節點類型擴展來標籤認證要求；
• 與驗證要求相關聯的可選登錄路徑。

新的自訂使用者群組實作

CUG（在上下文中稱為CUG）AEM包含以下步驟：

• 限制對需要保護的樹狀結構的讀訪問權限，並僅允許讀取帶有給定CUG實例或完全排除在CUG評估之外的承擔者。 這稱為​authorization​元素。
• 在指定樹上強制驗證，並可選擇指定該樹的專用登錄頁，該登錄頁隨後被排除。 這稱為​authentication​元素。

新的實施旨在在驗證和授權元素之間划出一條線。 從AEM6.3開始，可以在不明確添加驗證要求的情況下限制讀訪問。 例如，如果給定實例完全需要驗證，或者給定樹已駐留在需要驗證的子樹中。

同樣地，給定的樹可以用驗證要求標籤，而無需更改有效的權限設定。 組合和結果列在Combining CUG Policys and the Authentication Requirement一節中。

概覽

授權：限制讀訪問

CUG的主要功能是限制內容儲存庫中指定樹上除選定承擔者之外的所有人的讀取訪問。 新實施不會即時控制預設存取控制內容，而是採用不同的方法，定義代表CUG的專用存取控制策略類型。

CUG的訪問控制策略

這種新型策略具有以下特點：

• org.apache.jackrabbit.api.security.authorization.PrincipalSetPolicy（由Apache Jackrabbit API定義）類型的存取控制政策；
• PrincipalSetPolicy授予可修改的承擔者集的權限；
• 授予的權限和策略的範圍是實施詳細資訊。

用於表示CUG的PrincipalSetPolicy的實施還定義了：

• CUG策略僅授予對常規JCR項的讀訪問權限（例如，排除訪問控制內容）;
• 範圍由CUG策略的接入控制節點定義；
• CUG策略可以嵌套，嵌套CUG啟動新CUG而不繼承「父」CUG的主集；
• 如果啟用了評估，則策略的效果將繼承到整個子樹，並下移到下一個嵌套的CUG。

這些CUG策略通過名為oak-authorization-cugAEM的單獨授權模組部署到實例。 本模組具有自己的訪問控制管理和權限評估功能。 換言之，預設設定會AEM提供結合多種授權機制的Oak內容存放庫設定。 如需詳細資訊，請參閱Apache Oak Documentation🔗上的本頁。

在此組合設定中，新的CUG不會替換附加到目標節點的現有訪問控制內容，而是設計為補充，它也可以在以後刪除而不影響原始訪問控制，預設情況下AEM是訪問控制清單。

與以前的實施相比，新的CUG策略始終被識別和視為訪問控制內容。 這表示它們是使用JCR存取控制管理API來建立和編輯的。 有關詳細資訊，請參閱管理CUG策略一節。

CUG策略的權限評估

除了CUG的專用訪問控制管理外，新授權模型允許有條件地啟用其策略的權限評估。 這允許在測試環境中設定CUG策略，並且僅允許在複製到生產環境後評估有效權限。

CUG原則的權限評估以及與預設或任何額外授權模型的互動遵循Apache Jackrabbit Oak中針對多種授權機制所設計的模式：只有在所有模型都授與存取權時，才會授與特定的權限集。 如需詳細資訊，請參閱本頁。

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

• 它僅處理常規節點和屬性的讀取權限，但不處理讀取訪問控制內容
• 它不處理修改受保護JCR內容（訪問控制、節點類型資訊、版本修訂、鎖定或用戶管理等）所需的寫權限或任何類型的權限；這些權限不受CUG原則影響，且不會由相關的授權模型評估。 是否授予這些權限取決於安全設定中配置的其他模型。

單一CUG策略對權限評估的影響可總結如下：

• 除了包含策略中列出的已排除承擔者或承擔者的主體外，所有人都拒絕讀取權限；
• 策略對包含策略及其屬性的訪問控制節點生效；
• 這種效果還會沿著層次結構繼承，即由訪問控制節點定義的項目樹；
• 但是，它不影響接入控制節點的兄弟和祖先；
• 給定CUG的繼承將停止在嵌套CUG處。

最佳作法

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

• 有意識地決定您對CUG的需求是限制讀取存取還是驗證要求。 如果是後者，或如果需要兩者，請參閱最佳實務一節，以取得有關驗證要求的詳細資訊

• 為需要保護的資料或內容建立威脅模型，以識別威脅界限並清楚瞭解資料的敏感性以及與授權存取相關的角色

• 為儲存庫內容和CUG建模，同時牢記與授權相關的一般方面和最佳做法：

  • 請記住，只有在給定的CUG和設定授權中部署的其他模組評估允許給定主體讀取給定儲存庫項目時，才授予讀取權限
  • 避免建立冗餘CUG，其中讀取訪問已受到其他授權模組的限制
  • 過度需要巢狀CUG可能會反白顯示內容設計中的問題
  • 對CUG的過度需求（例如，在每個頁面上）可能表示需要自訂授權模型，這可能更符合應用程式和手邊內容的特定安全性需求。

• 將CUG策略支援的路徑限制在儲存庫中的幾個樹中，以便獲得最佳效能。 例如，僅允許在/content節點下方的CUG作為自6.3以來的預設值AEM發運。

• CUG策略的設計目的是授予對一小組承擔者的讀取訪問權限。 大量原則的需要可能會突出內容或應用程式設計中的問題，應該重新考慮。

驗證：定義驗證要求

CUG功能的驗證相關部分允許標籤需要驗證的樹並可選地指定專用登錄頁。 根據先前版本，新實現允許在內容儲存庫中標籤需要驗證的樹，並有條件地允許與負責最終實施要求並重定向到登錄資源的Sling org.apache.sling.api.auth.Authenticator同步。

這些要求是透過提供sling.auth.requirements註冊屬性的OSGi服務向驗證者註冊的。 然後，這些屬性會用來動態擴充驗證需求。 如需詳細資訊，請參閱Sling documentation。

使用專用混音類型定義驗證要求

出於安全原因，新實作會以名為granite:AuthenticationRequired的專用混音類型取代剩餘JCR屬性的使用，該類型為登入路徑granite:loginPath定義單一可選屬性類型STRING。 只有與此混音類型相關的內容變更，才能更新Apache Sling Authenticator註冊的需求。 在持續進行任何暫時性修改時會追蹤修改，因此需要javax.jcr.Session.save()呼叫才能生效。

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

使用Sling Authenticator註冊驗證要求和登入路徑

由於此類型的驗證需求預計會限制在某些執行模式和內容儲存庫中的樹的一小部分，因此追蹤需求混合類型和登入路徑屬性是有條件的，並且會系結至定義支援路徑的對應設定（請參閱下方的設定選項）。 因此，只有這些受支援路徑範圍內的變更才會觸發OSGi註冊的更新，而其他地方的mixin類型和屬性都將被忽略。

現在，AEM預設設定允許在作者運行模式中設定mixin，但僅在複製到發佈實例時使用此配置。 請參閱本頁以取得Sling如何強制執行驗證要求的詳細資訊。

將granite:AuthenticationRequired mixin類型添加到配置的受支援路徑中，將導致更新負責的處理程式的OSGi註冊，該註冊包含具有sling.auth.requirements屬性的新的附加條目。 如果給定的驗證要求指定了可選的granite:loginPath屬性，則該值會附加地向驗證器註冊一個「-」前置詞，以便排除在驗證要求之外。

認證要求的評估與繼承

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

登錄路徑評估

驗證時登入路徑的評估並重新導向至對應資源，目前是AdobeGranite登入選擇器驗證處理常式(com.day.cq.auth.impl.LoginSelectorHandler)的實作詳細資訊，此處是依預設設定的Apache Sling AuthenticationHandlerAEM。

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

• 區分過期密碼和需要定期登入以做為重新導向的原因；

• 若是定期登入，測試是否可依下列順序取得登入路徑：

  • 從由新com.adobe.granite.auth.requirement.impl.RequirementService實施的LoginPathProvider,
  • 從舊有、已過時的CUG實作，
  • 從「登入頁面對應」，如LoginSelectorHandler所定義，
  • 最後，依LoginSelectorHandler的定義，回退至預設登入頁面。

• 一旦透過上述呼叫取得有效的登入路徑，使用者的要求就會重新導向至該頁面。

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

• 登入路徑的註冊取決於是否區分過期的密碼，以及是否需要定期登入以做為重新導向的原因

• 若是定期登入，測試是否可依下列順序取得登入路徑：

  • 從由新com.adobe.granite.auth.requirement.impl.RequirementService實施的LoginPathProvider,
  • 從舊有、已過時的CUG實作，
  • 從以LoginSelectorHandler定義的登入頁面映射，
  • 最後回退至使用LoginSelectorHandler定義的預設登入頁面。

• 一旦透過上述呼叫取得有效的登入路徑，使用者的要求就會重新導向至該頁面。

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

最佳作法

在定義驗證要求時，應考慮以下最佳做法：

• 避免巢狀驗證需求：在樹的開頭放置單個驗證要求標籤應該足夠，並繼承到目標節點定義的整個子樹。 該樹狀結構中的其他驗證需求應視為多餘，並可能在評估Apache Sling中的驗證需求時導致效能問題。 通過將授權和認證相關的CUG區分開，可以通過CUG或其他類型的策略限制讀訪問，同時強制對整個樹進行認證。

• 模型儲存庫內容，以便驗證要求適用於整個樹，而無需再次將嵌套子樹排除在要求之外。

• 要避免指定，並隨後註冊冗餘登錄路徑：

  • 依賴繼承並避免定義巢狀登錄路徑，
  • 不要將可選登錄路徑設定為與預設值或繼承值相對應的值，
  • 應用程式開發人員應識別應在與LoginSelectorHandler關聯的全域登入路徑組態（預設和映射）中設定哪些登入路徑。

儲存庫中的表示法

資料庫中的CUG策略表示

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

資料庫中的驗證要求

對單獨驗證要求的需要反映在儲存庫內容中，該儲存庫內容具有位於目標節點上的專用混合節點類型。 混合類型定義了一個可選屬性，用於為目標節點定義的樹指定專用登錄頁。

與登錄路徑關聯的頁面可以位於該樹內或外。 它將被排除在驗證要求之外。

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

管理CUG策略和驗證要求

管理CUG策略

使用JCR訪問控制管理API管理用於限制CUG讀訪問的新型訪問控制策略，並遵循JCR 2.0規範中描述的機制。

設定新的CUG策略

在以前沒有設定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策略

編輯現有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策略

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策略

尋找在指定路徑上定義的所有巢狀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);
}

由Pincipal管理CUG策略

JackrabbitAccessControlManager定義的允許按承擔者編輯訪問控制策略的擴展不會與CUG訪問控制管理一起實現，因為定義中，CUG策略始終影響所有承擔者：與PrincipalSetPolicy一起列出的用戶將被授予讀訪問權限，而所有其他承擔者將無法讀取目標節點定義的樹中的內容。

對應的方法始終返回空策略陣列，但不會拋出異常。

管理驗證要求

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

新增驗證要求

建立新驗證要求的步驟如下。 請注意，如果RequirementHandler已針對包含目標節點的樹狀結構設定，則需求將只會註冊到Apache Sling Authenticator。

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();

檢索有效驗證要求

沒有專用的公用API可讀取所有已註冊Apache Sling Authenticator的有效驗證需求。 但是，清單會在系統控制台的「驗證要求配置」部分的https://<serveraddress>:<serverport>/system/console/slingauth中顯示。

下圖顯示具有示範內容之發佈例AEM項的驗證需求。 社群頁面的反白顯示路徑說明本檔案中所述實施新增的需求如何反映在Apache Sling Authenticator中。

檢索有效登錄路徑

目前沒有公用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策略和驗證要求

下表列出了通過配置同時啟用兩個模組的實例中CUG策略的有AEM效組合和驗證要求。

需要驗證	登入路徑	受限讀取存取	預期效果
是	是	是	只有在有效權限評估授予訪問權限時，給定用戶才能查看用CUG策略標籤的子樹。 未驗證的使用者將重新導向至指定的登入頁面。
是	否	是	只有在有效權限評估授予訪問權限時，給定用戶才能查看用CUG策略標籤的子樹。 未驗證的使用者將重新導向至繼承的預設登入頁面。
是	是	否	未驗證的使用者將重新導向至指定的登入頁面。 是否允許它查看使用驗證要求標籤的樹取決於該子樹中包含的各個項目的有效權限。 沒有專用的CUG限制讀訪問。
是	否	否	未驗證的使用者將重新導向至繼承的預設登入頁面。 是否允許它查看使用驗證要求標籤的樹取決於該子樹中包含的單個項目的有效權限。 沒有專用的CUG限制讀訪問。
否	否	是	如果有效權限評估授予訪問權限，則給定的已驗證或未驗證用戶只能查看用CUG策略標籤的子樹。 未驗證的使用者會受到同等對待，不會重新導向至登入。

OSGi元件和配置

本節概述OSGi元件以及新CUG實施中引入的各個配置選項。

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

授權：設定和配置

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

設定CUG授權

有關的Apache文檔🔗中詳細描述了設定CUG授權。 依預設，AEMCUG授權會部署在所有執行模式中。 該逐步指令也可用於在那些需要不同授權設定的安裝中禁用CUG授權。

設定反向連結篩選

您也需要設定Sling Referrer Filter，其中包含所有可用來存取的主機名AEM稱；例如，透過CDN、Load Balancer和其他任何方式。

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

已引入下列兩個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權限的授權設定。
組態屬性	cugSupportedPaths cugEnabled configurationRanking 此外，請參閱下面的配置選項。
配置策略	ConfigurationPolicy.REQUIRE
引用	CugExclude (ReferenceCardinality.OPTIONAL_UNARY)

org.apache.jackrabbit.oak.spi.security.authorization.cug.impl.CugExcludeImpl

標籤	Apache Jackrabbit Oak CUG排除清單
說明	允許從CUG評估中排除具有配置名稱的承擔者。
組態屬性	principalNames 另請參閱下方的「設定選項」一節。
配置策略	ConfigurationPolicy.REQUIRE
引用	不適用

配置選項

主要配置選項包括：

• cugSupportedPaths:指定可能包含CUG的子樹。未設定預設值
• cugEnabled:配置選項，以啟用對當前CUG策略的權限評估。

有關CUG-authorization模組的可用配置選項，請參見Apache Oak Documentation，並詳細說明。

從CUG評估中排除承擔者

對個人原則不進行CUG評價。 新的CUG授權以名為CugExclude的專用介面來涵蓋此點。 Apache Jackrabbit Oak 1.4提供預設實作，排除固定的承擔者集合，以及可設定個別承擔者名稱的擴充實作。 後者是在發佈實例AEM中配置的。

自6.3以AEM來的預設值會防止以下承擔者受到CUG策略的影響：

• 管理承擔者（管理員使用者、管理員群組）
• 服務用戶承擔者
• 儲存庫內部系統主機

如需詳細資訊，請參閱下方自6.3<a1/AEM>區段起的預設設定中的表格。

「管理員」群組的排除可在​Apache Jackrabbit Oak CUG排除清單​的設定區段中，在系統主控台中變更或擴充。

或者，可以提供和部署CugExclude介面的自定義實現，以在特殊需要時調整排除的承擔者集。 如需詳細資訊和實作範例，請參閱CUG可插拔性上的檔案。

驗證：設定和配置

新的驗證相關部分包含在​Adobe花崗岩驗證處理程式​包（com.adobe.granite.auth.authhandler 5.6.48版）中。 此套件是預設安裝的一AEM部分。

為了為已過時的CUG支援設定驗證要求替換，某些OSGi元件必須存在並在給定安裝中處於活動狀態AEM。 如需詳細資訊，請參閱下方的​OSGi元件特性。

OSGi元件的特性

已引入下列2個OSGi元件，以定義驗證需求並指定專用的登入路徑：

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

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

標籤	-
說明	用於驗證要求的專用OSGi服務，該服務針對影響驗證要求的內容更改（通過granite:AuthenticationRequirement混合類型）和登錄路徑向LoginSelectorHandler公開的內容更改註冊觀察器。
組態屬性	-
配置策略	ConfigurationPolicy.OPTIONAL
引用	RequirementHandler (ReferenceCardinality.MANDATORY_UNARY) Executor (ReferenceCardinality.MANDATORY_UNARY)

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

標籤	AdobeGranite驗證要求和登入路徑處理常式
說明	RequirementHandler 會更新Apache Sling驗證需求的實作，以及相關登入路徑的對應排除。
組態屬性	supportedPaths
配置策略	ConfigurationPolicy.REQUIRE
引用	不適用

配置選項

CUG重寫的驗證相關部分僅附帶與AdobeGranite驗證要求和登錄路徑處理程式關聯的單個配置選項：

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

屬性	類型	預設值	說明
標籤=支援的路徑 名稱= 'supportedPaths'	Set<String>	-	此處理常式將遵循驗證要求的路徑。 如果要將granite:AuthenticationRequirement mixin類型添加到節點而不強制執行（例如，在作者實例上），請取消設定此配置。 如果缺失，則禁用此功能。

自6.AEM3以來的預設配置

預設情況下AEM，新安裝將使用新實施來授權和驗證CUG功能的相關部分。 舊版實作「Adobe花崗岩封閉使用者群組(CUG)支援」已過時，依預設會在所有安裝中停用AEM。 新實作將改為啟用如下：

作者例項

"Apache Jackrabbit Oak CUG Configuration"	說明
支援的路徑/content	已啟用CUGpolicys的訪問控制管理。
啟用CUG評估的FALSE	權限評估已停用。 CUG政策沒有作用。
等級	200

發佈例項

"Apache Jackrabbit Oak CUG Configuration"	說明
支援的路徑/content	CUG策略的訪問控制管理在配置的路徑下啟用。
啟用CUG評估TRUE	在已設定路徑下方啟用權限評估。 CUG策略對Session.save()生效。
等級	200

"Apache Jackrabbit Oak CUG排除清單"	說明
承擔者名稱管理員	排除管理員承擔者，使其不參與CUG評估。

「AdobeGranite驗證要求和登入路徑處理常式」	說明
支援的路徑/content	通過granite:AuthenticationRequired混合類型在儲存庫中定義的驗證要求在Session.save()上生效。 /contentSling Authenticator會更新。 將混合類型添加到支援路徑之外會被忽略。

禁用CUG授權和驗證要求

如果給定安裝不使用CUG或使用不同的方法進行驗證和授權，則可以完全禁用新實施。

禁用CUG授權

有關如何從複合授權設定中刪除CUG授權模型的詳細資訊，請參閱CUG可插拔性文檔。

禁用驗證要求

為了禁用granite.auth.authhandler模組提供的驗證要求支援，已足以刪除與​AdobeGranite驗證要求和登錄路徑處理程式​相關的配置。

與其他模組的交互

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的導入機制已調整為處理PrincipalSetPolicy類型的訪問控制策略。

Apache Sling Content Distribution

請參閱上述Apache Jackrabbit FileVault章節。

Adobe花崗岩複製

為了能夠在不同實例之間複製CUG策略，複製模組稍微進行了AEM調整：

• DurboImportConfiguration.isImportAcl() 僅影響訪問控制策略的實施 javax.jcr.security.AccessControlList

• DurboImportTransformer 將僅遵守此配置，以便使用真正的ACL

• 其他策略（如由CUG授權模型建立的org.apache.jackrabbit.api.security.authorization.PrincipalSetPolicy實例）將始終被複製，配置選項DurboImportConfiguration.isImportAcl()將被忽略。

複製CUG策略有一個限制。 如果刪除了給定的CUG策略而未刪除相應的混合節點類型rep:CugMixin, ，則複製時將不反映刪除。 已解決此問題：在刪除策略時始終刪除混音。 不過，如果手動添加混合類型，則可能會顯示該限制。

AdobeGranite驗證處理常式

com.adobe.granite.auth.authhandler套件隨附的驗證處理常式​Adobe花崗岩HTTP標題驗證處理常式​包含由相同模組定義之CugSupport介面的參考。 它用於在某些情況下計算「領域」，返回到使用處理程式配置的領域。

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

AEM LiveCopy

將CUG與LiveCopy一起配置在儲存庫中通過添加一個額外節點和一個額外屬性來表示，如下所示：

• /content/we-retail/us/en/blueprint/rep:cugPolicy
• /content/we-retail/us/en/LiveCopy@granite:loginPath

這兩個元素都在cq:Page下建立。 在當前設計中，MSM僅處理cq:PageContent(jcr:content)節點下的節點和屬性。

因此，CUG組無法從「Blueprints」（藍圖即時副本）中展開。 設定即時副本時，請針對此進行規劃。

新CUG實施的變更

本節的目的是概述對CUG功能所做的更改以及新舊實施的比較。 它列出了影響CUG支援配置方式的更改，並說明了如何和由誰在儲存庫內容中管理CUG。

CUG設定和配置中的差異

已過時的OSGi元件​Adobe花崗岩封閉用戶組(CUG)支援(com.day.cq.auth.impl.cug.CugSupportImpl)已被新元件替換，以便能夠分別處理前CUG功能的授權和驗證相關部分。

在儲存庫內容中管理CUG的差異

以下各節從實施和安全性角度說明新舊實施之間的差異。 雖然新的實作旨在提供相同的功能，但在使用新CUG時，有一些細微的變更需要知道。

與授權有關的差異

從授權角度來看，主要差異概述於下列清單：

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檔案所述，只有在Oak資料庫中所配置的所有模型的權限評估授予讀取存取權時，才會授予允許檢視CUGcontent的指定承擔者讀取存取權。

換言之，在評估有效權限時，將同時考慮CUGPolicy和預設訪問控制項，並且只有在兩種策略都授予對CUG內容的讀訪問權時才授予對CUG內容的讀訪問權。 在預設AEM的發佈安裝中，每個人都獲得對完整/content樹狀結構的讀取訪問權，CUG策略的效果將與舊實施相同。

隨選評估

CUG授權模型允許個別開啟存取控制管理與權限評估：

• 如果模組具有一個或多個可建立CUG的支援路徑，則啟用訪問控制管理
• 僅當另外勾選選項​啟用CUG評估​時，才啟用權限評估。

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

如上所述，CUG存取控制原則現在一律儲存在內容中，但只有當Apache Jackrabbit Oak CUG Configuration的系統主控台中開啟 CUG Evaluation Enabled 時，才會執行這些原則所產生的有效權限評估。 依預設，它僅啟用「發佈」執行模式。

與驗證的差異

以下說明與驗證有關的差異。

用於驗證要求的專用混音類型

在前述實現中，CUG的授權和驗證方面都由單個JCR屬性(cq:cugEnabled)觸發。 就驗證而言，這會產生與Apache Sling Authenticator實作一起儲存的更新驗證需求清單。 通過新的實施，通過用專用混頻類型(granite:AuthenticationRequired)標籤目標節點來獲得相同的結果。

排除登錄路徑的屬性

mixin類型定義了一個名為granite:loginPath的單一可選屬性，該屬性基本上與cq:cugLoginPage屬性相對應。 與先前的實施相比，只有在其聲明節點類型為上述混音時，才會考慮登入路徑屬性。 新增具有該名稱的屬性而不設定mixin類型將無效，且不會向驗證者報告登入路徑的新要求或排除。

驗證要求的權限

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

就granite:loginPath而言，添加、修改或刪除屬性時需要相同的權限。

由Mixin類型定義的目標節點

驗證要求應在JCR節點上建立，該節點定義要受強制登錄約束的子樹。 如果CUG預期會影響整個樹狀結構，AEM則此為頁面，而新實作的UI會因此在頁面節點上新增驗證需求混合類型。

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

這可能是一個有效的方案，而且對於允許將混合放在任意節點的儲存庫編輯器是可能的。 但是，此行為與前一個實作不同，其中在jcr:content節點上放置cq:cugEnabled或cq:cugLoginPage屬性會在內部重新對應至頁面節點。 不再執行此映射。

已配置支援的路徑

granite:AuthenticationRequired mixin類型和granite:loginPath屬性只能在​​ Adobe花崗岩驗證要求和登入路徑處理常式​所顯示的「支援路徑」組態選項集所定義的範圍內。 如果未指定路徑，則完全禁用驗證要求功能。 在此例中，混合類型或屬性在添加或設定為給定JCR節點時生效。

JCR內容、OSGi服務和配置的映射

以下文檔提供了舊實施和新實施之間OSGi服務、配置和儲存庫內容的完整映射。

自6.AEM3以來的CUG映射

取得檔案

升級CUG

使用已過時的CUG的現有安裝

舊版CUG支援實作已過時，將在未來版本中移除。 建議從6.3以前的版本升級時，移至AEM新實作。

對於升AEM級安裝，請務必確保只啟用一個CUG實施。 新的和舊的、已過時的CUG支援的組合不會進行測試，並可能導致不希望的行為：

• Sling驗證器中與驗證要求的衝突
• 當與舊CUG關聯的ACL設定與新CUG策略衝突時，拒絕讀訪問。

遷移現有CUG內容

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

1. 前往https://<serveraddress>:<serverport>/system/console/cug-migration存取工具。
2. 輸入要檢查CUG的根路徑，然後按​執行dry run​按鈕。 這會掃描所選位置中可辨識的轉換CUG。
3. 查看結果後，按​執行遷移​按鈕遷移到新實施。