Utilisateurs de services dans AEM

Présentation

The main way of getting an administrative session or resource resolver in AEM was using the SlingRepository.loginAdministrative() and ResourceResolverFactory.getAdministrativeResourceResolver() methods provided by Sling.

Toutefois, aucune de ces méthodes n’a été conçue selon le principe de moindre autorisation. En conséquence, elles permettent facilement à un développeur de ne pas planifier de 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 à l’utilisateur admin, même si le code n’a pas besoin de privilèges d’administrateur pour fonctionner.

Élimination des sessions d’administrateur

Priority 0: Is the feature active/needed/derelict?

Il peut y avoir des cas où la session administrateur 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 : utilisez 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 ce n’est pas possible, elle peut fréquemment être obtenue en appliquant les priorités comme ci-dessous.

Priorité 2 : restructurez le contenu

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

  • Modification du contrôle d’accès

    • Assurez-vous que les utilisateurs ou les groupes qui ont réellement besoin d’accès ont accès.
  • Amélioration de la structure de contenu

    • Déplacez-le vers d’autres emplacements, par exemple là où le contrôle d’accès correspond aux sessions de requête disponibles.
    • Modifiez 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.

En outre, assurez-vous que toutes les nouvelles fonctions que vous développez sont conformes aux principes suivants :

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

    • La gestion du contrôle d’accès doit sembler naturelle.
    • Le contrôle d’accès doit être imposé par le référentiel, et non par l’application.
  • Tirez parti des types de nœuds.

    • Limitez le jeu de propriétés qui peut être défini.
  • Respectez les paramètres de confidentialité.

    • In the case of private profiles, one example would be to not expose the profile picture, email or full name found on the private /profile node.

Contrôle d’accès strict

Que vous appliquiez un contrôle d'accès lors de la restructuration du contenu ou lorsque vous le faisiez pour un nouvel utilisateur de service, vous devez appliquer les ACL les plus strictes possible. Utilisez tous les moyens de contrôle d’accès possibles :

  • For example, instead of applying jcr:read on /apps, only apply it to /apps/*/components/*/analytics

  • Utiliser les restrictions

  • Application de listes ACL aux types de nœuds

  • Limitation des autorisations

    • for example, when only needing to write properties, do not give the jcr:write permission; use jcr:modifyProperties instead

Utilisateurs de services et mises en correspondance

If the above fails, Sling 7 offers a Service User Mapping service, which allows to configure a bundle-to-user mapping and two corresponding API methods: [SlingRepository.loginService()](https://sling.apache.org/apidocs/sling7/org/apache/sling/jcr/api/SlingRepository.html#loginService-java.lang.String-java.lang.String-) and [ResourceResolverFactory.getServiceResourceResolver()](https://sling.apache.org/apidocs/sling7/org/apache/sling/api/resource/ResourceResolverFactory.html#getServiceResourceResolver-java.util.Map-) which return a session/resource resolver with the privileges of a configured user only. 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 " [ :" sous-service-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 recommandations

Remplacement de l’admin-session par un service-user

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. L’absence de mot de passe défini signifie qu’il n’est pas possible de se connecter avec un utilisateur de service.

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

Pour remplacer la session administrative par un utilisateur de services, vous devez effectuer les étapes suivantes :

  1. Identifiez les autorisations nécessaires pour votre service, en gardant à l’esprit le principe de 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. Dans certains cas, il est préférable de créer plusieurs utilisateurs de sous-services (par exemple, un pour écrire et l’autre pour lire) afin de compartimenter encore davantage l’accès.

  3. Configurez et testez les ACE pour votre utilisateur.

  4. Add a service-user mapping for your service and for 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. Replace the admin-session in your code with the loginService or getServiceResourceResolver APIs.

Création d’un utilisateur de service

Après avoir vérifié qu’aucun utilisateur dans la liste des utilisateurs de services AEM ne s’applique à votre cas d’utilisation, et que les problèmes RTC correspondants ont été approuvés, vous pouvez procéder à l’ajout de l’utilisateur au contenu par défaut.

The recommended approach is to create a service user to use the repository explorer at 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 module de contenu.

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

  1. Going to the repository explorer at https://<server>:<port>/crx/explorer/index.jsp

  2. Ouvrez une session en tant qu’administrateur en appuyant sur le lien 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 :

    chlimage_1-102

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

    chlimage_1-103

    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’un amendement 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 ces configurations avec votre lot consiste à utiliser le chargement du contenu initial de 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 nommé org.apache.sling.serviceusermapping.impl.ServiceUserMapperImpl.changed-<un nom unique pour votre configuration d’usine>.xml avec le contenu de votre configuration d’usine (y compris tous les mappages d’utilisateurs de sous-services). Exemple :

  3. Create a SLING-INF/content folder below the src/main/resources folder of your bundle;

  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 d’utilisateurs de sous-services.

    À 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. Reference the Sling initial content in the configuration of the maven-bundle-plugin in the pom.xml of your bundle. 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 :

    • Going to the Web Console at https://serverhost:serveraddress/system/console/configMgr
    • Recherchez Apache Sling Service User Mapper Service Amendment.
    • Cliquez sur le lien pour vérifier si la configuration appropriée est en place.

Traitement des sessions partagées dans les services

Calls to loginAdministrative() often appear together with shared sessions. 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 que cette pratique soit courante, elle soulève 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 autorisations élevées, or il n’est souvent pas évident pour l’appelant que la session utilisée est une session d’administrateur.
  • Performances : dans Oak, les sessions partagées peuvent entraîner des problèmes de performances, et il n’est pas recommandé de les utiliser à l’heure actuelle.

The most obvious solution for the security risk is to simply replace the loginAdministrative() call with a loginService() one to a user with restricted privileges. 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 pour donner à l’appelant le contrôle de la création/destruction de la session.

Sessions administratives dans les JSP

JSPs cannot use loginService(), because there is no associated service. Cependant, les sessions administratives dans les JSP sont généralement le signe d'une violation du paradigme du MVC.

Cela peut être corrigé de deux façons :

  1. En restructurant le contenu d’une manière qui permet de les manipuler avec la session utilisateur
  2. En extrayant la logique vers un service qui fournit une API qui peut alors être utilisée par le JSP

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

Traitement des événements, des préprocesseurs de réplication et des 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. Différentes approches sont envisageables pour résoudre ce problème, chacune ayant ses avantages et ses inconvénients :

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

    Avantages : facilité d’utilisation.

    Inconvénients : Toujours utilisé 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 un minimum de modifications.

    Inconvénients : Il faut des utilisateurs de services très puissants pour être flexibles, ce qui peut facilement conduire à des réaffectations de privilèges. Évite le modèle de sécurité.

  3. Pass a serialization of the Subject in the event payload, and create a ResourceResolver based on that subject. 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 relevant de la sécurité est transparent pour le consommateur de l’événement.

    Inconvénients : Il faut refaçonner. Le fait que le code relevant de 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. En conséquence, les processus de workflow utilisent souvent des sessions administratives pour effectuer leurs tâches.

Pour résoudre ces problèmes, il est recommandé que les mêmes approches mentionnées dans les Traitement des événements, des préprocesseurs de réplication et des tâches soient utilisées.

Processeurs 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. Les nœuds en attente de suppression sont accessibles pour révéler les métadonnées qui ne devraient pas être accessibles dans le cas contraire.

Sur cette page