DocumentaciónAEM 6.5Guía del usuario

Usuarios de servicio en Adobe Experience Manager (AEM) service-users-in-aem

Last update: Thu Sep 25 2025 00:00:00 GMT+0000 (Coordinated Universal Time)
  • Se aplica a:
  • Experience Manager 6.5

Creado para:

  • Administrador

Información general overview

La forma principal de obtener una resolución de sesiones o de recursos de administración en AEM era usar los métodos SlingRepository.loginAdministrative() y ResourceResolverFactory.getAdministrativeResourceResolver() proporcionados por Sling.

Sin embargo, ninguno de estos métodos se diseñó en torno al principio de mínimo privilegio. Hace que sea demasiado fácil para un desarrollador no planificar desde el principio una estructura adecuada y los correspondientes niveles de control de acceso (ACL) para su contenido. Si existe una vulnerabilidad en un servicio de este tipo, a menudo se producen escalaciones de privilegios para el usuario admin, incluso si el código en sí no necesita privilegios administrativos para funcionar.

Cómo eliminar gradualmente las sesiones de administración how-to-phase-out-admin-sessions

Prioridad 0: ¿La función está activa/es necesaria/está en desuso? priority-is-the-feature-active-needed-derelict

Puede haber casos en los que no se utilice la sesión de administración o en los que la función esté deshabilitada por completo. Si es así con su implementación, asegúrese de quitar la característica del todo o de ajustarla con código NOP.

Prioridad 1: Utilizar la sesión de solicitud priority-use-the-request-session

Siempre que sea posible, refactorice la función para que la sesión de solicitud autenticada dada se pueda utilizar para leer o escribir contenido. Si esto no es factible, a menudo se puede lograr aplicando las prioridades que se indican a continuación.

Prioridad 2: Reestructurar el contenido priority-restructure-content

Muchos problemas se pueden resolver reestructurando el contenido. Tenga en cuenta estas reglas sencillas al realizar la reestructuración:

  • Cambiar el control de acceso

    • Asegúrese de que los usuarios o grupos que de verdad necesiten acceso lo tengan;

  • Refinar la estructura de contenido

    • Muévalo a otras ubicaciones, por ejemplo, donde el control de acceso coincida con las sesiones de solicitud disponibles;
    • Cambiar la granularidad del contenido;

  • Refactorizar su código para que sea un servicio apropiado

    • Cambie la lógica empresarial del código JSP al servicio. Esto permite un modelado de contenido diferente.

Además, asegúrese de que todas las nuevas funciones que desarrolle se ajusten a estos principios:

  • Los requisitos de seguridad deben dirigir la estructura de contenido

    • La administración del control de acceso debería ser natural
    • El control de acceso lo debe aplicar el repositorio, no la aplicación

  • Utilizar tipos de nodos

    • Restrinja el conjunto de propiedades que se pueden establecer

  • Respetar la configuración de privacidad

    • Si hay perfiles privados, un ejemplo sería no exponer la imagen de perfil, el correo electrónico o el nombre completo que se encuentra en el nodo privado /profile.

Aplique un control de acceso estricto strict-access-control

Tanto si aplica el control de acceso al reestructurar el contenido como si lo hace para un nuevo usuario de servicio, debe aplicar los ACL más estrictos posibles. Utilice todas las posibilidades del control de acceso:

  • Por ejemplo, en lugar de aplicar jcr:read en /apps, aplíquelo solo a /apps/*/components/*/analytics

  • Usar restricciones

  • Aplicar ACL para los tipos de nodos

  • Limitar permisos

    • por ejemplo, cuando solo necesite escribir propiedades, no conceda el permiso jcr:write; use jcr:modifyProperties en su lugar

Usuarios de servicio y asignaciones service-users-and-mappings

Si lo anterior falla, Sling 7 ofrece un servicio de asignación de usuarios de servicio, que le permite configurar una asignación de paquete a usuario y dos métodos de API correspondientes:

Los métodos devuelven una resolución de sesiones/recursos con los privilegios de un usuario configurado solamente. Estos métodos tienen las siguientes características:

  • Permiten asignar servicios a los usuarios

  • Permiten definir a los usuarios de subservicio

  • El punto de configuración central es: org.apache.sling.serviceusermapping.impl.ServiceUserMapperImpl

  • service-id = service-name [":" subservice-name]

  • service-id está asignado a una resolución de recursos o a un ID de usuario del repositorio JCR para la autenticación

  • service-name es el nombre simbólico del paquete que proporciona el servicio

Otras recomendaciones other-recommendations

Reemplazar la sesión de administración por un usuario de servicio replacing-the-admin-session-with-a-service-user

Un usuario de servicio es un usuario de JCR sin contraseña establecida y con un conjunto mínimo de privilegios necesarios para realizar una tarea específica. Si no se ha establecido ninguna contraseña, no es posible iniciar sesión con un usuario de servicio.

Una forma de poner en desuso una sesión administrativa es reemplazarla por sesiones de usuarios de servicio. También podría sustituirse por varios usuarios de subservicios, si es necesario.

