AEM Grupos de usuarios cerrados en el

Introducción

AEM Desde la versión 6.3, existe una nueva implementación de grupo cerrado de usuarios diseñada para abordar los problemas de rendimiento, escalabilidad y seguridad presentes en la implementación existente.

El objetivo de la nueva implementación es cubrir la funcionalidad existente donde sea necesario y, al mismo tiempo, abordar los problemas y las limitaciones de diseño de versiones anteriores. El resultado es un nuevo diseño de CUG con las siguientes características:

• una clara separación de los elementos de autenticación y autorización, que pueden utilizarse de forma individual o combinada;
• Modelo de autorización dedicado para reflejar el acceso de lectura restringido en los árboles de CUG configurados sin interferir en otros requisitos de configuración y permiso de control de acceso;
• Separación entre la configuración de control de acceso del acceso de lectura restringido, que suele ser necesario en instancias de creación, y la evaluación de permisos, que normalmente solo se desea en la publicación;
• Edición de acceso de lectura restringido sin escalación de privilegios;
• Extensión de tipo de nodo dedicada para marcar el requisito de autenticación.
• Ruta de inicio de sesión opcional asociada al requisito de autenticación.

La nueva implementación del grupo de usuarios personalizados

AEM Un CUG, tal como se le conoce en el contexto de la creación de grupos de usuarios, consta de los siguientes pasos:

• Restrinja el acceso de lectura en el árbol que necesita protegerse y permita la lectura solo para las entidades principales que estén enumeradas con una instancia de CUG determinada o excluidas por completo de la evaluación de CUG. Esto se denomina autorización Elemento.
• Haga cumplir la autenticación en un árbol determinado y, opcionalmente, especifique una página de inicio de sesión dedicada para ese árbol que se excluya posteriormente. Esto se denomina authentication Elemento.

La nueva implementación se ha diseñado para trazar una línea entre los elementos de autenticación y autorización. AEM A partir de la versión 6.3, se puede restringir el acceso de lectura sin añadir explícitamente un requisito de autenticación. Por ejemplo, si una instancia determinada requiere autenticación por completo o un árbol determinado ya reside en un subárbol que requiere autenticación.

Del mismo modo, un árbol determinado se puede marcar con un requisito de autenticación sin cambiar la configuración de permisos efectiva. Las combinaciones y los resultados se enumeran en la Combinación de políticas de CUG y el requisito de autenticación sección.

Información general

Autorización: Restricción del acceso de lectura

La función principal de un CUG es restringir el acceso de lectura a un árbol determinado del repositorio de contenido para todos excepto para las entidades de seguridad seleccionadas. En lugar de manipular el contenido de control de acceso predeterminado sobre la marcha, la nueva implementación adopta un enfoque diferente al definir un tipo dedicado de directiva de control de acceso que representa un CUG.

Política de control de acceso para CUG

Este nuevo tipo de directiva tiene las siguientes características:

• Política de control de acceso de tipo org.apache.jackrabbit.api.security.authorization.PrincipalSetPolicy (definida por la API de Apache Jackrabbit);
• PrincipalSetPolicy otorga privilegios a un conjunto modificable de principales;
• Los privilegios concedidos y el ámbito de la política son detalles de implementación.

La implementación de PrincipalSetPolicy utilizada para representar CUG además define lo siguiente:

• Las políticas de CUG solo conceden acceso de lectura a los elementos JCR normales (por ejemplo, se excluye el contenido de control de acceso).
• El ámbito se define mediante el nodo controlado de acceso que contiene la directiva CUG;
• Las políticas de CUG se pueden anidar, un CUG anidado inicia un nuevo CUG sin heredar el conjunto principal del CUG "principal".
• El efecto de la directiva, si la evaluación está habilitada, se hereda a todo el subárbol hasta el siguiente CUG anidado.

AEM Estas políticas de CUG se implementan en una instancia de a través de un módulo de autorización independiente denominado oak-authorization-cug. Este módulo incluye su propia administración de control de acceso y evaluación de permisos. AEM En otras palabras, la configuración predeterminada del repositorio de contenido incluye una configuración de Oak que combina varios mecanismos de autorización. Para obtener más información, consulte esta página contiene la documentación de Apache Oak.

AEM En esta configuración compuesta, un nuevo CUG no reemplaza el contenido de control de acceso existente adjunto al nodo de destino, sino que está diseñado para ser un complemento que también se puede eliminar más adelante sin afectar al control de acceso original, que de forma predeterminada en la lista de control de acceso sería una lista de control de acceso.

A diferencia de la implementación anterior, las nuevas políticas de CUG siempre se reconocen y tratan como contenido de control de acceso. Esto implica que se crean y editan mediante la API de administración de control de acceso JCR. Para obtener más información, consulte la Administración de políticas de CUG sección.

Evaluación de permisos de políticas de CUG

Aparte de una gestión específica del control de acceso para los CUG, el nuevo modelo de autorización permite permitir condicionalmente la evaluación de permisos para sus políticas. Esto permite configurar las políticas de CUG en un entorno de ensayo y permitir la evaluación de los permisos efectivos solo una vez duplicados en el entorno de producción.

La evaluación de permisos para políticas de CUG y la interacción con el modelo de autorización predeterminado o cualquier modelo de autorización adicional sigue el patrón diseñado para varios mecanismos de autorización en Apache Jackrabbit Oak: un conjunto determinado de permisos se concede si y solo si todos los modelos conceden acceso. Consulte esta página para obtener más información.

Las siguientes características se aplican a la evaluación de permisos asociada al modelo de autorización diseñado para gestionar y evaluar las políticas de CUG:

• Solo controla los permisos de lectura para nodos y propiedades normales, pero no lee el contenido de control de acceso
• No gestiona permisos de escritura ni ningún tipo de permisos necesarios para la modificación del contenido JCR protegido (control de acceso, información de tipo de nodo, versiones, bloqueo o administración de usuarios, entre otros); Estos permisos no se ven afectados por una política de CUG y no serán evaluados por el modelo de autorización asociado. La concesión o no de estos permisos depende de los otros modelos configurados en la configuración de seguridad.

