Experience League

Exit search

AEM中的封閉使用者群組

簡介

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

注意

為了簡單起見，本檔案中將使用CUG縮寫。

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

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

新的自訂使用者群組實作

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

在需要保護的樹上限制讀訪問，並且只允許讀取帶有指定CUG實例的清單主體或完全排除在CUG評估之外的主體。這稱為授權元素。
在指定的樹上強制驗證，並可選地為該樹指定一個專用的登錄頁，該登錄頁隨後被排除。這稱為驗證元素。

新的實施旨在在驗證和授權元素之間划出一條線。自AEM 6.3起，可在不明確新增驗證要求的情況下限制讀取存取。例如，如果給定實例完全需要身份驗證，或給定樹已駐留在要求身份驗證的子樹中。

同樣，在不更改有效權限設定的情況下，可以用驗證要求來標籤給定的樹。組合和結果會列在結合CUG策略和身份驗證要求區段。

概觀

授權：限制讀取訪問

CUG的主要功能是限制除了所選主體之外，所有人在內容存放庫的指定樹狀結構上的讀取存取。新實施採用的方法不是即時操作預設訪問控制內容，而是定義代表CUG的專用類型的訪問控制策略。

CUG的訪問控制策略

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

org.apache.jackrabbit.api.security.authorization.PrincipalSetPolicy（由Apache Jackrabbit API定義）的存取控制原則；
PrincipalSetPolicy授予可修改的主體集的權限；
授予的權限和策略的範圍是實施詳細資訊。

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

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

這些CUG原則會透過名為oak-authorization-cug的個別授權模組部署至AEM執行個體。本模組隨附其自己的訪問控制管理和權限評估。換句話說，預設AEM設定會提供結合多個授權機制的Oak內容存放庫設定。如需詳細資訊，請參閱本頁面說明Apache Oak檔案.

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

與前一實施不同，新的CUG策略始終被識別並視為訪問控制內容。這表示使用JCR存取控制管理API來建立和編輯這些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，因為自AEM 6.3以來，預設值為已發運。
CUG策略旨在授予對一小組主體的讀取訪問權限。需要大量原則可能會突出內容或應用程式設計中的問題，應重新考慮。

驗證：定義驗證需求

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

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

使用專用混頻類型定義驗證需求

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

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

注意

設定登錄路徑屬性是可選的，並且僅當需要身份驗證的樹不能回復為預設或繼承的登錄頁時才需要。請參閱登錄路徑評估下方。

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

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

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

認證需求的評價與繼承

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

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

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

區分過期的密碼以及需要定期登錄作為重定向原因；
若是一般登入，會測試登入路徑是否可依下列順序取得：
- 從LoginPathProvider，如新 com.adobe.granite.auth.requirement.impl.RequirementService,
- 從舊有已棄用的CUG實作，
- ，以 LoginSelectorHandler,
- 最後，回復至預設登入頁面，如 LoginSelectorHandler.
一旦透過上述呼叫取得有效的登入路徑，系統就會將使用者的要求重新導向至該頁面。

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

登錄路徑的註冊取決於密碼過期和需要定期登錄作為重定向原因之間的區別
若是一般登入，會測試登入路徑是否可依下列順序取得：
- 從 LoginPathProvider 由 com.adobe.granite.auth.requirement.impl.RequirementService,
- 從舊有已棄用的CUG實作，
- ，如 LoginSelectorHandler,
- 最後，依 LoginSelectorHandler.
一旦透過上述呼叫取得有效的登入路徑，系統就會將使用者的要求重新導向至該頁面。

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

注意

僅對與配置的支援路徑中的資源關聯的請求執行評估。對於任何其他請求，將評估判斷登入路徑的替代方式。

最佳做法

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

避免嵌套身份驗證要求：在樹的開頭放置單個驗證需求標籤應足夠，並繼承至目標節點定義的整個子樹。該樹狀結構中的其他驗證需求應視為備援，且在評估Apache Sling中的驗證需求時，可能會導致效能問題。通過將授權和認證相關的CUG區域分開，可以通過CUG或其他類型的策略來限制讀取訪問，同時強制對整個樹進行認證。
模型儲存庫內容，使得驗證要求適用於整個樹，而不需要再次排除嵌套的子樹。
要避免指定，然後註冊冗餘登錄路徑：
- 依賴繼承並避免定義巢狀登入路徑，
- 請勿將選用的登入路徑設定為與預設值或繼承值相對應的值，
- 應用程式開發人員應識別應在與 LoginSelectorHandler.

在儲存庫中的表示

CUG在儲存庫中的策略表示

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

儲存庫中的驗證需求

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

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

[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策略是否在給定安裝中生效的一種方便方法。

注意

請注意 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是否生效，都會在指定路徑上找到已定義的所有巢狀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策略

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

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

管理驗證需求

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

注意

只有在 RequirementHandler 已設定，且目標包含在受支援路徑定義的樹中（請參閱「配置選項」一節）。

如需詳細資訊，請參閱分配混合節點類型和添加節點和設定屬性

新增驗證需求

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

Node targetNode = [...]

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

建立新驗證需求的步驟，包括登入路徑。請注意，登入路徑的需求和排除項目只會向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();

變更現有登入路徑的步驟於下文詳細說明。只有在 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");
}

