Utilisateurs de services dans AEM

Présentation

La principale façon d’obtenir un résolveur de session d’administration ou de ressource dans AEM consistait à utiliser les méthodes SlingRepository.loginAdministrative() et ResourceResolverFactory.getAdministrativeResourceResolver() fournies par Sling.

Toutefois, aucune de ces méthodes n’a été conçue selon le principe de moindre privilège. En conséquence, il est trop facile d’ignorer au cours du développement la planification d’une structure et de niveaux de contrôle d’accès (ACL) appropriés pour leur contenu dès le début. Si une vulnérabilité est présente dans un tel service, elle conduit souvent à des réaffectations de privilèges admin, même si le code n’a pas besoin de privilèges d’administration pour fonctionner.

Comment supprimer les sessions d’administration

Priorité 0 : La fonctionnalité est-elle principale/nécessaire/abandonnée ?

Il peut y avoir des cas où la session d’administration n’est pas utilisée, ou la fonction est complètement désactivée. Si tel est le cas avec votre mise en œuvre, assurez-vous de supprimer la fonction entièrement ou accompagnez-la d’une instruction nulle.

Priorité 1 : Utilisation De La Session De Requête

Lorsque cela est possible, refactorisez votre fonction de sorte que la session de requête authentifiée donnée puisse être utilisée pour écrire ou lire du contenu. Si cela n'est pas possible, il est souvent possible d'y parvenir en appliquant les priorités suivantes.

Priorité 2 : Restructurer le contenu

De nombreux problèmes peuvent être résolus en restructurant le contenu. Gardez ces règles simples à l’esprit lorsque vous effectuez la restructuration :

• Modifier le contrôle d’accès

  • Assurez-vous que les utilisateurs ou les groupes qui ont réellement besoin d’un accès ont bien accès à .

• Affiner la structure de contenu

  • Déplacez-le vers d’autres emplacements, par exemple lorsque le contrôle d’accès correspond aux sessions de requête disponibles ;
  • modifier la granularité du contenu ;

• Refactorisation du code afin qu’il corresponde à un service approprié

  • Redéfinissez la logique métier du code JSP en service. Cela permet une modélisation de contenu différente.

Veillez également à ce que toutes les nouvelles fonctionnalités que vous développez respectent les principes suivants :

• Les exigences de sécurité doivent déterminer la structure de contenu

  • La gestion du contrôle d’accès doit être naturelle
  • Le contrôle d’accès doit être appliqué par le référentiel, et non par l’application.

• Utilisation des types de noeuds

  • Restreindre l’ensemble des propriétés qui peuvent être définies

• Respectez les paramètres de confidentialité

  • Dans le cas de profils privés, par exemple, n’exposez pas la photo de profil, l’adresse électronique ni le nom complet figurant sur le nœud /profile privé.

Contrôle d’accès strict

Si vous appliquez le contrôle d’accès lors de la restructuration du contenu ou lorsque vous le faites pour un nouvel utilisateur, vous devez appliquer les listes ACL les plus strictes possibles. Utilisez tous les moyens de contrôle d’accès possibles :

• Par exemple, plutôt que d’appliquer jcr:read sur /apps, appliquez-le uniquement sur /apps/*/components/*/analytics.

• Utilisez des restrictions.

• Application de listes de contrôle d’accès pour les types de noeuds

• Limiter les autorisations

  • Par exemple, si vous avez besoin de l’autorisation d’écriture uniquement pour les propriétés, ne donnez pas l’autorisation jcr:write, utilisez plutôt jcr:modifyProperties.

Utilisateurs de services et mises en correspondance