El efecto de una única política de CUG sobre la evaluación de permisos se puede resumir de la siguiente manera:

• Se deniega el acceso de lectura a todas las personas, excepto a los sujetos que contienen entidades principales excluidas o entidades principales enumeradas en la directiva.
• La directiva tiene efecto en el nodo controlado de acceso que contiene la directiva y sus propiedades;
• El efecto se hereda adicionalmente en la jerarquía, es decir, el árbol de elementos definido por el nodo controlado de acceso;
• Sin embargo, no afecta a los hermanos ni a los antecesores del nodo controlado de acceso;
• La herencia de un CUG determinado se detiene en un CUG anidado.

Prácticas recomendadas

Se deben tener en cuenta las siguientes prácticas recomendadas para definir el acceso de lectura restringido a través de CUG:

• Tome una decisión consciente sobre si su necesidad de un CUG se trata de restringir el acceso de lectura o de un requisito de autenticación. En caso de esto último o si hay necesidad de ambos, consulte la sección sobre Prácticas recomendadas para obtener más información sobre el requisito de autenticación

• Cree un modelo de amenazas para los datos o el contenido que debe protegerse para identificar los límites de las amenazas y tener una idea clara de la confidencialidad de los datos y las funciones asociadas con el acceso autorizado

• Modele el contenido del repositorio y los CUG teniendo en cuenta los aspectos y las prácticas recomendadas generales relacionados con la autorización:

  • Recuerde que el permiso de lectura solo se concederá si un CUG determinado y la evaluación de otros módulos implementados en la concesión de configuración permiten que un sujeto determinado lea un elemento de repositorio determinado
  • Evite crear CUG redundantes en los que el acceso de lectura ya está restringido por otros módulos de autorización
  • La necesidad excesiva de CUG anidados puede resaltar problemas en el diseño de contenido
  • Una necesidad muy excesiva de CUG (por ejemplo, en cada página) puede indicar la necesidad de un modelo de autorización personalizado potencialmente más adecuado para satisfacer las necesidades de seguridad específicas de la aplicación y el contenido en cuestión.

• Limite las rutas admitidas para las políticas de CUG a unos pocos árboles en el repositorio para permitir un rendimiento optimizado. AEM Por ejemplo, solo permite CUG debajo del nodo /content como enviado como valor predeterminado desde 6.3.

• Las políticas de CUG están diseñadas para conceder acceso de lectura a un pequeño conjunto de principales. La necesidad de un gran número de principios puede resaltar problemas en el diseño del contenido o la aplicación y debe reconsiderarse.

Autenticación: Definición del requisito de autenticación

Las partes relacionadas con la autenticación de la función CUG permiten marcar árboles que requieran autenticación y, opcionalmente, especificar una página de inicio de sesión dedicada. De acuerdo con la versión anterior, la nueva implementación permite marcar árboles que requieran autenticación en el repositorio de contenido y habilitar condicionalmente la sincronización con Sling org.apache.sling.api.auth.Authenticatorresponsable de aplicar finalmente el requisito y redirigir a un recurso de inicio de sesión.

Estos requisitos se registran con el autenticador mediante un servicio OSGi que proporciona el sling.auth.requirements propiedad de registro. A continuación, estas propiedades se utilizan para ampliar dinámicamente los requisitos de autenticación. Para obtener más información, consulte la Documentación de Sling.

Definición del requisito de autenticación con un tipo de mezcla dedicado

Por motivos de seguridad, la nueva implementación reemplaza el uso de una propiedad JCR residual por un tipo de mezcla dedicado denominado granite:AuthenticationRequired, que define una única propiedad opcional de tipo CADENA para la ruta de inicio de sesión granite:loginPath. Solo los cambios de contenido relacionados con este tipo de mezcla llevarán a una actualización de los requisitos registrados con Apache Sling Authenticator. Las modificaciones se rastrean al mantener cualquier modificación transitoria y, por lo tanto, requieren una javax.jcr.Session.save() llame a para que sea efectivo.

Lo mismo se aplica al granite:loginPath propiedad. Solo se respetará si está definido por el tipo de mezcla relacionado con el requisito de autenticación. Si se agrega una propiedad residual con este mismo nombre en un nodo JCR no estructurado, no se mostrará el efecto deseado y el controlador responsable de actualizar el registro OSGi ignorará la propiedad.

Registro del requisito de autenticación y la ruta de inicio de sesión con el autenticador de Sling

Dado que se espera que este tipo de requisito de autenticación se limite a ciertos modos de ejecución y a un pequeño subconjunto de árboles dentro del repositorio de contenido, el seguimiento del tipo de mezcla de requisito y las propiedades de la ruta de inicio de sesión es condicional y está enlazado a una configuración correspondiente que define las rutas admitidas (consulte Opciones de configuración a continuación). Por consiguiente, solo los cambios dentro del ámbito de estas rutas admitidas almacenarán en déclencheur una actualización del registro OSGi, en cualquier otro lugar se omitirán tanto el tipo de mezcla como la propiedad.

AEM La configuración predeterminada de la ahora utiliza esta configuración para permitir establecer la mezcla en el modo de ejecución de autor, pero solo hacer que tenga efecto tras la replicación en la instancia de publicación. Consulte esta página para obtener más información sobre cómo Sling aplica el requisito de autenticación.

Añadir el granite:AuthenticationRequired El tipo de mezcla dentro de las rutas admitidas configuradas hará que el registro OSGi del controlador responsable se actualice y contenga una entrada nueva y adicional con el sling.auth.requirements propiedad. Si un requisito de autenticación determinado especifica lo opcional granite:loginPath , el valor se registra adicionalmente con el autenticador con un prefijo "-" para que se excluya del requisito de autenticación.

Evaluación y herencia del requisito de autenticación

