Plusieurs thèmes sont associés à l’activation de l’accès à un référentiel CRX :
Les éléments de base sont les suivants :
Comptes d’utilisateur - CRX authentifie l’accès en identifiant et en vérifiant un utilisateur (par cette personne ou une autre application) en fonction des détails contenus dans le compte utilisateur.
Dans CRX, chaque compte utilisateur est un noeud de l’espace de travail. Un compte utilisateur CRX possède les propriétés suivantes :
Il représente un utilisateur ou une utilisatrice de CRX.
Il contient un nom d’utilisateur et un mot de passe.
Applicable à cet espace de travail.
Il ne peut pas y avoir de sous-utilisateurs. Pour les droits d’accès hiérarchiques, vous devez utiliser des groupes.
Vous pouvez spécifier des droits d’accès pour le compte utilisateur.
Toutefois, pour simplifier la gestion, Adobe recommande (dans la plupart des cas) d’attribuer des droits d’accès aux comptes de groupe. L’attribution des droits d’accès à chaque utilisateur individuel devient rapidement difficile à gérer (les exceptions sont certains utilisateurs système lorsqu’il n’existe qu’une ou deux instances).
Comptes de groupe - Les comptes de groupe sont des collections d’utilisateurs et/ou d’autres groupes. Ils sont utilisés pour simplifier la gestion, car toute modification des droits d’accès affectés à un groupe est appliquée automatiquement à tous les utilisateurs de ce groupe. Un utilisateur ou une utilisatrice n’a pas l’obligation d’appartenir à un groupe, mais il ou elle appartient souvent à plusieurs groupes.
Dans CRX, un groupe possède les propriétés suivantes :
Droits d’accès - CRX utilise les droits d’accès pour contrôler l’accès à des zones spécifiques du référentiel.
Cette opération est effectuée en affectant des autorisations pour autoriser ou refuser l’accès à une ressource (nœud ou chemin d’accès) dans le référentiel. Lorsque différentes autorisations peuvent être affectées, les droits d’accès doivent être évalués afin de déterminer la combinaison qui s’applique à la demande actuelle.
CRX vous permet de configurer les droits d’accès pour les comptes utilisateur et de groupe. Les mêmes principes de base d’évaluation sont alors appliqués aux deux.
CRX implémente le contrôle d’accès tel que défini par JSR-283.
L’installation standard du référentiel CRX est configurée de manière à utiliser des listes de contrôle d’accès dépendant des ressources. Il s’agit d’une implémentation possible du contrôle d’accès JSR-283 et de l’une des implémentations présentes avec Jackrabbit.
CRX utilise deux concepts clés lors de l’évaluation des droits d’accès :
Un principal de sécurité est une entité qui transfère des droits d’accès. Les entités incluent :
Un compte d’utilisateur
Un compte de groupe
Si un compte utilisateur appartient à un ou plusieurs groupes, il est également associé à chacune de ces entités de groupe.
Un objet est utilisé pour représenter la source de la demande.
Il est utilisé pour centraliser les droits d’accès applicables pour cette demande. Ceux-ci proviennent de :
le principal de sécurité de l’utilisateur ;
Les droits affectés directement au compte utilisateur
tous les principaux de sécurité des groupes associés à cet utilisateur.
Tous les droits sont affectés à l’un des groupes auxquels l’utilisateur appartient.
Le résultat est ensuite utilisé pour autoriser ou refuser l’accès à la ressource demandée.
Dans CRX, le sujet dépend de :
La liste des droits d’accès applicables au sujet est établie à partir :
Lorsque CRX gère la demande, il compare la demande d’accès du sujet à la liste de contrôle d’accès sur le noeud du référentiel :
Ainsi, si Linda demande de mettre à jour le nœud /features
dans la structure de référentiel suivante :
Les droits d’accès dans CRX sont évalués comme suit :
Les entités d’utilisateur ou d’utilisatrice ont toujours la priorité sur les entités de groupe, indépendamment de :
Pour une entité de sécurité donnée, il existe (au plus) une entrée de refus et 1 entrée d’autorisation sur un noeud donné. La mise en œuvre efface toujours les entrées redondantes et s’assure que les mêmes autorisations ne figurent pas à la fois dans les entrées d’autorisation et de refus.
Ce processus d’évaluation est approprié pour le contrôle d’accès basé sur les ressources d’une installation CRX standard.
En prenant deux exemples dans lesquels l’utilisateur aUser
est membre du aGroup
:
+ parentNode
+ acl
+ ace: aUser - deny - write
+ childNode
+ acl
+ ace: aGroup - allow - write
+ grandChildNode
Dans le cas ci-dessus :
aUser
ne dispose pas d’une autorisation en écriture sur grandChildNode
. + parentNode
+ acl
+ ace: aUser - deny - write
+ childNode
+ acl
+ ace: aGroup - allow - write
+ ace: aUser - deny - write
+ grandChildNode
Dans ce cas :
aUser
ne dispose pas d’une autorisation en écriture sur grandChildNode
.aUser
est redondante.Les droits d’accès provenant de plusieurs entités de groupe sont évalués en fonction de leur ordre, à la fois dans la hiérarchie et dans une seule liste de contrôle d’accès.
Le tableau ci-dessous contient des recommandations et bonnes pratiques :
Recommandation... | Raison... |
Utilisez des groupes | Évitez d’affecter des droits d’accès utilisateur par utilisateur. Il existe plusieurs raisons à cela :
|
Soyez positif | Utilisez toujours des instructions Autoriser pour spécifier les droits d’accès du principal du groupe (dans la mesure du possible). Évitez d’utiliser une instruction Refuser. Les principaux de groupe sont évalués dans l’ordre, dans la hiérarchie et dans la liste de contrôle d’accès unique. |
Restez simple | Investir du temps et réfléchir lors de la configuration d’une nouvelle installation est payant. L’application d’une structure claire simplifie la maintenance et l’administration en cours, en veillant à ce que vos collègues actuels et/ou futurs successeurs puissent facilement comprendre ce qui est mis en oeuvre. |
Testez | Utilisez une installation de test pour vous exercer et vous assurer que vous comprenez les relations entre les différents utilisateurs et groupes. |
Utilisateurs/groupes par défaut | Mettez toujours à jour les utilisateurs et les groupes par défaut immédiatement après l’installation afin d’éviter tout problème de sécurité. |
Une boîte de dialogue standard est utilisée pour l’administration des utilisateurs.
Vous devez être connecté(e) à l’espace de travail approprié, puis vous pouvez accéder à la boîte de dialogue à partir :
Propriétés
UserID
Nom court du compte utilisé lors de l’accès à CRX.
Principal Name
Nom entier du compte.
Password
Nécessaire lors de l’accès à CRX avec ce compte.
ntlmhash
Affecté automatiquement pour chaque nouveau compte et mis à jour lorsque le mot de passe est modifié.
Vous pouvez ajouter de nouvelles propriétés en définissant un nom, un type et une valeur. Cliquez sur Enregistrer (symbole de coche verte) pour chaque nouvelle propriété.
Appartenance à un groupe
Tous les groupes auxquels appartient le compte s’affichent. La colonne Hérité indique l’appartenance héritée en raison de l’appartenance à un autre groupe.
Cliquer sur un ID de groupe (le cas échéant) ouvre la variable Administration des groupes pour ce groupe.
Emprunteurs d’identité
La fonction Emprunter l’identité permet à un utilisateur ou une utilisatrice de travailler sous le nom d’un(e) autre.
Cela signifie qu’un compte utilisateur peut spécifier d’autres comptes (utilisateur ou groupe) compatibles avec son compte. En d’autres termes, si l’utilisateur B est autorisé à emprunter l’identité de l’utilisateur A, l’utilisateur B peut agir en utilisant les détails complets du compte de l’utilisateur A (y compris l’identifiant, le nom et les droits d’accès).
Cela permet aux comptes d’emprunteur d’identité d’effectuer des tâches comme s’ils utilisaient le compte qu’ils empruntent ; par exemple, en cas d’absence, ou de partager une charge excessive à court terme.
Si un compte emprunte l’identité d’un autre compte, il est difficile de le voir. Les fichiers journaux ne contiennent pas d’informations sur le fait que l’emprunt de l’identité s’est produit lors des événements. Ainsi, si l’utilisateur B emprunte l’identité de l’utilisateur A, tous les événements peuvent ressembler à s’ils ont été effectués par l’utilisateur A personnellement.
Ouvrez la boîte de dialogue Administration des utilisateurs.
Cliquez sur Créer un utilisateur.
Vous pouvez ensuite saisir les Propriétés :
Cliquez sur Enregistrer (symbole de coche verte).
La boîte de dialogue est développée afin que vous puissiez effectuer les opérations suivantes :
Une perte de performances peut parfois être constatée lors de l’enregistrement de nouveaux utilisateurs ou de nouvelles utilisatrices dans des installations comportant un grand nombre :
Cette action supprime le nœud de cette entité du référentiel.
Les entrées de droit d’accès ne sont pas supprimées. Cela permet de s’assurer de l’intégrité de l’historique.
Vous pouvez définir des propriétés pour les comptes nouveaux ou existants :
Les propriétés existantes peuvent être supprimées avec le symbole de la corbeille.
A l’exception du mot de passe, les propriétés ne peuvent pas être modifiées. Elles doivent être supprimées et recréées.
La variable Password est une propriété spéciale qui peut être modifiée en cliquant sur la propriété Modifier le mot de passe lien.
Vous pouvez également modifier le mot de passe de votre propre compte utilisateur à partir du menu Sécurité dans l’Explorateur CRX.
Vous pouvez définir des emprunteurs d’identité pour les comptes nouveaux ou existants :
Ouvrez la boîte de dialogue Administration des utilisateurs pour le compte approprié.
Indiquez le compte autorisé à emprunter l’identité de ce compte.
Vous pouvez utiliser Parcourir… pour sélectionner un compte existant.
Cliquez sur Enregistrer (symbole de coche verte) pour la nouvelle propriété.
Une boîte de dialogue standard est utilisée pour l’administration des groupes.
Vous devez être connecté(e) à l’espace de travail approprié, puis vous pouvez accéder à la boîte de dialogue à partir :
Propriétés
GroupID
Nom abrégé du compte de groupe.
Principal Name
Nom textuel entier pour le compte de groupe.
Vous pouvez ajouter de nouvelles propriétés en définissant un nom, un type et une valeur. Cliquez sur Enregistrer (symbole de coche verte) pour chaque nouvelle propriété.
Members
Vous pouvez ajouter des utilisateurs, ou d’autres groupes, en tant que membres de ce groupe.
Appartenance à un groupe
Tous les groupes auxquels appartient le compte s’affichent. La colonne Hérité indique l’appartenance héritée en raison de l’appartenance à un autre groupe.
Cliquez sur un ID de groupe pour ouvrir la boîte de dialogue correspondante.
Membres
Répertorie tous les comptes (utilisateurs, utilisatrices et/ou groupes) qui sont membres du groupe actuel.
La colonne Hérité indique l’appartenance héritée en raison de l’appartenance à un autre groupe.
Lorsque le rôle Propriétaire, Éditeur ou Observateur est attribué à un utilisateur sur n’importe quel dossier de ressources, un nouveau groupe est créé. Le nom du groupe utilise le format mac-default-<foldername>
pour chaque dossier sur lequel les rôles sont définis.
Ouvrez le Administration des groupes de la boîte de dialogue
Cliquez sur Créer un groupe.
Vous pouvez ensuite saisir les Propriétés :
Cliquez sur Enregistrer (symbole de coche verte).
La boîte de dialogue est développée afin que vous puissiez :
Cette action supprime le nœud de cette entité du référentiel.
Les entrées de droit d’accès ne sont pas supprimées. Cela permet de s’assurer de l’intégrité de l’historique.
Vous pouvez définir des propriétés pour les comptes nouveaux ou existants :
Les propriétés existantes peuvent être supprimées avec le symbole de la corbeille.
Vous pouvez ajouter des membres au groupe actuel :
Ouvrez la boîte de dialogue Administration des groupes pour le compte approprié.
Vous pouvez :
Cliquez sur Enregistrer (symbole de coche verte) pour la nouvelle propriété.
Vous pouvez également supprimer un membre existant avec le symbole de la corbeille.
Avec la variable Contrôle d’accès dans l’onglet de CRXDE Lite, vous pouvez définir les stratégies de contrôle d’accès et attribuer les privilèges associés.
Par exemple, pour Chemin actuel sélectionnez la ressource requise dans le volet de gauche, l’onglet Contrôle d’accès dans le volet inférieur droit :
Les politiques sont classées en fonction des éléments suivants :
Politiques de contrôle d’accès applicables
Ces politiques peuvent être appliquées.
Ce sont les politiques disponibles pour créer une politique locale. Lorsque vous sélectionnez et ajoutez une stratégie applicable, elle devient une stratégie locale.
Politiques de contrôle d’accès locales
Il s’agit des politiques de contrôle d’accès que vous avez appliquées. Vous pouvez les mettre à jour, les trier ou les supprimer.
Une stratégie locale remplace toute stratégie héritée du parent.
Politiques de contrôle d’accès actuelles
Ce sont les politiques de contrôle d’accès désormais en vigueur pour toutes les demandes d’accès. Elles affichent les politiques agrégées dérivées des politiques locales et des politiques héritées du parent.
Les politiques peuvent être sélectionnées pour les éléments suivants :
Chemin d’accès actuel
Comme dans l’exemple ci-dessus, sélectionnez une ressource dans le référentiel. Les stratégies de ce "chemin actuel" s’affichent.
Référentiel
Sélectionne le contrôle d’accès au niveau du référentiel. Par exemple, lors de la définition de l’autorisation jcr:namespaceManagement
, qui n’est appropriée que pour le référentiel, et non pour le nœud.
Principal de sécurité
Principal de sécurité enregistré dans le référentiel.
Vous pouvez saisir le Principal nommez ou cliquez sur l’icône située à droite du champ pour ouvrir le Sélectionner l’entité de sécurité de la boîte de dialogue
Cela vous permet de : Rechercher pour un Utilisateur ou Groupe. Sélectionnez l’entité requise dans la liste qui en résulte, puis cliquez sur OK pour rétablir la valeur dans la boîte de dialogue précédente.
Pour simplifier l’Adobe de gestion, vous devez attribuer des droits d’accès aux comptes de groupe, et non à des comptes d’utilisateur individuels.
Il est plus facile de gérer quelques groupes que de nombreux comptes utilisateurs.
Les autorisations ci-dessous peuvent être sélectionnées lors de l’ajout d’une entrée de contrôle d’accès (pour plus d’informations, voir API de sécurité) :
Nom de l’autorisation | Qui contrôle l’autorisation pour... |
---|---|
jcr:read |
Récupérer un nœud et lire ses propriétés et leurs valeurs |
rep:write |
Il s’agit d’un privilège agrégé spécifique à Jackrabbit de jcr:write et jcr:nodeTypeManagement. |
jcr:all |
Il s’agit d’une autorisation agrégée qui contient tous les autres privilèges prédéfinis. |
Avancé | |
crx:replicate |
Effectuer la réplication d’un nœud |
jcr:addChildNodes |
Créer les nœuds enfants d’un nœud |
jcr:lifecycleManagement |
Effectuer des opérations de cycle de vie sur un nœud |
jcr:lockManagement |
Verrouiller et déverrouiller un nœud ; actualiser un verrou |
jcr:modifyAccessControl |
Modifier les politiques de contrôle d’accès d’un nœud |
jcr:modifyProperties |
Créez, modifiez et supprimez les propriétés d’un noeud. |
jcr:namespaceManagement |
Enregistrez, annulez l’enregistrement et modifiez les définitions d’espace de noms. |
jcr:nodeTypeDefinitionManagement |
Importer des définitions de type de nœud dans le référentiel |
jcr:nodeTypeManagement |
Ajouter et supprimer des types de nœuds mixin et modifier le type de nœud principal d’un nœud Cela inclut également les appels de Node.addNode et les méthodes d’importation XML, dans lesquels le type mixin ou principal du nouveau nœud est spécifié explicitement. |
jcr:readAccessControl |
Lire la politique de contrôle d’accès d’un nœud |
jcr:removeChildNodes |
Supprimer les nœuds enfants d’un nœud |
jcr:removeNode |
Supprimer un nœud |
jcr:retentionManagement |
Effectuer des opérations de gestion de la rétention sur un nœud |
jcr:versionManagement |
Exécuter des opérations de contrôle de version sur un nœud |
jcr:workspaceManagement |
Créer et supprimer des espaces de travail via l’API JCR |
jcr:write |
Il s’agit d’une autorisation agrégée qui contient : - jcr:modifyProperties - jcr:addChildNodes - jcr:removeNode - jcr:removeChildNodes |
rep:privilegeManagement |
Inscrivez un nouveau privilège. |
Vous pouvez également enregistrer de nouvelles autorisations :
Dans la barre d’outils, sélectionnez Outils, puis Privilèges pour afficher les privilèges actuellement enregistrés.
Utilisez la variable Privilège d’enregistrement icône (+) afin que vous puissiez définir un privilège :
Cliquez sur OK pour enregistrer. Le privilège peut désormais être sélectionné.
Sélectionnez votre ressource et ouvrez l’onglet Contrôle d’accès.
Pour ajouter une politique de contrôle d’accès locale, cliquez sur l’icône + à droite de la liste Politique de contrôle d’accès applicable :
Une nouvelle entrée s’affiche sous Politiques de contrôle d’accès locales :
Cliquez sur le bouton + pour ajouter une entrée :
Actuellement, une solution de contournement est nécessaire pour spécifier une chaîne vide.
Pour cela, vous devez utiliser ""
.
Définissez votre politique de contrôle d’accès et cliquez sur OK pour l’enregistrer. Votre nouvelle stratégie est la suivante :
CRX valide votre sélection ; pour une entité de sécurité donnée, il existe (au plus) une entrée de refus et une entrée d’autorisation sur un noeud donné. La mise en œuvre efface toujours les entrées redondantes et s’assure que les mêmes autorisations ne figurent pas à la fois dans les entrées d’autorisation et de refus.
L’ordre dans la liste indique l’ordre dans lequel les politiques sont appliquées.
Dans le tableau de Stratégies de contrôle d’accès locales, sélectionnez l’entrée requise et faites-la glisser vers le nouvel emplacement du tableau.
Les modifications sont affichées dans les deux tableaux pour la variable Local et la variable Stratégies de contrôle d’accès efficaces.
Dans la barre d’outils du CRXDE Lite, sélectionnez Outils, puis Tester le contrôle d’accès….
Une nouvelle boîte de dialogue s’ouvre dans le volet supérieur droit. Sélectionnez le chemin d’accès et/ou le principal de sécurité à tester.
Cliquez sur Test pour afficher les résultats de votre sélection :