Para reemplazar la sesión de administración por un usuario de servicio, debe seguir estos pasos:

  1. Identifique los permisos necesarios para su servicio y tenga en cuenta el principio de permisos mínimos.

  2. Compruebe si ya hay un usuario disponible con exactamente la configuración de permisos que necesita. Cree un usuario de servicio del sistema si ningún usuario existente coincide con sus necesidades. Se necesita RTC para crear un usuario de servicio. A veces, tiene sentido crear varios usuarios de subservicios (por ejemplo, uno de escritura y otro de lectura) para compartimentar el acceso aún más.

  3. Configure y pruebe las ACE para el usuario.

  4. Añada una asignación service-user para su servicio y para user/sub-users

  5. Haga que la funcionalidad de usuario de servicio de Sling esté disponible en su paquete: actualice a la versión más reciente de org.apache.sling.api.

  6. Reemplace admin-session en su código con las API loginService o getServiceResourceResolver.

Creación de un usuario de servicio creating-a-new-service-user

Después de comprobar que ningún usuario de la lista de usuarios de servicio de AEM es aplicable a su caso de uso y de aprobar los problemas de RTC correspondientes, añada el nuevo usuario al contenido predeterminado.

El método recomendado es crear un usuario de servicio para utilizar el explorador del repositorio en https://<server>:<port>/crx/explorer/index.jsp

El objetivo es obtener una propiedad jcr:uuid válida, que es obligatoria para crear el usuario mediante la instalación de un paquete de contenido.

Puede crear usuarios de servicio siguiendo estos pasos:

  1. Vaya al explorador del repositorio en https://<server>:<port>/crx/explorer/index.jsp

  2. Inicie sesión como administrador pulsando el vínculo Iniciar sesión en la esquina superior izquierda de la pantalla.

  3. A continuación, cree y asigne un nombre al usuario del sistema. Para crear el usuario como del sistema, establezca la ruta intermedia como system y añada subcarpetas opcionales según sus necesidades:

    chlimage_1-102

  4. Compruebe que el nodo de usuario del sistema tenga el siguiente aspecto:

    chlimage_1-103

    note note
    NOTE
    No hay tipos de mezcla asociados a usuarios de servicio. Esto significa que no hay directivas de control de acceso para los usuarios del sistema.

Al añadir el archivo .content.xml correspondiente al contenido del paquete, asegúrese de haber establecido rep:authorizableId y de que el tipo principal sea rep:SystemUser. Debería tener un aspecto similar al siguiente:

<?xml version="1.0" encoding="UTF-8"?>
<jcr:root xmlns:jcr="https://www.jcp.org/jcr/1.0" xmlns:rep="internal"
    jcr:primaryType="rep:SystemUser"
    jcr:uuid="4917dd68-a0c1-3021-b5b7-435d0044b0dd"
    rep:principalName="authentication-service"
    rep:authorizableId="authentication-service"/>

Adición de una modificación de configuración a la configuración de ServiceUserMapper adding-a-configuration-amendment-to-the-serviceusermapper-configuration

Para añadir una asignación desde su servicio a los usuarios del sistema correspondientes, cree una configuración de fábrica para el servicio ServiceUserMapper.  Para mantener este elemento modular, dicha configuración se puede proporcionar mediante el mecanismo de modificación de Sling. La manera recomendada de instalar estas configuraciones con su paquete es usando la carga inicial de contenido de Sling:

  1. Cree una subcarpeta SLING-INF/content debajo de la carpeta src/main/resources del paquete

  2. En esta carpeta, cree un archivo llamado org.apache.sling.serviceusermapping.impl.ServiceUserMapperImpl.amended-<algún nombre único para su configuración de fábrica>.xml con el contenido de su configuración de fábrica (incluidas todas las asignaciones de usuarios de subservicios). Ejemplo:

  3. Cree una carpeta SLING-INF/content debajo de la carpeta src/main/resources del paquete;

  4. En esta carpeta, cree un archivo named org.apache.sling.serviceusermapping.impl.ServiceUserMapperImpl.amended-<a unique name for your factory configuration>.xml con el contenido de la configuración de fábrica, incluidas todas las asignaciones de usuario de subservicio.

    Por motivos ilustrativos, coja el archivo llamado org.apache.sling.serviceusermapping.impl.ServiceUserMapperImpl.amended-com.adobe.granite.auth.saml.xml:

    code language-xml 
    <?xml version="1.0" encoding="UTF-8"?>
<node>
    <primaryNodeType>sling:OsgiConfig</primaryNodeType>
    <property>
        <name>user.default</name>
        <value></value>
    </property>
    <property>
        <name>user.mapping</name>
        <values>
            <value>com.adobe.granite.auth.saml=authentication-service</value>
        </values>
    </property>
</node>

  5. Haga referencia al contenido inicial de Sling en la configuración de maven-bundle-plugin en pom.xml de su paquete. Ejemplo:

    code language-xml 
    <Sling-Initial-Content>
   SLING-INF/content;path:=/libs/system/config;overwrite:=true;
