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中的多个授权机制设计的模式：仅当且仅当所有模型授予访问权限时，才会授予给定的一组权限。 请参阅 本页 以了解更多详细信息。

以下特征适用于与用于处理和评估CUG策略的授权模型相关的权限评估：

单个CUG策略对权限评估的影响可概括如下：

最佳实践 best-practices

在定义通过CUG的受限读取访问时，应考虑以下最佳实践：

身份验证：定义身份验证要求 authentication-defining-the-auth-requirement

CUG功能的与身份验证相关的部分允许标记需要身份验证的树并可选地指定专用登录页面。 根据先前的版本，新实施允许标记需要在内容存储库中进行验证的树，并有条件地启用与的同步 Sling org.apache.sling.api.auth.Authenticator负责最终实施要求并重定向到登录资源。

这些要求通过提供 sling.auth.requirements 注册属性。 然后，这些属性用于动态扩展身份验证要求。 有关更多详细信息，请参阅 Sling文档.

用专用混合类型定义认证要求 defining-the-authentication-requirement-with-a-dedicated-mixin-type

出于安全原因，新实施将使用名为的专用混合类型替换剩余JCR属性 granite:AuthenticationRequired，为登录路径定义类型为STRING的单个可选属性 granite:loginPath. 只有与此混合类型相关的内容更改才会导致更新向Apache Sling Authenticator注册的要求。 在保留任何临时修改时会跟踪这些修改，因此需要 javax.jcr.Session.save() 呼吁生效。

这同样适用于 granite:loginPath 属性。 仅当它由与身份验证相关的mixin类型定义时，才会遵守该规则。 在非结构化JCR节点中添加具有此名称的剩余属性将不会显示所需的效果，该属性将被负责更新OSGi注册的处理程序忽略。

向Sling验证器注册验证要求和登录路径 registering-the-authentication-requirement-and-login-path-with-the-sling-authenticator

由于此类身份验证要求预计仅限于某些运行模式和内容存储库中树的一小部分，因此对要求混合类型和登录路径属性的跟踪是有条件的，并绑定到定义受支持路径的相应配置（请参阅下面的配置选项）。 因此，只有这些受支持路径范围内的更改才会触发OSGi注册的更新，在mixin类型和属性的其他位置都会被忽略。

默认的AEM设置现在允许在创作运行模式下设置mixin，以便利用此配置，但只有在复制到发布实例时才会生效。 请参阅 本页 有关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起提供的实施如下所示：

的 LoginPathProvider 由Granite中新的auth-requirement支持实施时，会公开由 granite:loginPath 属性，这些属性又由如上所述的mixin类型定义。 保存登录路径的资源路径和属性值本身的映射被保存在内存中，并且将被评估以为层次结构中的其他节点找到合适的登录路径。

最佳实践 best-practices-1

定义身份验证要求时应考虑以下最佳实践：

存储库中的表示形式 representation-in-the-repository

存储库中的CUG策略表示 cug-policy-representation-in-the-repository

Oak文档介绍了新CUG策略在存储库内容中的反映方式。 有关详细信息，请查阅 本页.

存储库中的身份验证要求 authentication-requirement-in-the-repository

对单独身份验证要求的需求反映在存储库内容中，并且目标节点处放置专用的混合节点类型。 mixin类型定义一个可选属性，用于为目标节点定义的树指定专用登录页。

与登录路径关联的页面可以位于该树内部或外部。 它将被排除在身份验证要求之外。

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

管理CUG策略和身份验证要求 managing-cug-policies-and-authentication-requirement

管理CUG策略 managing-cug-policies

用于限制CUG读取访问的新类型的访问控制策略是使用JCR访问控制管理API来管理的，并遵循 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 (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策略 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);
}

按Pincipal管理CUG策略 managing-cug-policies-by-pincipal

定义的扩展 JackrabbitAccessControlManager 允许按主体编辑访问控制策略的CUG访问控制管理未通过CUG实施，因为根据定义，CUG策略始终影响所有主体：列在 PrincipalSetPolicy 将被授予读取访问权限，而所有其他主体将被阻止读取目标节点定义的树中的内容。

相应的方法始终返回空策略数组，但不会引发异常。

管理身份验证要求 managing-the-authentication-requirement

通过改变目标节点的有效节点类型来实现新的认证要求的创建、修改或移除。 然后，可以使用常规JCR API写入可选的登录路径属性。

添加新的身份验证要求 adding-a-new-auth-requirement

创建新身份验证要求的步骤详见下文。 请注意，仅当 RequirementHandler 已为包含目标节点的树配置。

