AEM 中的封閉使用者群組

簡介

自AEM 6.3開始，已推出新的封閉使用者群組實作，旨在解決現有實作帶來的效能、擴充性和安全性問題。

新實作的目標是在必要時涵蓋現有功能，同時解決舊版本的問題和設計限制。 結果會產生具有下列特性的新CUG設計：

• 身份驗證和授權元素的明確分離，可單獨或組合使用；
• 專屬授權模型，可反映已設定之CUG樹狀結構的受限讀取存取權，而不會干擾其他存取控制設定和許可權需求；
• 將限制讀取存取的存取控制設定（通常在編寫執行個體上需要）與許可權評估（通常僅在發佈上需要）分開；
• 編輯受限制的讀取存取權而不提升許可權；
• 專用的節點型別延伸以標示驗證需求；
• 與驗證需求相關聯的選擇性登入路徑。

新的自訂使用者群組實作

在AEM環境中已知的CUG包含下列步驟：

• 限制需要保護的樹狀結構上的讀取存取權，並只允許讀取隨指定CUG執行個體列出或完全從CUG評估中排除的主參與者。 這稱為 authorization 元素。
• 強制驗證指定的樹狀結構，並選擇性地為該樹狀結構指定後續排除的專用登入頁面。 這稱為 authentication 元素。

新實作的設計目的是在驗證和授權元素之間畫出一條線。 自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，而不會繼承「父」CUG的主體集；
• 如果已啟用評估，則原則的效果會繼承至整個子樹狀結構，直到下一個巢狀CUG。

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

在此複合設定中，新的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原則支援的路徑限制在存放庫中的幾個樹狀結構，以便獲得最佳效能。 例如，自AEM 6.3起，僅允許將/content節點底下的CUG作為預設值送出。

• CUG原則的設計目的，是要授予一小部分主體的讀取存取權。 大量主體的需求可能會突顯內容或應用程式設計中的問題，因此應重新考慮。

驗證：定義驗證需求

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

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

使用專用的Mixin型別定義驗證需求

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

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

向Sling驗證者註冊驗證需求和登入路徑

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

預設AEM設定現在會使用此設定，允許以製作執行模式設定mixin，但只有在複製到發佈執行個體時才會生效。 另請參閱 此頁面 以瞭解Sling如何執行驗證要求的詳細資訊。

新增 granite:AuthenticationRequired 在設定的支援路徑中的mixin型別將導致負責處理常式的OSGi註冊被更新，包含新的附加專案，帶有 sling.auth.requirements 屬性。 如果指定的驗證需求指定了選擇性 granite:loginPath 屬性，則值會額外向驗證器註冊，且具有'-'前置詞，以排除在驗證需求之外。

驗證需求的評估與繼承

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

登入路徑評估

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

通話時 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節點型別放置在目標節點的存放庫內容中，會反映需要單獨的驗證要求。 mixin型別會定義選擇性屬性，以指定目標節點所定義之樹狀結構的專用登入頁面。

與登入路徑相關聯的頁面可能位於該樹狀結構內部或外部。 它將被排除在驗證需求之外。

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

管理CUG原則和驗證需求

管理CUG政策

限制對CUG讀取存取的新型別的存取控制政策，是使用JCR存取控制管理API來管理，並遵循以下所述的機制： 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 (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原則

編輯現有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);
}

依主體管理CUG原則

擴充功能定義自 JackrabbitAccessControlManager 允許依主體編輯存取控制原則的存取控制原則，不會使用CUG存取控制管理實作，因為根據定義，CUG原則一律會影響所有主體：以 PrincipalSetPolicy 正在被授與讀取存取權，而所有其他主體將禁止讀取目標節點所定義樹狀結構中的內容。

對應方法一律會傳回空的原則陣列，但不會擲回例外狀況。

管理驗證需求

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

新增驗證需求

建立驗證需求的步驟詳述如下。 只有在符合以下條件時，此要求才會向Apache Sling Authenticator註冊： RequirementHandler 已為包含目標節點的樹狀結構設定。

Node targetNode = [...]

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

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

建立包含登入路徑的驗證要求的步驟。 請注意，如果符合以下條件，則登入路徑的要求和排除專案只會向Apache Sling驗證者註冊： 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驗證器中。