Se espera que los requisitos de autenticación de Apache Sling se hereden a través de la jerarquía de páginas o nodos. Los detalles mismos de la herencia y la evaluación de los requisitos de autenticación, como el orden y la prioridad, se consideran un detalle de implementación y no se documentarán en este artículo.

Evaluación de la ruta de inicio de sesión

La evaluación de la ruta de inicio de sesión y el redireccionamiento al recurso correspondiente tras la autenticación es actualmente un detalle de implementación del Controlador de autenticación del selector de inicio de sesión de Granite de Adobe ( com.day.cq.auth.impl.LoginSelectorHandlerAEM ), que es un controlador de autenticación de Apache Sling configurado con la opción de autenticación de forma predeterminada.

Al llamar AuthenticationHandler.requestCredentials este controlador intenta determinar la página de inicio de sesión de asignación a la que se redirigirá al usuario. Esto incluye los siguientes pasos:

• Distinguir entre contraseña caducada y necesidad de inicio de sesión regular como motivo para la redirección;

• En el caso de un inicio de sesión normal, comprueba si una ruta de inicio de sesión se puede obtener en el siguiente orden:

  • desde LoginPathProvider tal como lo implementa el nuevo com.adobe.granite.auth.requirement.impl.RequirementService,
  • de la implementación antigua y obsoleta de CUG,
  • de las Asignaciones de páginas de inicio de sesión, tal como se definen con la variable LoginSelectorHandler,
  • y, por último, vuelva a la página de inicio de sesión predeterminada, tal como se define en la variable LoginSelectorHandler.

• Tan pronto como se obtenga una ruta de inicio de sesión válida a través de las llamadas enumeradas anteriormente, la solicitud del usuario se redirigirá a esa página.

El objetivo de esta documentación es la evaluación de la ruta de inicio de sesión expuesta por el LoginPathProvider interfaz. AEM La implementación enviada desde la versión 6.3 se comporta de la siguiente manera:

• El registro de las rutas de inicio de sesión depende de la distinción entre la contraseña caducada y la necesidad de iniciar sesión de forma regular como motivo para la redirección

• En el caso del inicio de sesión normal, comprueba si una ruta de inicio de sesión se puede obtener en el siguiente orden:

  • desde el LoginPathProvider según lo implementado por el nuevo com.adobe.granite.auth.requirement.impl.RequirementService,
  • de la implementación antigua y obsoleta de CUG,
  • de las Asignaciones de página de inicio de sesión tal como se definen con la variable LoginSelectorHandler,
  • y, finalmente, volver a la página de inicio de sesión predeterminada, tal como se define en la LoginSelectorHandler.

• Tan pronto como se obtenga una ruta de inicio de sesión válida a través de las llamadas enumeradas anteriormente, la solicitud del usuario se redirigirá a esa página.

El LoginPathProvider según se haya implementado mediante la nueva compatibilidad con requisitos de autenticación en Granite, expone las rutas de inicio de sesión tal como se definen en granite:loginPath propiedades, que a su vez se definen mediante el tipo de mezcla como se ha descrito anteriormente. La asignación de la ruta de recurso que contiene la ruta de inicio de sesión y el propio valor de propiedad se mantiene en memoria y se evalúa para encontrar una ruta de inicio de sesión adecuada para otros nodos de la jerarquía.

Prácticas recomendadas

Se deben tener en cuenta las siguientes prácticas recomendadas al definir los requisitos de autenticación:

• Evite anidar requisitos de autenticación: colocar un solo marcador de requisito de autenticación al principio de un árbol debe ser suficiente y se hereda a todo el subárbol definido por el nodo de destino. Los requisitos de autenticación adicionales dentro de ese árbol deben considerarse redundantes y pueden provocar problemas de rendimiento al evaluar el requisito de autenticación dentro de Apache Sling. Con la separación de las áreas de CUG relacionadas con la autorización y la autenticación, es posible restringir el acceso de lectura mediante CUG u otro tipo de políticas, al mismo tiempo que se aplica la autenticación para todo el árbol.

• Contenido del repositorio de modelo tal que los requisitos de autenticación se apliquen a todo el árbol sin necesidad de excluir de nuevo los subárboles anidados del requisito.

• Para evitar especificar y, posteriormente, registrar rutas de inicio de sesión redundantes:

  • basarse en la herencia y evitar definir rutas de inicio de sesión anidadas,
  • no establezca la ruta de inicio de sesión opcional en un valor que corresponda al valor predeterminado o heredado,
  • los desarrolladores de aplicaciones deben identificar qué rutas de inicio de sesión deben configurarse en las configuraciones globales de ruta de inicio de sesión (tanto predeterminadas como de asignaciones) asociadas con LoginSelectorHandler.

Representación en el repositorio

Representación de la directiva CUG en el repositorio

La documentación de Oak cubre cómo se reflejan las nuevas políticas de CUG en el contenido del repositorio. Para obtener más información, consulte esta página.

Requisito de autenticación en el repositorio

La necesidad de un requisito de autenticación independiente se refleja en el contenido del repositorio con un tipo de nodo de mezcla dedicado ubicado en el nodo de destino. El tipo de mezcla define una propiedad opcional para especificar una página de inicio de sesión dedicada para el árbol definido por el nodo de destino.

La página asociada con la ruta de inicio de sesión puede encontrarse dentro o fuera de ese árbol. Se excluirá del requisito de autenticación.

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

Administración de directivas de CUG y requisito de autenticación

Administración de políticas de CUG

El nuevo tipo de políticas de control de acceso para restringir el acceso de lectura para un CUG se administra mediante la API de administración de control de acceso JCR y sigue los mecanismos descritos con la variable Especificación JCR 2.0.

Establecer una nueva directiva CUG

Código para aplicar una nueva política de CUG en un nodo que no tenía un CUG establecido anteriormente. Tenga en cuenta que getApplicablePolicies solo devolverá nuevas directivas que no se hayan establecido antes. Al final, la política debe volver a escribirse y los cambios deben persistir.

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