Node targetNode = [...]

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

使用登录路径添加新的身份验证要求 add-a-new-auth-requirement-with-login-path

创建新身份验证要求（包括登录路径）的步骤。 请注意，仅当 RequirementHandler 为包含目标节点的树配置了。

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 已为包含目标节点的树配置。 将从注册中删除之前的登录路径值。 与目标节点关联的身份验证要求不受此修改的影响。

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 已为包含目标节点的树配置。 与目标节点关联的身份验证要求不受影响。

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 为包含目标节点的树配置了。

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 Authenticator如何反映本文档中所述实施添加的要求。

检索有效登录路径 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授权 捆绑( org.apache.jackrabbit.oak-authorization-cug)，这是AEM默认安装的一部分。 该包定义了一个分离的授权模型，该授权模型旨在作为管理读取访问的另一种方式进行部署。

设置CUG授权 setting-up-cug-authorization

有关设置CUG授权的详情，请参阅 相关Apache文档. 默认情况下，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授权模块关联的可用配置选项的列出，请参阅 Apache Oak文档.

从CUG评估中排除承担者 excluding-principals-from-cug-evaluation

对个人负责人免予进行国别评价，原执行情况除外。 新的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支持的身份验证要求替换，某些OSGi组件必须在给定的AEM安装中存在且处于活动状态。 有关更多详细信息，请参阅 OSGi元件的特性 下。

OSGi元件的特性

引入了以下2个OSGi组件来定义身份验证要求并指定专用的登录路径：

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

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

配置选项 configuration-options-1

CUG重写的与身份验证相关的部分只附带一个与AdobeGranite身份验证要求和登录路径处理程序关联的配置选项：

"身份验证要求和登录路径处理程序"

自AEM 6.3以来的默认配置 default-configuration-since-aem

默认情况下，新安装的AEM将使用新实施来进行CUG功能的授权和身份验证相关部分。 旧的“AdobeGranite封闭用户组(CUG)支持”实施已弃用，默认情况下将在所有AEM安装中禁用。 新实施将改为启用，如下所示：

创作实例 author-instances

发布实例 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。 自版本2.11.0起 jackrabbit-api 模块定义了名为 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策略存在一个限制。 如果删除了给定的CUG策略而未删除相应的混合节点类型 rep:CugMixin, 复制时不会反映删除内容。 已通过始终在删除策略时删除mixin来解决此问题。 但是，如果手动添加混合类型，则可能会显示该限制。

AdobeGranite身份验证处理程序 adobe-granite-authentication-handler

身份验证处理程序 AdobeGranite HTTP标头身份验证处理程序 随 com.adobe.granite.auth.authhandler 包包含对的引用 CugSupport 由同一模块定义的接口。 它用于在某些情况下计算“领域”，并回退到使用处理程序配置的领域。

此参数已调整为参考 CugSupport 可选，以确保在给定设置决定重新启用已弃用的实施时，能够实现最大的向后兼容性。 使用实施的安装将不再获取从CUG实施提取的领域，但将始终显示通过定义的领域 AdobeGranite HTTP标头身份验证处理程序.

AEM LiveCopy aem-livecopy

配置CUG与LiveCopy一起使用时，会添加一个额外节点和一个额外属性，如下所示：

这两个元素均在 cq:Page. 在当前设计中，MSM仅处理位于 cq:PageContent (jcr:content)节点。

因此，无法从Blueprint将CUG组转出到Live Copy。 请在配置 Live Copy 时对此进行规划。

新CUG实施中的更改 changes-with-the-new-cug-implementation

本节旨在概述对CUG功能所做的更改，以及旧实施和新实施的比较。 它列出了影响CUG支持配置方式的更改，并描述了如何以及由谁在存储库内容中管理CUG。

CUG设置和配置中的差异 diferences-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时，需要了解一些细微的更改。

与授权有关的差异 diferences-with-regards-to-authorization

从授权角度来看，主要区别在以下列表中：

CUG的专用访问控制内容

在旧实施中，默认授权模型用于处理发布时的访问控制列表策略，通过CUG授权的设置替换任何现有ACE。 这是由编写常规的剩余JCR属性触发的，这些属性会在发布时进行解释。

在新实施中，默认授权模型的访问控制设置不会受到创建、修改或删除的任何CUG的影响。 而是新类型的策略，名为 PrincipalSetPolicy 作为附加访问控制内容应用于目标节点。 此附加策略将作为目标节点的子项找到，并且如果存在，则将作为默认策略节点的同级。

在访问控制管理中编辑CUG策略

