自AEM 6.3開始,已推出新的封閉使用者群組實作,旨在解決現有實作帶來的效能、擴充性和安全性問題。
為了簡單起見,本檔案全程使用CUG縮寫。
新實作的目標是在必要時涵蓋現有功能,同時解決舊版本的問題和設計限制。 結果會產生具有下列特性的新CUG設計:
在AEM環境中已知的CUG包含下列步驟:
新實作的設計目的是在驗證和授權元素之間畫出一條線。 自AEM 6.3起,您可以限制讀取存取權,而不明確新增驗證需求。 例如,如果指定的執行處理完全需要驗證,或指定的樹狀結構已位於需要驗證的子樹狀結構中。
同樣地,指定樹狀結構可標示驗證需求,而不需變更有效的許可權設定。 組合和結果會列在 結合CUG政策與驗證需求 區段。
CUG的主要功能是限制內容存放庫中指定樹狀結構的讀取存取權,僅限選取的主參與者以外的所有人。 新實作不會即時操控預設存取控制內容,而是會透過定義代表CUG的專屬存取控制原則型別採取不同方法。
這種新型別的原則具有以下特性:
用於表示CUG的PrincipalSetPolicy實作還定義了:
這些CUG原則會透過名為oak-authorization-cug的個別授權模組部署至AEM執行個體。 此模組隨附自己的存取控制管理和許可權評估。 換言之,預設的AEM設定會提供結合了多個授權機制的Oak內容存放庫設定。 如需詳細資訊,請參閱 Apache Oak檔案上的此頁面.
在此複合設定中,新的CUG不會取代附加至目標節點的現有存取控制內容,而是設計成一種補充,稍後也可以移除,而不會影響原始存取控制,預設情況下,AEM中的存取控制清單就是如此。
相較於之前的實施,新的CUG政策一律會被辨識及視為存取控制內容。 這表示它們是使用JCR存取控制管理API建立和編輯的。 如需詳細資訊,請參閱 管理CUG政策 區段。
除了CUG的專用存取控制管理外,新的授權模型可讓您有條件地啟用其原則的許可權評估。 這可讓您在中繼環境中設定CUG原則,並且只允許在複製到生產環境後評估有效許可權。
CUG原則的許可權評估以及與預設或任何其他授權模型的互動,遵循為Apache Jackrabbit Oak中的多個授權機制設計的模式:若且唯若所有模型都授予存取權時,才會授予一組給定許可權。 另請參閱 此頁面 以取得更多詳細資料。
下列特性適用於與授權模型相關的許可權評估,這些授權模型設計用來處理和評估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型別取代剩餘JCR屬性的使用 granite:AuthenticationRequired
,會為登入路徑定義STRING型別的單一選用屬性 granite:loginPath
. 只有與此mixin型別相關的內容變更,才會導致更新向Apache Sling Authenticator註冊的需求。 在持續進行任何暫時性修改時會追蹤修改,因此需要 javax.jcr.Session.save()
呼叫以生效。
同樣的情況適用於 granite:loginPath
屬性。 只有當它是由驗證需求相關的mixin型別定義時,才會被遵守。 在非結構化JCR節點中新增具有此名稱的剩餘屬性將不會顯示所需的效果,並且負責更新OSGi註冊的處理常式將忽略該屬性。
設定登入路徑屬性是選擇性的,而且只有在需要驗證的樹狀結構無法回覆為預設或以其他方式繼承的登入頁面時才需要。 請參閱 登入路徑評估 底下。
由於此型別的驗證需求應限製為某些執行模式,以及內容存放庫中的一小部分樹狀結構,因此對需求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
此處理常式會嘗試判斷要將使用者重新導向的對應登入頁面。 此工作流程包含下列步驟:
區分過期密碼和需要定期登入作為重新導向的原因;
如果是定期登入,會測試是否可依下列順序取得登入路徑:
com.adobe.granite.auth.requirement.impl.RequirementService
,LoginSelectorHandler
,LoginSelectorHandler
.一旦透過上述呼叫取得有效的登入路徑,使用者的請求就會重新導向至該頁面。
本檔案的目標是評估內部公開的登入路徑 LoginPathProvider
介面。 自AEM 6.3以來出貨的實作行為如下:
登入路徑的註冊取決於區分過期密碼和需要定期登入作為重新導向的原因
若為一般登入,會測試登入路徑是否可依下列順序取得:
LoginPathProvider
由新實作 com.adobe.granite.auth.requirement.impl.RequirementService
,LoginSelectorHandler
,LoginSelectorHandler
.一旦透過上述呼叫取得有效的登入路徑,使用者的請求就會重新導向至該頁面。
此 LoginPathProvider
由Granite中新的驗證需求支援實作,會公開由定義的登入路徑 granite:loginPath
屬性,這些屬性又由mixin型別定義,如上所述。 儲存登入路徑的資源路徑與屬性值本身的對應會保留在記憶體中,並會進行評估以找出適合階層中其他節點的登入路徑。
評估只會針對與位於已設定支援路徑中的資源相關聯的請求執行。 對於任何其他請求,將會評估判斷登入路徑的替代方法。
定義驗證需求時,應考量下列最佳實務:
避免巢狀驗證需求:在樹狀結構開頭放置單一驗證需求標籤,應該就足夠了,而且會繼承至目標節點定義的整個子樹狀結構。 在評估Apache Sling中的驗證需求時,應該將該樹狀結構中的其他驗證需求視為備援,可能會導致效能問題。 透過將授權和驗證相關的CUG區域分離,可以透過CUG或其他型別的原則來限制讀取存取權,同時強制整個樹狀結構的驗證。
為存放庫內容建模,使得驗證需求適用於整個樹狀結構,而無需再次從需求中排除巢狀子樹狀結構。
若要避免指定並隨後註冊多餘的登入路徑,請執行下列動作:
LoginSelectorHandler
.Oak檔案說明新CUG政策在存放庫內容中的反映方式。 如需詳細資訊,請參閱 此頁面.
將專用mixin節點型別放置在目標節點的存放庫內容中,會反映需要單獨的驗證要求。 mixin型別會定義選擇性屬性,以指定目標節點所定義之樹狀結構的專用登入頁面。
與登入路徑相關聯的頁面可能位於該樹狀結構內部或外部。 它將被排除在驗證需求之外。
[granite:AuthenticationRequired]
mixin
- granite:loginPath (STRING)
限制對CUG讀取存取的新型別的存取控制政策,是使用JCR存取控制管理API來管理,並遵循以下所述的機制: JCR 2.0規格.
此程式碼可在之前未設定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原則需要下列步驟。 修改的原則需要回寫,而變更需要透過保留 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");
}
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,無論其是否生效。 如需詳細資訊,請參閱 設定選項 區段。
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);
}
擴充功能定義自 JackrabbitAccessControlManager
允許依主體編輯存取控制原則的存取控制原則,不會使用CUG存取控制管理實作,因為根據定義,CUG原則一律會影響所有主體:以 PrincipalSetPolicy
正在被授與讀取存取權,而所有其他主體將禁止讀取目標節點所定義樹狀結構中的內容。
對應方法一律會傳回空的原則陣列,但不會擲回例外狀況。
新驗證需求的建立、修改或移除是透過變更目標節點的有效節點型別來實現的。 然後,您可使用一般JCR API來寫入選用的登入路徑屬性。
如果符合以下條件,則上述對給定目標節點的修改將僅反映在Apache Sling驗證器中: RequirementHandler
而且目標包含在由支援的路徑定義的樹狀結構中(請參閱設定選項區段)。
如需詳細資訊,請參閱 指派Mixin節點型別和 新增節點及設定屬性
建立驗證需求的步驟詳述如下。 只有在符合以下條件時,此要求才會向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();
}
}
下表列出透過設定同時啟用兩個模組的AEM執行個體中,CUG原則及驗證需求的有效組合。
需要驗證 | 登入路徑 | 限制的讀取存取權 | 預期效果 |
---|---|---|---|
是 | 是 | 是 | 如果有效的許可權評估授予存取權,特定使用者將只能檢視以CUG原則標籤的子樹狀結構。 系統會將未驗證的使用者重新導向至指定的登入頁面。 |
是 | 否 | 是 | 如果有效的許可權評估授予存取權,特定使用者將只能檢視以CUG原則標籤的子樹狀結構。 未經驗證的使用者會重新導向至繼承的預設登入頁面。 |
是 | 是 | 否 | 系統會將未驗證的使用者重新導向至指定的登入頁面。 是否允許檢視以驗證需求標示的樹狀結構,取決於該子樹狀結構中個別專案的有效許可權。 沒有專用的CUG限制讀取存取權。 |
是 | 否 | 否 | 未經驗證的使用者會重新導向至繼承的預設登入頁面。 是否允許檢視以驗證需求標示的樹狀結構,取決於該子樹狀結構中個別專案的有效許可權。 沒有專用的CUG限制讀取存取權。 |
否 | 否 | 是 | 如果有效的許可權評估授權存取,則指定的已驗證或未驗證使用者將只能檢視標示CUG原則的子樹狀結構。 系統會對未經驗證的使用者一視同仁,不會將他們重新導向以登入。 |
「驗證需求」=「否」和「登入路徑」=「是」的組合未列出,因為「登入路徑」是與驗證需求相關聯的選擇性屬性。 指定具有該名稱的JCR屬性而不新增定義mixin型別將沒有效果,且將被對應的處理常式忽略。
本節提供OSGi元件的概觀,以及新CUG實施匯入的個別設定選項。
另請參閱CUG對應檔案,取得新舊實施之間的設定選項完整對應。
新的授權相關零件包含在 Oak CUG授權 組合( org.apache.jackrabbit.oak-authorization-cug
),這是AEM預設安裝的一部分。 該套件定義了一個獨立的授權模型,旨在部署為管理讀取存取權的額外方法。
有關設定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元件已匯入以定義驗證需求並指定專用登入路徑:
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許可權的授權設定。 |
組態屬性 |
另請參閱 設定選項 底下。 |
設定原則 | ConfigurationPolicy.REQUIRE |
參考 | CugExclude (ReferenceCardinality.OPTIONAL_UNARY) |
org.apache.jackrabbit.oak.spi.security.authorization.cug.impl.CugExcludeImpl
標籤 | Apache Jackrabbit Oak CUG排除清單 |
說明 | 可讓您從CUG評估中排除具有已設定名稱的主參與者。 |
組態屬性 |
另請參閱下方的組態選項一節。 |
設定原則 | ConfigurationPolicy.REQUIRE |
參考 | 不適用 |
主要組態選項包括:
cugSupportedPaths
:指定可能包含CUG的子樹狀結構。 未設定預設值cugEnabled
:為目前CUG原則啟用許可權評估的設定選項。與CUG-authorization模組相關的可用組態選項列示於,並詳見 Apache Oak檔案.
先前實作已採用免除個別主參與者進行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元件的特性
下列兩個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 |
參考 |
|
com.adobe.granite.auth.requirement.impl.DefaultRequirementHandler
標籤 | AdobeGranite驗證需求和登入路徑處理常式 |
---|---|
說明 | RequirementHandler 此實施會更新Apache Sling驗證要求,以及相關登入路徑的對應排除。 |
組態屬性 | supportedPaths |
設定原則 | ConfigurationPolicy.REQUIRE |
參考 | 不適用 |
CUG重寫的驗證相關部分只隨附與Adobe「Granite驗證需求」和「登入路徑處理常式」相關聯的單一組態選項:
「驗證需求和登入路徑處理常式」
屬性 | 類型 | 預設值 | 說明 |
標籤=支援的路徑 名稱= 'supportedPaths' |
設定<string> | - | 此處理常式遵循驗證要求的路徑。 如果您要新增 granite:AuthenticationRequirement 將mixin型別新增至節點,而不強制執行這些節點(例如在作者執行個體上)。 如果遺失,則功能會停用。 |
AEM的新安裝預設會將新的實施用於CUG功能的授權和驗證相關部分。 舊版實作「AdobeGranite封閉使用者群組(CUG)支援」已過時,並預設會在所有AEM安裝中停用。 新的實作將改為啟用,如下所示:
「Apache Jackrabbit Oak CUG設定」 | 解釋 |
---|---|
支援的路徑 /content |
CUGpolicies的存取控制管理已啟用。 |
CUG評估啟用FALSE | 已停用許可權評估。 CUG政策無效。 |
等級 | 200 |
沒有的設定 Apache Jackrabbit Oak CUG排除清單 和 AdobeGranite驗證需求和登入路徑處理常式 會出現在預設的編寫執行個體上。
「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授權模型的詳細資訊,請參閱檔案。
若要停用對驗證需求的支援,請參閱 granite.auth.authhandler
模組足以移除與關聯的組態 AdobeGranite驗證需求和登入路徑處理常式.
但是請注意,移除設定將不會取消註冊mixin型別,這仍然適用於節點而不會生效。
為了反映CUG授權模型使用的新型別的存取控制政策,Apache Jackrabbit定義的API已擴充。 自2.11.0版的 jackrabbit-api
模組會定義名為的新介面 org.apache.jackrabbit.api.security.authorization.PrincipalSetPolicy
,會從 javax.jcr.security.AccessControlPolicy
.
已調整Apache Jackrabbit FileVault的匯入機制,以處理型別的存取控制政策 PrincipalSetPolicy
.
請參閱上文 Apache Jackrabbit FileVault 區段。
復寫模組已稍微調整,以便能夠在不同的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 HTTP標頭驗證處理常式 隨附於 com.adobe.granite.auth.authhandler
束儲存參照 CugSupport
由相同模組定義的介面。 在特定情況下,它可用來計算「範圍」,並歸入使用處理常式設定的範圍。
這已經過調整,以做為參考 CugSupport
選擇性,可在指定設定決定重新啟用已棄用的實作時,確保最大限度的回溯相容性。 使用實作的安裝將不會再從CUG實作中擷取領域,但會一律顯示領域,如使用所定義 AdobeGranite HTTP標頭驗證處理常式.
根據預設, AdobeGranite HTTP標頭驗證處理常式 只會在發佈執行模式中以「停用登入頁面」( auth.http.nologin
)選項已啟用。
在存放庫中結合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在存放庫內容中的管理方式及管理者。
過時的OSGi元件 Adobe Granite封閉使用者群組(CUG)支援 ( com.day.cq.auth.impl.cug.CugSupportImpl
)已由新元件取代,以便能夠分別處理舊版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授權模型允許個別開啟存取控制管理和許可權評估:
在新的AEM預設設定CUG原則評估中,它僅能以「發佈」執行模式啟用。 欲知詳情,請參閱 自AEM 6.3以來的預設設定 以取得更多詳細資料。 這可透過比較給定路徑的有效原則與內容中儲存的原則來驗證。 只有啟用CUG的許可權評估時,才會顯示有效原則。
如上所述,CUG存取控制原則現在一律會儲存在內容中,但是只有在 CUG評估已啟用 在Apache Jackrabbit Oak的系統主控台中開啟 CUG設定。 預設情況下,僅在「發佈」執行模式中啟用它。
關於驗證的差異如下所述。
在之前的實作中,CUG的授權和驗證層面都是由單一JCR屬性( cq:cugEnabled
)。 就驗證而言,這會產生與Apache Sling Authenticator實作儲存的驗證需求更新清單。 在新實施中,使用專用的mixin型別( granite:AuthenticationRequired
)。
mixin型別會定義單一、選用的屬性,稱為 granite:loginPath
,基本上對應至 cq:cugLoginPage
屬性。 相較於先前的實施,只有當其宣告節點型別是上述的mixin時,才會考量登入路徑屬性。 新增具有該名稱的屬性而不設定mixin型別將沒有效果,並且不會向驗證者報告針對登入路徑的新要求或排除。
新增或移除mixin型別需要 jcr:nodeTypeManagement
正在授與許可權。 在上一個實作中, jcr:modifyProperties
許可權用於編輯剩餘屬性。
至此 granite:loginPath
擔心新增、修改或移除屬性需要相同的許可權。
在JCR節點建立驗證需求,定義要強制登入的子樹狀結構。 這可能是個AEM頁面,以防CUG預計會影響整個樹狀結構,且新實作的UI隨後會在頁面節點上新增驗證需求mixin型別。
將CUG原則僅放置在位於指定頁面下方的jcr:content節點會限制內容的存取權,但不會影響頁面節點本身或任何子頁面。
這可能是有效的案例,並且可在允許將mixin放置在任何節點的存放庫編輯器中進行。 不過,此行為與之前的實施相反,也就是在jcr:content節點上放置cq:cugEnabled或cq:cugLoginPage屬性最終會在內部重新對應至頁面節點。 不再執行此對應。
兩者 granite:AuthenticationRequired
mixin型別和granite:loginPath屬性只能在 支援的路徑 組態選項與 AdobeGranite驗證需求和登入路徑處理常式. 如果未指定路徑,則會完全停用驗證需求功能。 在這種情況下,將mixin型別或屬性新增或設定到給定JCR節點時會生效。
以下檔案提供舊實作與新實作之間的OSGi服務、設定和存放庫內容的完整對應。
AEM 6.3之後的CUG對應
舊的CUG支援實作已淘汰,並將在未來版本中移除。 從AEM 6.3之前的版本升級時,建議改用新的實作。
對於升級的AEM安裝,請務必確保僅啟用一個CUG實作。 新的和舊的、已棄用的CUG支援組合未經測試,並可能會導致不良行為:
Adobe提供了移轉至新CUG實作的工具。 若要使用,請執行下列步驟:
https://<serveraddress>:<serverport>/system/console/cug-migration
以存取工具。如果您遇到問題,可以在以下位置設定特定記錄器: 偵錯 平準於 com.day.cq.auth.impl.cug
以取得移轉工具的輸出。 另請參閱 記錄 以取得執行此動作的詳細資訊。