移除現有登入路徑的步驟。只有在 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();
}

移除驗證需求

移除現有驗證需求的步驟。只有在 RequirementHandler 已為包含目標節點的樹配置。

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

session.save();

檢索有效驗證要求

沒有專用的公用API可讀取向Apache Sling Authenticator註冊的所有有效驗證需求。不過，此清單會公開於 https://<serveraddress>:<serverport>/system/console/slingauth 在「驗證需求配置」部分。

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

注意

在此示例中，未設定可選登錄路徑屬性。因此，沒有向驗證器註冊第二條。

chlimage_1-24

目前沒有公用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限制讀取訪問。
否	否	是	只有在有效權限評估授予訪問權限時，給定的已驗證或未驗證用戶才能查看標籤為CUG策略的子樹。未驗證的使用者會受到同等對待，不會被重新導向至登入。

注意

上方未列出「驗證需求」=「否」和「登入路徑」=「是」的組合，因為「登入路徑」是與驗證需求相關聯的選用屬性。指定具有該名稱的JCR屬性而不添加定義的mixin類型將無效，並且將被相應的處理程式忽略。

OSGi元件和配置

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

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

授權：設定與設定

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

設定CUG授權

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

設定反向連結篩選

您也需要設定 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元件的特性

引入下列兩個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授權模組相關聯的可用配置選項，並在 Apache Oak檔案.

將主體排除在CUG評估之外

在前一實施中，個人負責人免予進行CUG評估。新的CUG授權透過名為CugExclude的專用介面涵蓋此資訊。 Apache Jackrabbit Oak 1.4隨附預設實作，排除固定的承擔者集合，以及可設定個別承擔者名稱的延伸實作。後者是在AEM發佈執行個體中設定。

自AEM 6.3以來的預設值可防止下列主體受到CUG原則的影響：

管理主體（管理員用戶、管理員組）
服務用戶主體
儲存系統內部主體

如需詳細資訊，請參閱自AEM 6.3起的預設設定一節。

「管理員」群組的排除可在以下位置的系統主控台中變更或展開： Apache Jackrabbit Oak CUG排除清單.

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

驗證：設定與設定

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

為了為已棄用的CUG支援設定驗證需求替換，在指定的AEM安裝中，某些OSGi元件必須存在且處於活動狀態。如需更多詳細資訊，請參閱 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