从剩余的JCR属性移动到专用的访问控制策略会影响创建或修改CUG功能授权部分所需的权限。 由于这被视为对访问控制内容的修改，因此需要 jcr:readAccessControl 和 jcr:modifyAccessControl 权限。 因此，只有有权修改页面访问控制内容的内容作者才能设置或修改此内容。 这与旧实施形成了对比，旧实施中写入常规JCR属性的功能已足够，从而导致权限提升。

策略定义的目标节点

CUG策略应在JCR节点创建，该节点定义要受限制读取访问的子树。 如果CUG应影响整个树，则该页面可能是AEM页面。

请注意，将CUG策略仅放置在位于给定页面下方的jcr:content节点上，将仅限制对给定页面内容的访问，而不会对任何同级页面或子页面生效。 这可能是一个有效的用例，并且可以使用允许应用细粒度访问内容的存储库编辑器来实现。 但是，它与之前的实施形成了对比，在之前的实施中，将cq:cugEnabled属性放置到jcr:content节点后，会在内部将该属性重新映射到页面节点。 不再执行此映射。

使用CUG策略进行权限评估

从旧的CUG支持转移到其他授权模型，更改了评估有效读取权限的方式。 如 Jackrabbit文档，允许给定的主体查看 CUGcontent 只有在对Oak存储库中配置的所有模型进行权限评估时，才授予读取访问权限。

换言之，在评估有效权限时， CUGPolicy 并且，将考虑默认访问控制条目，并且仅在两种策略类型授予CUG内容的读取访问权限时，才授予该内容的读取权限。 在默认的AEM发布安装中，其中对完成项具有读取访问权限 /content 树会向每个人授予，CUG政策的效果将与旧实施的效果相同。

按需评估

CUG授权模型允许单独开启访问控制管理和权限评估：

在新的AEM默认设置CUG策略评估中，仅通过“发布”运行模式启用该设置。 请参阅 自AEM 6.3以来的默认配置 以了解更多详细信息。 可通过将给定路径的有效策略与存储在内容中的策略进行比较来验证这一点。 只有在启用CUG的权限评估时，才会显示有效策略。

如上所述，CUG访问控制策略现在始终存储在内容中，但只有在 已启用CUG评估 在Apache Jackrabbit Oak的系统控制台中打开 CUG配置。 默认情况下，仅通过“发布”运行模式启用此功能。

与身份验证的区别 differences-with-regards-to-authentication

与身份验证有关的差异如下所述。

用于验证要求的专用混合类型 dedicated-mixin-type-for-authentication-requirement

在前一个实现中，CUG的授权和身份验证方面都由单个JCR属性( cq:cugEnabled)。 就身份验证而言，这会生成与Apache Sling Authenticator实施一起存储的身份验证要求的更新列表。 在新的实施中，通过用专用混合类型标记目标节点( granite:AuthenticationRequired)。

用于排除登录路径的属性 property-for-excluding-login-path

mixin类型定义一个名为的可选属性 granite:loginPath，它基本上与 cq:cugLoginPage 属性。 与之前的实施相反，仅当其声明节点类型为所述mixin时，才会遵守登录路径属性。 在不设置mixin类型的情况下添加具有该名称的属性将不起作用，并且不会向验证器报告对登录路径的新要求或排除项。

身份验证要求的权限 privilege-for-authentication-requirement

添加或删除混合类型需要 jcr:nodeTypeManagement 权限。 在上一个实施中， jcr:modifyProperties 权限用于编辑剩余属性。

对于 granite:loginPath 担心添加、修改或删除资产时需要具有相同的权限。

由混合类型定义的目标节点 target-node-defined-by-mixin-type

应在JCR节点创建身份验证要求，该节点定义要强制登录的子树。 如果CUG预期会影响整个树，且用于新实施的UI随后会在页面节点上添加身份验证要求mixin类型，则这可能是AEM页面。

将CUG策略仅放置在位于给定页面下方的jcr:content节点将仅限访问内容，但不会影响页面节点本身或任何子页面。

这可能是一种有效的方案，在允许将混合内容放置到任意节点的存储库编辑器中，也可能是这种情况。 但是，这种行为与之前的实施形成了对比，在之前的实施中，将cq:cugEnabled或cq:cugLoginPage属性放置到jcr:content节点后，最终会将其内部重新映射到页面节点。 不再执行此映射。

已配置的受支持路径 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支持的组合，这可能会导致不希望的行为：

迁移现有CUG内容 migrating-existing-cug-content

Adobe提供了迁移到新CUG实施的工具。 要使用该插件，请执行以下步骤：