En cas d’échec de la procédure ci-dessus, Sling 7 offre un service de mappage des utilisateurs de services qui permet de configurer un mappage des lots à utilisateur et deux méthodes d’API correspondantes : [SlingRepository.loginService()](https://sling.apache.org/apidocs/sling7/org/apache/sling/jcr/api/SlingRepository.html#loginService-java.lang.String-java.lang.String-) et [ResourceResolverFactory.getServiceResourceResolver()](https://sling.apache.org/apidocs/sling7/org/apache/sling/api/resource/ResourceResolverFactory.html#getServiceResourceResolver-java.util.Map-) qui renvoient un résolveur de session/ressource avec uniquement les privilèges d’un utilisateur configuré. Ces méthodes présentent les caractéristiques suivantes :

• Elles permettent de mettre en correspondance les services avec les utilisateurs.

• Elles permettent de définir des utilisateurs de sous-services.

• Le point central de configuration est le suivant : org.apache.sling.serviceusermapping.impl.ServiceUserMapperImpl.

• service-id = service-name [ “:” subservice-name ]

• service-id est mis en correspondance avec un résolveur de ressource et/ou un ID d’utilisateur de référentiel JCR pour l’authentification.

• service-name est le nom symbolique du lot qui fournit le service.

Autres Recommendations

Remplacement de la session d’administration par un utilisateur de service

Un utilisateur de service est un utilisateur JCR sans mot de passe défini et avec un jeu minimal d’autorisations nécessaires pour effectuer une tâche spécifique. Si aucun mot de passe n’est défini, il ne sera pas possible de se connecter avec un utilisateur du service.

Une façon de rendre une session administrative obsolète consiste à la remplacer par des sessions d’utilisateurs de services. Il peut également être remplacé par plusieurs utilisateurs de sous-services si nécessaire.

Pour remplacer la session d’administrateur par un utilisateur de service, procédez comme suit :

1. Identifiez les autorisations nécessaires à votre service, en gardant à l’esprit le principe de la moindre autorisation.

2. Vérifiez s’il existe déjà un utilisateur disponible ayant exactement la configuration de permissions dont vous avez besoin. Créez un utilisateur de service système si aucun utilisateur existant ne correspond à vos besoins. RTC est nécessaire pour créer un utilisateur de service. Parfois, il est logique de créer plusieurs utilisateurs de sous-services (par exemple, un pour l’écriture et un autre pour la lecture) pour compartimenter encore plus l’accès.

3. Configurez et testez les ACE pour votre utilisateur.

4. Ajoutez une mise en correspondance service-user pour votre service et pour les user/sub-users

5. Rendez la fonction Sling d’utilisateur de service disponible pour votre lot : mettez à jour vers la version la plus récente de org.apache.sling.api.

6. Remplacez admin-session dans votre code par les API loginService ou getServiceResourceResolver.

Création d’un utilisateur de service

Après avoir vérifié qu’aucun utilisateur de la liste des utilisateurs du service AEM ne s’applique à votre cas d’utilisation et que les problèmes RTC correspondants ont été approuvés, vous pouvez poursuivre et ajouter le nouvel utilisateur au contenu par défaut.

Il est recommandé de créer un utilisateur de service pour utiliser l’explorateur de référentiel à l’adresse https://<server>:<port>/crx/explorer/index.jsp.

Le but est d’obtenir une propriété jcr:uuid valide qui est obligatoire pour créer l’utilisateur par l’intermédiaire d’une installation de package de contenu.

Vous pouvez créer des utilisateurs de services de la façon suivante :

1. En vous rendant dans l’explorateur de référentiel sur https://<server>:<port>/crx/explorer/index.jsp.

2. Connectez-vous en tant qu’administrateur en appuyant sur la touche Connexion dans le coin supérieur gauche de l’écran.

3. Ensuite, créez et nommez votre utilisateur système. Pour créer l’utilisateur en tant qu’utilisateur système, définissez le chemin intermédiaire comme system et ajoutez des sous-dossiers facultatifs en fonction de vos besoins :

   

4. Vérifiez que le nœud d’utilisateur système se présente comme suit :

   

   REMARQUE

   Notez qu’il n’y a aucun type de mixin associé aux utilisateurs de services. Cela signifie qu’il n’y a aucune stratégie de contrôle d’accès pour les utilisateurs système.

En ajoutant le fichier content.xml correspondant au contenu du lot, assurez-vous que vous avez défini le rep:authorizableId et que le type principal est rep:SystemUser. Il doit ressembler à ceci :

<?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"/>

Ajout d’une modification de configuration à la configuration ServiceUserMapper

Pour ajouter une mise en correspondance de votre service avec les utilisateurs système correspondants, vous devez créer une configuration de fabrique pour le service [ServiceUserMapper](https://sling.apache.org/apidocs/sling7/org/apache/sling/serviceusermapping/ServiceUserMapper.html). Pour conserver la modularité, de telles fonctionnalités peuvent être fournies par le mécanisme d’amendement de Sling. La méthode recommandée pour installer de telles configurations avec votre lot consiste à utiliser Chargement initial du contenu Sling:

1. Créez un sous-dossier SLING-INF/content sous le dossier src/main/resources de votre lot.

2. Dans ce dossier, créez un fichier appelé org.apache.sling.serviceusermapping.impl.ServiceUserMapperImpl.amended-<nom unique de votre configuration de fabrique>.xml avec le contenu de votre configuration de fabrique (incluant toutes les mises en correspondance d’utilisateurs de sous-services). Exemple :

3. Créez un sous-dossier SLING-INF/content sous le dossier src/main/resources de votre lot.

4. Dans ce dossier, créez un fichier named org.apache.sling.serviceusermapping.impl.ServiceUserMapperImpl.amended-<a unique name for your factory configuration>.xml avec le contenu de votre configuration d’usine, y compris tous les mappages utilisateur de sous-service.

   À des fins d’illustration, prenez le fichier nommé 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>
   

5. Référencez le contenu initial Sling dans la configuration de maven-bundle-plugin dans le fichier pom.xml du lot. Exemple :

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

6. Installez le lot et assurez-vous que la configuration de fabrique a été installée. Vous pouvez le faire en procédant comme suit :

   • Accédez à la console web à l’adresse https://serverhost:serveraddress/system/console/configMgr.
   • Recherchez Amendement du service de mappage des utilisateurs de service Apache Sling.
   • Cliquez sur le lien pour vérifier si la configuration appropriée est en place.

Traitement des sessions partagées dans les services

Les appels à loginAdministrative() apparaissent souvent avec les sessions partagées. Ces sessions sont acquises lors de l’activation du service et ne sont déconnectées qu’après l’arrêt du service. Bien qu’il s’agisse d’une pratique courante, cela débouche sur deux problèmes :

• Sécurité : ces sessions d’administrateur sont utilisées pour mettre en cache et renvoyer les ressources ou d’autres objets qui sont liés à la session partagée. Plus loin dans la pile d’appels, ces objets peuvent être adaptés aux sessions ou aux résolveurs de ressources avec des privilèges élevés. Il n’est souvent pas clair pour l’appelant qu’il s’agit d’une session d’administration avec laquelle ils opèrent.
• Performances : Dans Oak, les sessions partagées peuvent entraîner des problèmes de performances et il n’est actuellement pas recommandé de les utiliser.

La solution la plus évidente au risque de sécurité est de remplacer simplement l’appel loginAdministrative() par un appel loginService() à un utilisateur disposant d’autorisations limitées. Toutefois, cette opération n’aura aucune incidence sur une éventuelle dégradation des performances. Vous pouvez limiter ces éventuelles dégradations en incluant toutes les informations requises dans un objet qui n’est plus associé à la session. Ensuite, créez (ou détruisez) la session à la demande.

L’approche recommandée consiste à refactoriser l’API du service afin que l’appelant puisse contrôler la création/destruction de la session.

Sessions d’administration dans les JSP

Les JSP ne peuvent pas utiliser loginService() car il n’y a aucun service associé. Toutefois, les sessions administratives dans les JSP indiquent généralement une violation du paradigme MVC.

Ce problème peut être résolu de deux façons :

1. Restructurer le contenu de manière à pouvoir le manipuler avec la session utilisateur ;
2. Extraire la logique vers un service qui fournit une API qui peut ensuite être utilisée par le JSP.

La première méthode est préférable.

Événements de traitement, préprocesseurs de réplication et tâches

Lors du traitement d’événements, de tâches, et dans certains cas, de workflows, la session correspondante qui a déclenché l’événement est généralement perdue. Il en résulte que les gestionnaires d’événements et les processeurs de tâches utilisent souvent des sessions administratives pour effectuer leurs tâches. Il existe différentes approches possibles pour résoudre ce problème, chacune présentant ses avantages et ses inconvénients :

1. Transmettez l’user-id dans le payload de l’événement et utilisez l’emprunt d’identité.

   Avantages : facilité d’utilisation.

   Inconvénients : continue d’utiliser loginAdministrative(). Il réauthentifie une requête qui a déjà été authentifiée.

2. Créez ou réutilisez un utilisateur de service ayant accès aux données.

   Avantages : cohérent par rapport à la conception actuelle. Nécessite peu de modifications.

   Inconvénients : nécessite que les utilisateurs de services très performants soient flexibles, ce qui peut facilement conduire à une réaffectation des privilèges. Évite le modèle de sécurité.

3. Transmettez une sérialisation du Subject dans le payload d’événement et créez un ResourceResolver basé sur cet objet. Un exemple serait d’utiliser le JAAS doAsPrivileged dans le ResourceResolverFactory.

   Avantages : mise en œuvre propre du point de vue de la sécurité. Cela évite la réauthentification et utilise les privilèges d’origine. Le code pertinent pour la sécurité est transparent pour le consommateur de l’événement.

   Inconvénients : nécessité de refactoriser. Le fait que le code approprié pour la sécurité soit transparent pour le consommateur de l’événement peut également entraîner des problèmes.

La troisième approche est actuellement la technique de traitement préférée.

Processus de workflow

Dans les mises en œuvre de processus de workflow, la session utilisateur correspondante ayant déclenché le workflow est généralement perdue. Cela conduit à ce que les processus de workflow utilisent souvent des sessions administratives pour effectuer leur travail.

Pour résoudre ces problèmes, il est recommandé d’utiliser les mêmes méthodes que celles mentionnées dans la section Événements de traitement, préprocesseurs de réplication et tâches à utiliser.

Traitateurs de POST Sling et pages supprimées

Plusieurs sessions administratives sont utilisées dans les mises en œuvre de processeur POST Sling. En règle générale, les sessions administratives sont utilisées pour accéder aux nœuds qui sont en attente de suppression dans le POST en cours de traitement. Par conséquent, ils ne sont plus disponibles via la session de requête. Un noeud en attente de suppression peut être accessible pour révéler des métadonnées qui, autrement, ne devraient pas être accessibles.