Editar una política de CUG existente

Se necesitan los siguientes pasos para editar una política de CUG existente. Tenga en cuenta que la directiva modificada debe volver a escribirse y que los cambios deben persistir usando 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");
}

Recuperar políticas de CUG efectivas

La administración de control de acceso JCR define un método de mejor esfuerzo para recuperar las políticas que surten efecto en una ruta determinada. Debido a que la evaluación de las políticas de CUG es condicional y depende de la configuración correspondiente para habilitarse, llame a getEffectivePolicies es una forma cómoda de comprobar si una directiva CUG determinada está surtiendo efecto en una instalación determinada.

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

Recuperar políticas de CUG heredadas

Búsqueda de todos los CUG anidados que se han definido en una ruta determinada, independientemente de si tienen efecto o no. Para obtener más información, consulte la Opciones de configuración sección.

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

Administración de directivas de CUG por entidad principal

Las extensiones definidas por JackrabbitAccessControlManager que permiten editar directivas de control de acceso por principal no se implementan con la administración de control de acceso de CUG, ya que por definición una directiva de CUG siempre afecta a todas las principales: las enumeradas con la variable PrincipalSetPolicy se les concede acceso de lectura, mientras que a todos los demás principales se les impedirá leer el contenido en el árbol definido por el nodo de destino.

Los métodos correspondientes siempre devuelven una matriz de directivas vacía, pero no producen excepciones.

Administración del requisito de autenticación

La creación, modificación o eliminación de un nuevo requisito de autenticación se logra cambiando el tipo de nodo efectivo del nodo de destino. La propiedad de ruta de inicio de sesión opcional se puede escribir utilizando la API JCR normal.

Adición de un nuevo requisito de autenticación

A continuación se detallan los pasos para crear un nuevo requisito de autenticación. Tenga en cuenta que el requisito solo se registrará con el autenticador de Apache Sling si RequirementHandler se ha configurado para el árbol que contiene el nodo de destino.

Node targetNode = [...]

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

Agregar nuevo requisito de autenticación con ruta de inicio de sesión

Pasos para crear un nuevo requisito de autenticación que incluya una ruta de inicio de sesión. Tenga en cuenta que el requisito y la exclusión de la ruta de inicio de sesión solo se registrarán con el autenticador de Apache Sling si la variable RequirementHandler se ha configurado para el árbol que contiene el nodo de destino.

Node targetNode = [...]
String loginPath = [...] // STRING property

Node targetNode = session.getNode(path);
targetNode.addMixin("granite:AuthenticationRequired");

targetNode.setProperty("granite:loginPath", loginPath);
session.save();

Modificar una ruta de inicio de sesión existente

A continuación se detallan los pasos para cambiar una ruta de inicio de sesión existente. La modificación solo se registrará con el autenticador de Apache Sling si RequirementHandler se ha configurado para el árbol que contiene el nodo de destino. El valor anterior de la ruta de inicio de sesión se eliminará del registro. El requisito de autenticación asociado al nodo de destino no se ve afectado por esta modificación.

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");
}

Eliminar una ruta de inicio de sesión existente

Pasos para eliminar una ruta de inicio de sesión existente. La entrada de ruta de inicio de sesión solo se anulará del registro del autenticador de Apache Sling si RequirementHandler se ha configurado para el árbol que contiene el nodo de destino. El requisito de autenticación asociado con el nodo de destino no se ve afectado.

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");
}

O bien, puede utilizar el siguiente método para lograr el mismo propósito:

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

Eliminar un requisito de autenticación

Pasos para eliminar un requisito de autenticación existente. El requisito solo se anulará del registro del autenticador de Apache Sling si RequirementHandler se ha configurado para el árbol que contiene el nodo de destino.

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

session.save();

Recuperar requisitos de autenticación efectivos

No hay ninguna API pública dedicada para leer todos los requisitos de autenticación efectivos registrados con el autenticador de Apache Sling. Sin embargo, la lista se expone en la consola del sistema en https://<serveraddress>:<serverport>/system/console/slingauth en la sección "Configuración del requisito de autenticación" sección.

AEM La siguiente imagen muestra los requisitos de autenticación de una instancia de publicación de la con contenido de demostración. La ruta resaltada de la página de la comunidad ilustra cómo se refleja un requisito agregado por la implementación descrita en este documento en el autenticador de Apache Sling.

Recuperación de la ruta de inicio de sesión efectiva

Actualmente no hay ninguna API pública para recuperar la ruta de inicio de sesión que surtirá efecto al acceder de forma anónima a un recurso que requiera autenticación. Consulte la sección Evaluación de la ruta de inicio de sesión para obtener detalles de implementación sobre cómo se recupera la ruta de inicio de sesión.

AEM Sin embargo, tenga en cuenta que, aparte de las rutas de inicio de sesión definidas con esta función, hay formas alternativas de especificar la redirección al inicio de sesión, que deben tenerse en cuenta al diseñar el modelo de contenido y los requisitos de autenticación de una instalación de determinada.

Recuperar el requisito de autenticación heredado

Al igual que con la ruta de inicio de sesión, no hay ninguna API pública para recuperar los requisitos de autenticación heredados definidos en el contenido. El siguiente ejemplo ilustra cómo enumerar todos los requisitos de autenticación que se han definido con una jerarquía determinada, independientemente de si surten efecto o no. Para obtener más información, consulte Opciones de configuración.

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

Combinación de políticas de CUG y el requisito de autenticación

AEM En la tabla siguiente se enumeran las combinaciones válidas de directivas CUG y el requisito de autenticación en una instancia de CUG que tiene ambos módulos habilitados mediante configuración.