標籤	-
說明	針對驗證需求的專用OSGi服務，會針對影響驗證需求的內容變更向觀察者註冊(透過 `granite:AuthenticationRequirement` mixin類型)和的登入路徑會公開給 `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'

設定<string>

此處理常式將接受驗證要求的路徑。如果您要新增 granite:AuthenticationRequirement 混合類型至節點，但未強制執行（例如在製作例項上）。如果缺少，則禁用該功能。

自AEM 6.3起的預設設定

依預設，新安裝的AEM會將新實施用於CUG功能的授權和驗證相關部分。舊版實作「AdobeGranite封閉使用者群組(CUG)支援」已淘汰，並預設會在所有AEM安裝中停用。將改為啟用新實施，如下所示：

製作例項

"Apache Jackrabbit Oak CUG Configuration"	解釋
支援的路徑 `/content`	已啟用CUGpolicies的訪問控制管理。
CUG評估已啟用FALSE	禁用權限評估。 CUG政策沒有生效。
等級	200

注意

沒有 Apache Jackrabbit Oak CUG排除清單 和 AdobeGranite驗證需求和登入路徑處理常式 預設製作執行個體上存在。

發佈例項

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

"Apache Jackrabbit Oak CUG Exclude List"	解釋
主體名稱管理員	不包括管理員主體（CUG評估）。

「AdobeGranite驗證需求和登入路徑處理常式」	解釋
支援的路徑 `/content`	存放庫中定義的驗證要求，透過 `granite:AuthenticationRequired` 混合類型在以下生效 `/content` up `Session.save()`. Sling Authenticator會更新。在支援的路徑之外新增mixin類型會遭忽略。

禁用CUG授權和身份驗證要求

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

禁用CUG授權

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

禁用身份驗證要求

為了禁用對驗證要求的支援， granite.auth.authhandler 模組，足以移除與 AdobeGranite驗證需求和登入路徑處理常式.

注意

但是，請注意，刪除配置將不會取消註銷混合類型，該類型仍適用於未生效的節點。

與其他模組的互動

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的匯入機制已調整，以處理類型的存取控制政策 PrincipalSetPolicy.

Apache Sling Content Distribution

請參閱上述 Apache Jackrabbit FileVault 區段。

AdobeGranite復寫

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

DurboImportConfiguration.isImportAcl() 按字面方式解釋，並且只會影響訪問控制策略的實施 javax.jcr.security.AccessControlList
DurboImportTransformer 只會遵守此配置，以使用真ACL
其他政策，例如 org.apache.jackrabbit.api.security.authorization.PrincipalSetPolicy 由CUG授權模型建立的實例將始終被複製，並配置選項 DurboImportConfiguration.isImportAcl()會被忽略。

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

AdobeGranite驗證處理常式

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

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

注意

依預設， AdobeGranite HTTP標題驗證處理常式 僅以「停用登入頁面」( auth.http.nologin)選項啟用。

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組無法從Blueprint轉出到Live Copy。設定Live Copy時，請針對此進行規劃。

新CUG實作的變更

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

CUG設定和配置方面的差異

已棄用的OSGi元件 AdobeGranite封閉使用者群組(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節點，只會限制對指定頁面內容s.str的存取，但不會對任何同層頁面或子頁面生效。這可能是有效的使用案例，而且可以使用允許套用微調存取內容內容的存放庫編輯器來達成。不過，它會與前一個實施作比較，前者將cq:cugEnabled屬性放置在jcr:content節點上，會在內部重新對應至頁面節點。不再執行此對應。

使用CUG策略進行權限評估

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

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

按需評估

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

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

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

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

與驗證的差異

與驗證有關的差異如下。

用於認證需求的專用混合類型

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

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

身份驗證要求的權限

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

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

由Mixin類型定義的目標節點

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

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

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

配置的支援路徑

兩者 granite:AuthenticationRequired mixin類型和granite:loginPath屬性只會在由 支援的路徑 設定選項與 AdobeGranite驗證需求和登入路徑處理常式. 如果未指定路徑，則完全禁用身份驗證要求功能。在此情況下，mixin類型或屬性在添加到給定JCR節點或設定該節點時生效。

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

以下檔案提供舊實作與新實作之間OSGi服務、設定和存放庫內容的完整對應。

自AEM 6.3以來的CUG對應

取得檔案

升級CUG

使用已棄用的CUG的現有安裝

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

對於升級的AEM安裝，請務必確保僅啟用一個CUG實作。新的和舊的、過時的CUG支援的組合不會經過測試，並且可能會導致不適當的行為：

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

移轉現有CUG內容

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

前往 https://<serveraddress>:<serverport>/system/console/cug-migration 來存取工具。
輸入要檢查CUG的根路徑，然後按 執行乾式運行 按鈕。這會掃描所選位置中符合轉換資格的CUG。
查看結果後，按 執行移轉 按鈕移轉至新實作。

注意

如果您遇到問題，可以在除錯層級 com.day.cq.auth.impl.cug 以取得移轉工具的輸出。請參閱記錄以取得如何執行此動作的詳細資訊。

Business.Adobe.com 資源

Automated Onboarding Style System Personalized Experiences Mobile Forms Theme Editor Digital Rights Management

AEM中的封閉使用者群組

簡介

新的自訂使用者群組實作

概觀

授權：限制讀取訪問

CUG的訪問控制策略

CUG策略的權限評估

最佳做法

驗證：定義驗證需求

使用專用混頻類型定義驗證需求

向Sling Authenticator註冊驗證要求和登錄路徑

認證需求的評價與繼承

登錄路徑評估

最佳做法

在儲存庫中的表示

CUG在儲存庫中的策略表示

儲存庫中的驗證需求

管理CUG策略和身份驗證要求

管理CUG策略

設定新的CUG策略

編輯現有的CUG策略

檢索有效的CUG策略

檢索繼承的CUG策略

按主管管理CUG策略

管理驗證需求

新增驗證需求

使用登入路徑新增驗證需求

修改現有登入路徑

移除現有登入路徑

移除驗證需求

檢索有效驗證要求

檢索有效登錄路徑

檢索繼承的驗證要求

結合CUG策略和身份驗證要求

OSGi元件和配置

授權：設定與設定

設定CUG授權

設定反向連結篩選

OSGi元件的特性

配置選項

將主體排除在CUG評估之外

驗證：設定與設定

配置選項

自AEM 6.3起的預設設定

製作例項

發佈例項

禁用CUG授權和身份驗證要求

禁用CUG授權

禁用身份驗證要求

與其他模組的互動

Apache Jackrabbit API

Apache Jackrabbit FileVault

Apache Sling Content Distribution

AdobeGranite復寫

AdobeGranite驗證處理常式

AEM LiveCopy

新CUG實作的變更

CUG設定和配置方面的差異

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

授權方面的差異

與驗證的差異

用於認證需求的專用混合類型

用於排除登錄路徑的屬性

身份驗證要求的權限

由Mixin類型定義的目標節點

配置的支援路徑

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

升級CUG

使用已棄用的CUG的現有安裝

移轉現有CUG內容

Business.Adobe.com 資源

本頁內容

檢視下一個:

學習

說明文件

社群

技術支援

資源

Adobe 帳戶

Adobe