</Sling-Initial-Content>

  6. Instale el paquete y asegúrese de que la configuración de fábrica está instalada. Para ello, haga lo siguiente:

    • Visite la consola web en https://serverhost:serveraddress/system/console/configMgr
    • Busque Apache Sling Service User Mapper Service Amendment
    • Haga clic en el vínculo para ver si se ha implementado la configuración adecuada.

Trato de sesiones compartidas en servicios dealing-with-shared-sessions-in-services

Las llamadas a loginAdministrative() suelen aparecer junto con las sesiones compartidas. Estas sesiones se adquieren al activarse el servicio y solo se cierran después de que este se detenga. Aunque esta es una práctica común, causa dos problemas:

  • Seguridad: estas sesiones de administración se usan para almacenar en caché y devolver recursos u otros objetos enlazados a la sesión compartida. Más adelante en la pila de llamadas, estos objetos podrían adaptarse a sesiones o resoluciones de recursos con privilegios elevados. A menudo, quien realiza la llamada no tiene claro que está operando con una sesión de administración.
  • Rendimiento: en Oak, las sesiones compartidas pueden causar problemas de rendimiento y no se recomienda usarlas.

La solución más obvia para el riesgo de seguridad es simplemente reemplazar la llamada de loginAdministrative() con una llamada de loginService() a un usuario con privilegios restringidos. Sin embargo, esto no tiene ningún impacto en ninguna degradación potencial del rendimiento. Una posibilidad de mitigarlo es envolver toda la información solicitada en un objeto que no esté asociado con la sesión. A continuación, cree (o destruya) la sesión bajo demanda.

El enfoque recomendado es refactorizar la API del servicio para dar control a quien realiza la llamada sobre la creación o destrucción de la sesión.

Sesiones administrativas en JSP administrative-sessions-in-jsps

Las JSP no pueden usar loginService(), ya que no hay ningún servicio asociado. Sin embargo, las sesiones administrativas en las JSP suelen indicar una vulneración del paradigma MVC.

Esto se puede solucionar de dos maneras:

  1. Reestructurando el contenido de forma que permita manipularlo con la sesión del usuario;
  2. Extrayendo la lógica a un servicio que proporcione una API que luego pueda utilizar la JSP.

El primer método es el preferido.

Procesamiento de eventos, preprocesadores de replicación y trabajos processing-events-replication-preprocessors-and-jobs

Al procesar eventos o trabajos, y a veces flujos de trabajo, se pierde la sesión correspondiente que activó el evento. Esto lleva a que los controladores de eventos y los procesadores de trabajos a menudo utilicen sesiones administrativas para hacer su trabajo. Existen diferentes enfoques concebibles para resolver este problema, cada uno con sus ventajas y desventajas:

  1. Pasar user-id en la carga útil de evento y utilice la suplantación.

    Ventajas: es fácil de usar.

    Desventajas: sigue utilizando loginAdministrative(). Vuelve a autenticar una solicitud que ya se ha autenticado.

  2. Crear o reutilizar un usuario de servicio que tenga acceso a los datos.

    Ventajas: es coherente con el diseño actual. Necesita un cambio mínimo.

    Desventajas: necesita que los usuarios de servicio avanzados sean flexibles, lo que puede llevar fácilmente a escalaciones de privilegios. Elude el modelo de seguridad.

  3. Pasar una serialización de Subject en la carga útil de evento y cree una ResourceResolver basado en ese asunto. Un ejemplo sería el uso de JAAS doAsPrivileged en ResourceResolverFactory.

    Ventajas: es una implementación limpia desde el punto de vista de la seguridad. Evita la reautenticación y funciona con los privilegios originales. El código relevante para la seguridad es transparente para el consumidor del evento.

    Desventajas: necesita refactorización. El hecho de que el código relevante para la seguridad sea transparente para el consumidor del evento también puede provocar problemas.

El tercer enfoque es la técnica de procesamiento preferida.

Procesos de flujo de trabajo workflow-processes

Dentro de las implementaciones de procesos de flujo de trabajo, se pierde la sesión de usuario correspondiente que activó el flujo de trabajo. Esto lleva a procesos de flujo de trabajo que, a menudo, utilizan sesiones administrativas para hacer su trabajo.

Para solucionar estos problemas, se recomienda emplear los mismos enfoques mencionados en Procesamiento de eventos, preprocesadores de replicación y trabajos.

Procesadores POST de Sling y páginas eliminadas sling-post-processors-and-deleted-pages

Hay un par de sesiones administrativas utilizadas en las implementaciones de procesadores POST de Sling. Por lo general, las sesiones administrativas se usan para acceder a nodos que están pendientes de eliminación dentro del POST que se está procesando. En consecuencia, ya no están disponibles a través de la sesión de solicitud. Se puede acceder a un nodo cuya eliminación está pendiente para revelar metadatos que, de otro modo, no deberían estar accesibles.

recommendation-more-help
19ffd973-7af2-44d0-84b5-d547b0dffee2