AEM La forma principal de obtener un solucionador de sesión administrativa o de recursos en la aplicación de era usando el método de resolución de recursos de la aplicación de la aplicación de la. SlingRepository.loginAdministrative()
y ResourceResolverFactory.getAdministrativeResourceResolver()
métodos proporcionados por Sling.
Sin embargo, ninguno de estos métodos se diseñó en torno a la principio de menor privilegio y facilitar al desarrollador la tarea de no planificar una estructura adecuada y los niveles de control de acceso (ACL) correspondientes para su contenido desde el principio. Si una vulnerabilidad está presente en un servicio de este tipo, a menudo conduce a escalaciones de privilegios a admin
usuario, incluso si el código en sí no necesita privilegios administrativos para funcionar.
Puede haber casos en los que no se utilice la sesión de administración o en los que la función esté completamente deshabilitada. Si este es el caso de la implementación, asegúrese de eliminar por completo la función o de ajustarla con código NOP.
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 siguientes a las siguientes.
Muchos problemas se pueden resolver reestructurando el contenido. Tenga en cuenta estas reglas sencillas al realizar la reestructuración:
Cambiar control de acceso
Refinamiento de la estructura de contenido
Refactorice su código para que sea un servicio adecuado
Además, asegúrese de que todas las nuevas funciones que desarrolle se ajusten a estos principios:
Los requisitos de seguridad deben orientar la estructura de contenido
Utilizar tipos de nodos
Respetar la configuración de privacidad
/profile
nodo.Tanto si aplica el control de acceso al reestructurar el contenido como si lo hace para un nuevo usuario de servicio, debe aplicar las ACL más estrictas posibles. Utilice todas las posibilidades de control de acceso:
Por ejemplo, en lugar de aplicar jcr:read
el /apps
, solo aplíquelo a /apps/*/components/*/analytics
Uso restricciones
Aplicar ACL para los tipos de nodo
Limitar permisos
jcr:write
permiso; uso jcr:modifyProperties
en su lugarSi lo anterior falla, Sling 7 ofrece un servicio de asignación de usuarios de servicio, que permite configurar una asignación de paquete a usuario y dos métodos de API correspondientes:
Los métodos devuelven un solucionador de sesión/recurso 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 subservicios
El punto de configuración central es: org.apache.sling.serviceusermapping.impl.ServiceUserMapperImpl
service-id
= service-name
[":" nombre-subservicio]
service-id
está asignado a un solucionador 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
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 definido ninguna contraseña, no será posible iniciar sesión con un usuario del servicio.
Una forma de dejar de utilizar una sesión administrativa es reemplazarla por sesiones de usuarios de servicio. También podría ser reemplazado por varios usuarios de subservicios si es necesario.
Para reemplazar la sesión de administración por un usuario de servicio, debe realizar los siguientes pasos:
Identifique los permisos necesarios para su servicio, teniendo en cuenta el principio de permisos mínimos.
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. RTC es necesario para crear un usuario de servicio. A veces, tiene sentido crear varios usuarios de subservicios (por ejemplo, uno para escribir y otro para leer) para compartimentar el acceso aún más.
Configure y pruebe los ACE para el usuario.
Añadir un service-user
asignación para el servicio y para user/sub-users
Ponga a disposición del paquete la función de usuario de servicio sling: actualice a la versión más reciente de. org.apache.sling.api
.
Reemplace el admin-session
en el código con la variable loginService
o getServiceResourceResolver
API.
AEM Después de comprobar que no hay ningún usuario en la lista de usuarios del servicio de aplicable a su caso de uso y de aprobar los problemas de RTC correspondientes, puede continuar y agregar el nuevo usuario al contenido predeterminado.
El método recomendado es crear un usuario de servicio para utilizar el explorador de repositorios en https://<server>:<port>/crx/explorer/index.jsp
El objetivo es obtener un válido jcr:uuid
propiedad que es obligatoria para crear el usuario a través de la instalación de un paquete de contenido.
Puede crear usuarios de servicios de:
Ir al explorador de repositorios en https://<server>:<port>/crx/explorer/index.jsp
Iniciar sesión como administrador presionando la tecla Iniciar sesión en la esquina superior izquierda de la pantalla.
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 agregue subcarpetas opcionales según sus necesidades:
Compruebe que el nodo de usuario del sistema tenga el siguiente aspecto:
No hay tipos de mezcla asociados a usuarios del servicio. Esto significa que no habrá políticas de control de acceso para los usuarios del sistema.
Al agregar el archivo .content.xml correspondiente al contenido del paquete, asegúrese de haber establecido el rep:authorizableId
y que el tipo principal es 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"/>
Para añadir una asignación desde el servicio a los usuarios del sistema correspondientes, cree una configuración de fábrica para ServiceUserMapper
servicio. Para mantener esta configuración modular, se puede proporcionar dicha configuración utilizando la variable Mecanismo de modificación de Sling. La forma recomendada de instalar estas configuraciones con el paquete es mediante Cargando contenido inicial de Sling:
Cree una subcarpeta SLING-INF/content debajo de la carpeta src/main/resources del paquete
En esta carpeta, cree un archivo llamado org.apache.sling.serviceusermapping.impl.ServiceUserMapperImpl.modified-<some 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). Ejemplo:
Crear un SLING-INF/content
carpeta debajo de src/main/resources
carpeta de su paquete;
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.
A título ilustrativo, tome el archivo llamado org.apache.sling.serviceusermapping.impl.ServiceUserMapperImpl.amended-com.adobe.granite.auth.saml.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>
Hacer referencia al contenido inicial de Sling en la configuración del maven-bundle-plugin
en el pom.xml
de su paquete. Ejemplo:
<Sling-Initial-Content>
SLING-INF/content;path:=/libs/system/config;overwrite:=true;
</Sling-Initial-Content>
Instale el paquete y asegúrese de que la configuración de fábrica está instalada. Para ello:
Llamadas a loginAdministrative()
a menudo aparecen junto con sesiones compartidas. Estas sesiones se adquieren al activarse el servicio y solo se cierran después de que este se detiene. Aunque esta es una práctica común, conduce a dos problemas:
La solución más obvia para el riesgo de seguridad es simplemente reemplazar el loginAdministrative()
llamada con a loginService()
una a un usuario con privilegios restringidos. Sin embargo, esto no tendrá ningún impacto en ninguna degradación potencial del rendimiento. Una posibilidad de mitigar que es envolver toda la información solicitada en un objeto que no tiene asociación con la sesión. A continuación, cree (o destruya) la sesión bajo demanda.
El método recomendado es refactorizar la API del servicio para dar al que llama control sobre la creación o destrucción de la sesión.
Los JSP no pueden usar loginService()
, porque no hay ningún servicio asociado. Sin embargo, las sesiones administrativas en los JSP suelen ser un signo de una violación del paradigma de MVC.
Esto se puede solucionar de dos maneras:
El primer método es el preferido.
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 realizar su trabajo. Existen diferentes enfoques concebibles para resolver este problema, cada uno con sus ventajas y desventajas:
Pase el user-id
en la carga útil de evento y utilice la suplantación.
Ventajas: Fácil de usar.
Desventajas: Sigue usando loginAdministrative()
. Vuelve a autenticar una solicitud que ya se ha autenticado.
Crear o reutilizar un usuario de servicio que tenga acceso a los datos.
Ventajas: Compatible con el diseño actual. Necesita un cambio mínimo.
Desventajas: Necesita usuarios de servicios poderosos que sean flexibles, lo que puede llevar fácilmente a escalados de privilegios. Elude el modelo de seguridad.
Pasar una serialización de Subject
en la carga útil de evento y cree un ResourceResolver
basado en ese tema. Un ejemplo sería el uso del JAAS doAsPrivileged
en el ResourceResolverFactory
.
Ventajas: 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.
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 realizar su trabajo.
Para solucionar estos problemas, se recomienda que los mismos enfoques mencionados en Procesamiento de eventos, preprocesadores de replicación y trabajos se utilizará.
Hay un par de sesiones administrativas que se utilizan en las implementaciones de POST de Sling. Normalmente, las sesiones administrativas se utilizan para acceder a nodos cuya eliminación está pendiente 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 lo contrario, no deberían estar accesibles.