Se requiere autenticación	Ruta de inicio de sesión	Acceso de lectura restringido	Efecto esperado
Sí	Sí	Sí	Un usuario determinado solo podrá ver el subárbol marcado con la directiva CUG si la evaluación efectiva de permisos concede acceso. Se redirigirá a un usuario no autenticado a la página de inicio de sesión especificada.
Sí	No	Sí	Un usuario determinado solo podrá ver el subárbol marcado con la directiva CUG si la evaluación efectiva de permisos concede acceso. Se redirigirá a un usuario no autenticado a una página de inicio de sesión predeterminada heredada.
Sí	Sí	No	Se redirigirá a un usuario no autenticado a la página de inicio de sesión especificada. El hecho de que se permita o no ver el árbol marcado con el requisito de autenticación depende de los permisos efectivos de los elementos individuales contenidos en ese subárbol. No hay ningún CUG dedicado que restrinja el acceso de lectura.
Sí	No	No	Se redirigirá a un usuario no autenticado a una página de inicio de sesión predeterminada heredada. El hecho de que se permita o no ver el árbol marcado con el requisito de autenticación depende de los permisos efectivos de los elementos individuales contenidos en ese subárbol. No hay ningún CUG dedicado que restrinja el acceso de lectura.
No	No	Sí	Un usuario autenticado o no autenticado determinado solo podrá ver el subárbol marcado con la directiva CUG si la evaluación de permisos efectiva concede acceso. Un usuario no autenticado recibirá el mismo trato y no se le redirigirá al inicio de sesión.

Componentes y configuración de OSGi

Esta sección proporciona información general sobre los componentes de OSGi y las opciones de configuración individuales introducidas con la nueva implementación de CUG.

Consulte también la documentación de asignación de CUG para una asignación completa de las opciones de configuración entre la implementación antigua y la nueva.

Autorización: instalación y configuración

Las nuevas partes relacionadas con la autorización se incluyen en el Autorización de Oak CUG paquete ( org.apache.jackrabbit.oak-authorization-cugAEM ), que forma parte de la instalación predeterminada de la. El paquete define un modelo de autorización separado que se va a implementar como una forma adicional de administrar el acceso de lectura.

Configuración de la autorización de CUG

La configuración de la autorización de CUG se describe en detalle en la Documentación de Apache relevante. AEM De forma predeterminada, la autorización de CUG se ha implementado en todos los modos de ejecución de la. Las instrucciones paso a paso también pueden utilizarse para desactivar la autorización de CUG en aquellas instalaciones que requieran una configuración de autorización diferente.

Configuración del filtro de referente

También debe configurar la variable Filtro de referente de Sling AEM con todos los nombres de host que se pueden utilizar para acceder a los datos; por ejemplo, a través de CDN, Equilibrador de carga y cualquier otro.

Si el filtro de referente no está configurado, se observan errores, similares a los siguientes, cuando un usuario intenta iniciar sesión en un sitio de 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

Características de los componentes OSGi

Se han introducido los dos componentes OSGi siguientes para definir los requisitos de autenticación y especificar las rutas de inicio de sesión dedicadas:

• 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

Etiqueta	Configuración de Apache Jackrabbit Oak CUG
Descripción	Configuración de autorización específica para configurar y evaluar permisos de CUG.
Propiedades de configuración	cugSupportedPaths cugEnabled configurationRanking Consulte también Opciones de configuración más abajo.
Directiva de configuración	ConfigurationPolicy.REQUIRE
Referencias	CugExclude (ReferenceCardinality.OPTIONAL_UNARY)

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

Etiqueta	Lista de exclusión de Apache Jackrabbit Oak CUG
Descripción	Permite excluir de la evaluación de CUG las entidades de seguridad con los nombres configurados.
Propiedades de configuración	principalNames Consulte también la sección Opciones de configuración a continuación.
Directiva de configuración	ConfigurationPolicy.REQUIRE
Referencias	ND

Opciones de configuración

Las opciones de configuración clave son:

• cugSupportedPaths: especifique los subárboles que pueden contener CUG. No se ha establecido ningún valor predeterminado
• cugEnabled: opción de configuración para habilitar la evaluación de permisos para las políticas de CUG actuales.

Las opciones de configuración disponibles asociadas con el módulo de autorización de CUG se enumeran y describen de forma más detallada en la Documentación de Apache Oak.

Exclusión de identidades de la evaluación CUG

Se ha excluido a los responsables individuales de la evaluación de los grupos de usuarios compartidos de la aplicación anterior. La nueva autorización de CUG cubre esto con una interfaz dedicada llamada CugExclude. Apache Jackrabbit Oak 1.4 se distribuye con una implementación predeterminada que excluye un conjunto fijo de principales, así como una implementación extendida que permite configurar nombres principales individuales. AEM Esto último se configura en instancias de publicación de la publicación de la.

AEM El valor predeterminado desde la versión 6.3 de evita que las siguientes entidades de seguridad se vean afectadas por las políticas de CUG:

• principales administrativos (usuario administrador, grupo de administradores)
• principales de usuario de servicio
• principal del sistema interno del repositorio

Para obtener más información, consulte la tabla de AEM Configuración predeterminada desde la versión 6.3 de más abajo.

La exclusión del grupo "administradores" se puede modificar o expandir en la consola del sistema en la sección de configuración de Lista de exclusión de Apache Jackrabbit Oak CUG.

Como alternativa, es posible proporcionar e implementar una implementación personalizada de la interfaz CugExclude para ajustar el conjunto de principales excluidos en caso de necesidades especiales. Consulte la documentación sobre Capacidad de conexión de CUG para obtener más información y un ejemplo de implementación.

Autenticación: instalación y configuración

Las partes nuevas relacionadas con la autenticación se encuentran en Controlador de autenticación de Adobe Granite paquete ( com.adobe.granite.auth.authhandler versión 5.6.48). AEM Este paquete forma parte de la instalación predeterminada de la.

AEM Para configurar el reemplazo del requisito de autenticación para la compatibilidad con CUG obsoleta, algunos componentes OSGi deben estar presentes y activos en una instalación de determinada. Para obtener más información, consulte Características de los componentes OSGi más abajo.

Características de los componentes OSGi

Se han introducido los dos componentes OSGi siguientes para definir los requisitos de autenticación y especificar rutas de inicio de sesión dedicadas:

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