擷取有效登入路徑

目前沒有公用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原則的子樹狀結構。 系統會對未經驗證的使用者一視同仁，不會將他們重新導向以登入。

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-authorization模組相關的可用組態選項列示於，並詳見 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元件的特性 底下。

OSGi元件的特性

下列兩個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 type)和包含的登入路徑會公開給 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重寫的驗證相關部分只隨附與Adobe「Granite驗證需求」和「登入路徑處理常式」相關聯的單一組態選項：

「驗證需求和登入路徑處理常式」

屬性	類型	預設值	說明
標籤=支援的路徑 名稱= 'supportedPaths'	設定<string>	-	此處理常式遵循驗證要求的路徑。 如果您要新增 granite:AuthenticationRequirement 將mixin型別新增至節點，而不強制執行這些節點（例如在作者執行個體上）。 如果遺失，則功能會停用。

自AEM 6.3以來的預設設定

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

作者執行個體

「Apache Jackrabbit Oak CUG設定」	解釋
支援的路徑 /content	CUGpolicies的存取控制管理已啟用。
CUG評估啟用FALSE	已停用許可權評估。 CUG政策無效。
等級	200

發佈執行個體

「Apache Jackrabbit Oak CUG設定」	解釋
支援的路徑 /content	在設定的路徑下方啟用CUG原則的存取控制管理。
CUG評估啟用TRUE	已針對設定的路徑啟用許可權評估。 CUG政策生效日期 Session.save().
等級	200

「Apache Jackrabbit Oak CUG排除清單」	解釋
主體名稱管理員	排除CUG評估中的管理員主體。

「AdobeGranite驗證需求和登入路徑處理常式」	解釋
支援的路徑 /content	由以下方式在存放庫中定義的驗證需求： granite:AuthenticationRequired mixin型別將在以下生效 /content 於 Session.save(). Sling驗證器已更新。 在支援的路徑之外新增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內容發佈

請參閱上文 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原則時沒有移除對應的mixin節點型別 rep:CugMixin, 復寫時不會反映移除。 原則移除後，一律移除mixin即可解決此問題。 不過，如果手動新增mixin型別，則可能會顯示此限制。

AdobeGranite驗證處理常式

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

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

AEM LiveCopy

在存放庫中結合LiveCopy設定CUG時，會額外增加一個節點和一個屬性，如下所示：

• /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轉出至即時副本。 設定即時副本時，請對此進行規劃。

新CUG實作的變更

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

CUG設定和設定的差異

過時的OSGi元件 Adobe Granite封閉使用者群組(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屬性的能力已足夠，導致許可權提升。

原則定義的目標節點

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

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

使用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設定。 預設情況下，僅在「發佈」執行模式中啟用它。

與驗證相關的差異

關於驗證的差異如下所述。

驗證需求的專用Mixin型別

在之前的實作中，CUG的授權和驗證層面都是由單一JCR屬性( cq:cugEnabled)。 就驗證而言，這會產生與Apache Sling Authenticator實作儲存的驗證需求更新清單。 在新實施中，使用專用的mixin型別( granite:AuthenticationRequired)。

排除登入路徑的屬性

mixin型別會定義單一、選用的屬性，稱為 granite:loginPath，基本上對應至 cq:cugLoginPage 屬性。 相較於先前的實施，只有當其宣告節點型別是上述的mixin時，才會考量登入路徑屬性。 新增具有該名稱的屬性而不設定mixin型別將沒有效果，並且不會向驗證者報告針對登入路徑的新要求或排除。

驗證要求的許可權

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

至此 granite:loginPath 擔心新增、修改或移除屬性需要相同的許可權。

由Mixin型別定義的目標節點

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

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

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

已設定的支援路徑

兩者 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實作的工具。 若要使用，請執行下列步驟：

1. 前往 https://<serveraddress>:<serverport>/system/console/cug-migration 以存取工具。
2. 輸入您要檢查CUG的根路徑，然後按 執行試用 按鈕。 這將會在選取的位置中掃描符合轉換資格的CUG。
3. 在檢閱結果後，請按 執行移轉 按鈕，以移轉至新的實作。