com.adobe.granite.auth.requirements.impl.RequirementService

Etiqueta	-
Descripción	Servicio OSGi dedicado para los requisitos de autenticación que registra a un observador para los cambios de contenido que afectan al requisito de autenticación (a través del granite:AuthenticationRequirement tipo de mezcla) y las rutas de inicio de sesión con están expuestas al LoginSelectorHandler.
Propiedades de configuración	-
Directiva de configuración	ConfigurationPolicy.OPTIONAL
Referencias	RequirementHandler (ReferenceCardinality.MANDATORY_UNARY) Executor (ReferenceCardinality.MANDATORY_UNARY)

com.adobe.granite.auth.required.impl.DefaultRequirementHandler

Etiqueta	Requisito de autenticación de Adobe Granite y controlador de ruta de inicio de sesión
Descripción	RequirementHandler implementación que actualiza los requisitos de autenticación de Apache Sling y la exclusión correspondiente para las rutas de inicio de sesión asociadas.
Propiedades de configuración	supportedPaths
Directiva de configuración	ConfigurationPolicy.REQUIRE
Referencias	ND

Opciones de configuración

Las partes relacionadas con la autenticación de la reescritura de CUG solo incluyen una única opción de configuración asociada al requisito de autenticación de Adobe Granite y al controlador de ruta de inicio de sesión:

"Requisito de autenticación y controlador de ruta de inicio de sesión"

Propiedad	Tipo	Valor predeterminado	Descripción
Label = Rutas admitidas Nombre = 'supportedPaths'	Establecer<string>	-	Rutas en las que este controlador respetará los requisitos de autenticación. Deje esta configuración sin configurar si desea agregar el granite:AuthenticationRequirement tipo de mezcla en nodos sin que se apliquen (por ejemplo, en instancias de autor). Si falta, la función está desactivada.

AEM Configuración predeterminada desde la versión 6.3 de

AEM De forma predeterminada, las nuevas instalaciones de la función CUG utilizarán las nuevas implementaciones tanto para las partes relacionadas con la autorización como con la autenticación. La antigua implementación "Compatibilidad con grupos cerrados de usuarios (CUG) de Adobe AEM Granite" ha quedado obsoleta y, por defecto, se desactivará en todas las instalaciones de la. Las nuevas implementaciones se habilitarán de la siguiente manera:

Instancias de autor

"Configuración de Apache Jackrabbit Oak CUG"	Explicación
Rutas admitidas /content	La administración de control de acceso para directivas CUG está habilitada.
Evaluación de CUG habilitada FALSE	La evaluación de permisos está deshabilitada. Las políticas de CUG no surten efecto.
Clasificación	200

Instancias de publicación

"Configuración de Apache Jackrabbit Oak CUG"	Explicación
Rutas admitidas /content	La administración del control de acceso para las políticas de CUG está habilitada debajo de las rutas configuradas.
Evaluación de CUG habilitada VERDADERO	La evaluación de permisos está habilitada debajo de las rutas configuradas. Las políticas de CUG surten efecto en Session.save().
Clasificación	200

"Lista de exclusión de Apache Jackrabbit Oak CUG"	Explicación
Administradores de nombres principales	Excluye al administrador principal de la evaluación de CUG.

"Requisito de autenticación de Adobe Granite y controlador de ruta de inicio de sesión"	Explicación
Rutas admitidas /content	Requisitos de autenticación definidos en el repositorio mediante el granite:AuthenticationRequired el tipo de mezcla surte efecto a continuación /content tras Session.save(). Sling Authenticator se actualiza. Se omite la adición del tipo de mezcla fuera de las rutas admitidas.

Desactivación de la autorización de CUG y el requisito de autenticación

La nueva implementación puede desactivarse por completo en caso de que una instalación determinada no utilice CUG o utilice medios diferentes para la autenticación y la autorización.

Deshabilitar autorización de CUG

Consulte la Capacidad de conexión de CUG documentación para obtener más información sobre cómo eliminar el modelo de autorización de CUG de la configuración de autorización compuesta.

Desactivar el requisito de autenticación

Para deshabilitar la compatibilidad con el requisito de autenticación proporcionado por el granite.auth.authhandler módulo, es suficiente con quitar la configuración asociada a Requisito de autenticación de Adobe Granite y controlador de ruta de inicio de sesión.

Interacción con otros módulos

API de Apache Jackrabbit

Para reflejar el nuevo tipo de política de control de acceso utilizada por el modelo de autorización de CUG, se ha ampliado la API definida por Apache Jackrabbit. Desde la versión 2.11.0 de jackrabbit-api El módulo define una nueva interfaz llamada org.apache.jackrabbit.api.security.authorization.PrincipalSetPolicy, que se extiende desde javax.jcr.security.AccessControlPolicy.

Apache Jackrabbit FileVault

El mecanismo de importación de Apache Jackrabbit FileVault se ha ajustado para hacer frente a las políticas de control de acceso de tipo PrincipalSetPolicy.

Distribución de contenido de Apache Sling

Consulte lo anterior Apache Jackrabbit FileVault sección.

Adobe de replicación de Granite

AEM El módulo de replicación se ha ajustado ligeramente para poder replicar las políticas de CUG entre diferentes instancias de:

• DurboImportConfiguration.isImportAcl() se interpreta literalmente y solo afectará a las políticas de control de acceso que implementen javax.jcr.security.AccessControlList

• DurboImportTransformer solo respetará esta configuración para ACL verdaderas

• Otras políticas, como org.apache.jackrabbit.api.security.authorization.PrincipalSetPolicy las instancias creadas por el modelo de autorización de CUG siempre se replicarán y la opción de configuración DurboImportConfiguration.isImportAcl() se omitirá.

Hay una limitación en la replicación de políticas de CUG. Si se elimina una política de CUG determinada sin eliminar el tipo de nodo de mezcla correspondiente rep:CugMixin, la eliminación no se reflejará en la replicación. Esto se ha solucionado eliminando siempre el mixin tras la eliminación de la política. No obstante, la limitación puede aparecer si se añade manualmente el tipo de mezcla.

Controlador de autenticación de Adobe Granite

El controlador de autenticación Controlador de autenticación de encabezado HTTP de Adobe Granite enviado con el com.adobe.granite.auth.authhandler el paquete contiene una referencia a CugSupport interfaz definida por el mismo módulo. Se utiliza para calcular el "dominio kerberos" en determinadas circunstancias, regresando al dominio configurado con el controlador.

Esto se ha ajustado para hacer referencia a CugSupport opcional para garantizar la máxima compatibilidad con versiones anteriores si una configuración determinada decide volver a habilitar la implementación obsoleta. Las instalaciones que utilicen la implementación ya no obtendrán el dominio extraído de la implementación de CUG, pero siempre mostrarán el dominio tal como se define con Controlador de autenticación de encabezado HTTP de Adobe Granite.

AEM LiveCopy

La configuración de CUG junto con LiveCopy se representa en el repositorio mediante la adición de un nodo adicional y una propiedad adicional de la siguiente manera:

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

Ambos elementos se crean en la variable cq:Page. Con el diseño actual, MSM solo gestiona los nodos y las propiedades que se encuentran en cq:PageContent (jcr:content) nodo.

Por lo tanto, los grupos de CUG no se pueden desplegar en Live Copies desde modelos. Tenga en cuenta esto al configurar Live Copy.

Cambios con la nueva implementación de CUG

El objetivo de esta sección es proporcionar una visión general de los cambios realizados en la función CUG, así como una comparación entre la implementación antigua y la nueva. Enumera los cambios que afectan a la forma en que se configura la compatibilidad con CUG y describe cómo y por quién se administran los CUG en el contenido del repositorio.

Diferencias en la configuración y configuración de CUG

El componente OSGi obsoleto Soporte de Adobe Granite Closed User Group (CUG) ( com.day.cq.auth.impl.cug.CugSupportImpl) se ha sustituido por nuevos componentes para poder gestionar por separado las partes relacionadas con la autorización y la autenticación de la antigua funcionalidad de CUG.

Diferencias en la gestión de CUG en el contenido del repositorio

Las secciones siguientes describen las diferencias entre las implementaciones antiguas y nuevas desde el punto de vista de la implementación y la seguridad. Aunque la nueva implementación pretende proporcionar la misma funcionalidad, hay cambios sutiles que son importantes conocer al utilizar el nuevo CUG.

Diferencias Con Respecto A La Autorización

Las principales diferencias desde el punto de vista de la autorización se resumen en la lista siguiente:

Contenido de control de acceso dedicado para CUG

En la implementación antigua, el modelo de autorización predeterminado se utilizaba para manipular las políticas de lista de control de acceso en la publicación, sustituyendo cualquier ACE existente por la configuración establecida por el CUG. Esto se activó escribiendo propiedades JCR residuales normales que se interpretaron al publicar.

Con la nueva implementación, la configuración de control de acceso del modelo de autorización predeterminado no se ve afectada por la creación, modificación o eliminación de ningún CUG. En su lugar, se llama a un nuevo tipo de directiva PrincipalSetPolicy se aplica como contenido de control de acceso adicional al nodo de destino. Esta directiva adicional se ubicará como un elemento secundario del nodo de destino y sería secundario del nodo de directiva predeterminado si está presente.

Edición de directivas de CUG en la administración de control de acceso

Este cambio de las propiedades JCR residuales a una política de control de acceso dedicada afecta al permiso necesario para crear o modificar la parte de autorización de la función CUG. Dado que esto se considera una modificación del contenido de control de acceso, requiere lo siguiente jcr:readAccessControl y jcr:modifyAccessControl privilegios para que se escriban en el repositorio. Por lo tanto, solo los autores de contenido con derecho a modificar el contenido de control de acceso de una página pueden configurar o modificar este contenido. Esto contrasta con la implementación antigua, en la que la capacidad para escribir propiedades JCR normales era suficiente, lo que daba como resultado una escalación de privilegios.

Nodo De Destino Definido Por La Directiva

Se espera que las políticas de CUG se creen en el nodo JCR que define el subárbol que estará sujeto a acceso de lectura restringido. AEM Es probable que esta sea una página de en caso de que se espere que el CUG afecte a todo el árbol.

Tenga en cuenta que colocar la directiva CUG solo en el nodo jcr:content ubicado debajo de una página determinada solo restringirá el acceso al contenido s.str de una página determinada, pero no surtirá efecto en ninguna página del mismo nivel o secundaria. Este puede ser un caso de uso válido y se puede lograr con un editor de repositorios que permita aplicar contenido de acceso de grano fino. Sin embargo, contrasta con la implementación anterior, en la que al colocar una propiedad cq:cugEnabled en el nodo jcr:content se reasignaba internamente al nodo de la página. Esta asignación ya no se realiza.

Evaluación de permisos con políticas de CUG

Al pasar de la antigua compatibilidad con CUG a un modelo de autorización adicional, cambia la forma en que se evalúan los permisos de lectura efectivos. Como se describe en la Documentación de Jackrabbit, una entidad de seguridad determinada que puede ver el CUGcontent solo se concederá acceso de lectura si la evaluación de permisos de todos los modelos configurados en el repositorio de Oak concede acceso de lectura.

En otras palabras, para la evaluación de los permisos efectivos, tanto la CUGPolicy y se tendrán en cuenta las entradas de control de acceso predeterminadas, y el acceso de lectura al contenido de CUG solo se concederá si lo conceden ambos tipos de directivas. AEM En una instalación predeterminada de publicación en la que el acceso de lectura a la /content El árbol se concede a todos, el efecto de las políticas de CUG será el mismo que con la implementación antigua.

Evaluación a petición

El modelo de autorización de CUG permite activar individualmente la gestión del control de acceso y la evaluación de permisos:

• la administración del control de acceso está habilitada si el módulo tiene una o varias rutas admitidas en las que se pueden crear CUG
• la evaluación de permisos solo está habilitada si la opción Evaluación de CUG habilitada está marcado adicionalmente.

AEM En la nueva evaluación de configuración predeterminada de la configuración de la nueva configuración de la configuración de CUG, solo se activa con el modo de ejecución "publicar". Consulte los detalles en la AEM Configuración predeterminada desde la versión 6.3 de para obtener más información. Esto se puede comprobar comparando las políticas efectivas para una ruta determinada con las políticas almacenadas en el contenido. Las políticas efectivas solo se mostrarán en caso de que la evaluación de permisos para CUG esté habilitada.

Como se ha explicado anteriormente, las políticas de control de acceso de CUG ahora siempre se almacenan en el contenido, pero la evaluación de los permisos efectivos que resultan de esas políticas solo se aplicará si Evaluación de CUG habilitada se activa en la consola del sistema en Apache Jackrabbit Oak Configuración de CUG. De forma predeterminada, solo está habilitado con el modo de ejecución "publicar".

Diferencias Con Respecto A La Autenticación

A continuación se describen las diferencias con respecto a la autenticación.

Tipo De Mixin Dedicado Para El Requisito De Autenticación

En la implementación anterior, los aspectos de autorización y autenticación de un CUG se activaban mediante una sola propiedad JCR ( cq:cugEnabled). Por lo que respecta a la autenticación, esto dio como resultado una lista actualizada de los requisitos de autenticación almacenados con la implementación de Apache Sling Authenticator. Con la nueva implementación se logra el mismo resultado marcando el nodo de destino con un tipo de mezcla dedicado ( granite:AuthenticationRequired).

Propiedad Para Excluir Ruta De Acceso

El tipo de mezcla define una sola propiedad opcional llamada granite:loginPath, que básicamente corresponde a la cq:cugLoginPage propiedad. A diferencia de la implementación anterior, la propiedad de ruta de inicio de sesión solo se respetará si su tipo de nodo de declaración es el mixin mencionado. Añadir una propiedad con ese nombre sin establecer el tipo de mezcla no tendrá ningún efecto y no se informará al autenticador de ningún requisito nuevo ni de ninguna exclusión de la ruta de inicio de sesión.

Privilegio Para Requisito De Autenticación

Añadir o eliminar un tipo de mezcla requiere lo siguiente jcr:nodeTypeManagement privilegio que se concede. En la implementación anterior, la variable jcr:modifyProperties se utiliza para editar la propiedad residual.

En cuanto a la granite:loginPath En este caso, se requiere el mismo privilegio para añadir, modificar o eliminar la propiedad.

Nodo De Destino Definido Por Tipo De Mixin

Se espera que los requisitos de autenticación se creen en el nodo JCR que define el subárbol que debe estar sujeto al inicio de sesión obligatorio. AEM Es probable que esta sea una página de en caso de que se espere que el CUG afecte a todo el árbol y, en consecuencia, la interfaz de usuario de la nueva implementación agregará el tipo de mezcla de requisito de autenticación en el nodo de página.

Colocar la directiva CUG solo en el nodo jcr:content ubicado debajo de una página determinada solo restringirá el acceso al contenido, pero no entrará en vigor en el propio nodo de la página ni en ninguna página secundaria.

Este puede ser un escenario válido y es posible con un editor de repositorios que permita colocar el mixin en cualquier nodo. Sin embargo, el comportamiento contrasta con la implementación anterior, en la que al colocar una propiedad cq:cugEnabled o cq:cugLoginPage en el nodo jcr:content se reasignaba internamente, en última instancia, al nodo de la página. Esta asignación ya no se realiza.

Rutas admitidas configuradas

Tanto la granite:AuthenticationRequired El tipo de mezcla y la propiedad granite:loginPath solo se respetarán dentro del ámbito definido por el conjunto de Rutas admitidas opción de configuración presente con la variable Requisito de autenticación de Adobe Granite y controlador de ruta de inicio de sesión. Si no se especifica ninguna ruta, la función de requisito de autenticación se desactiva por completo. En este caso, el tipo de mezcla ni la propiedad tienen efecto cuando se agregan o establecen en un nodo JCR determinado.

Asignación de contenido JCR, servicios OSGi y configuraciones

El documento siguiente proporciona una asignación completa de los servicios OSGi, las configuraciones y el contenido del repositorio entre la implementación antigua y la nueva.

AEM Asignación de CUG desde la versión 6.30000

Obtener archivo

Actualizar CUG

Instalaciones existentes que utilizan el CUG obsoleto

La antigua implementación de compatibilidad con CUG se ha desaprobado y se eliminará para en versiones futuras. AEM Se recomienda pasar a las nuevas implementaciones al actualizar desde versiones anteriores a la versión 6.3 de la aplicación de la versión de la versión de la versión de la versión de la versión de la versión 6.3.

AEM Para la instalación actualizada de la, es importante asegurarse de que solo se activa una implementación de CUG. La combinación de la nueva y la antigua compatibilidad con CUG obsoleta no se ha probado y es probable que cause un comportamiento no deseado:

• colisiones en Sling Authenticator con respecto a los requisitos de autenticación
• se ha denegado el acceso de lectura cuando la configuración de ACL asociada con el CUG antiguo entra en conflicto con una directiva de CUG nueva.

Migración del contenido de CUG existente

El Adobe proporciona una herramienta para migrar a la nueva implementación de CUG. Para utilizarlo, realice los siguientes pasos:

1. Ir a https://<serveraddress>:<serverport>/system/console/cug-migration para acceder a la herramienta.
2. Introduzca la ruta raíz para la que desea comprobar los CUG y pulse el botón Realizar ejecución en seco botón. Esto buscará los CUG aptos para la conversión en la ubicación seleccionada.
3. Después de revisar los resultados, presione la tecla Realización de migración para migrar a la nueva implementación.