accessRightsSettings_fr

SLDR —> SldrWiki —> SLDR_FR —> SLDR : bonnes pratiques... —> Gestion des droits d'accès

Same page in English

Réglage des droits d'accès

---

Attributs d'accès des documents

Statut

• Un document numérique, représenté par un fichier (ou de manière équivalente par un datastream), peut être accessible sans aucune restriction au téléchargement. Son statut est alors public.
• Dans le cas contraire (statut privé) il n'est accessible que sous certaines conditions : identification de l'utilisateur, attribution de cet utilisateur à un groupe, et autorisations données à ce groupe par le producteur de l'objet qui contient le document.
• Les mécanismes d'identification et d'autorisation ne sont pas exposés ici. Le seul objet du réglage des droits d'accès est de déterminer le statut public/privé de chaque document.
• Remarquer que nous ne faisons pas de distinction entre le téléchargement d'un fichier et sa réception en mode streaming. N'importe quel document audio/vidéo diffusé en streaming peut en effet être capturé par un logiciel et sauvegardé sous la forme d'un fichier.

Derogation et durée

• Comme expliqué sur la page Gestion des droits d’accès en accord avec le Code du patrimoine, tout document stocké dans une archive publique doit être public par défaut. Toutefois, un certain nombre de dérogations au principe de libre diffusion ont été prévues par la loi.
• Ces dérogations sont codées conformément aux catégories définies par les Archives de France. La catégorie d'un document public est AR038. Chacune des catégories correspond à une autorisation de restriction d'accès limitée par une durée exprimée en années. Par exemple, la catégorie AR042 autorise une période d'embargo de 25 ans.

Date de début de la dérogation (derogation start-date)

• Cette date est par défaut celle de la création du document.
• Connaissant cette date et la durée de la dérogation fixée par la loi, le système est en mesure de calculer la date de fin de la dérogation.

Autorisation

• Cet attribut (yes/no) indique l'existence d'une autorisation de diffusion signée par les personnes ayant participé à l'élaboration du document. (Ces autorisations doivent aussi être archivées.)

Date de début de l'autorisation (autorisation start-date)

• En général il s'agit de la date de signature de l'autorisation, mais un participant peut exiger que la diffusion commence à une date ultérieure. (C'est le cas de documents soumis à une période d'embargo pour exploitation commerciale.)

Date de fin de l'autorisation (autorisation end-date)

• Un participant peut donner une date de fin de validité de son autorisation. (Une renégociation du contrat peut être envisagée dans ce cas.)

Identifiant d'autorisation

• Information brève et précise permettant de localiser l'autorisation concernant le document (optionnel).

Commentaire

• Brève explication concernant le choix des attributs de gestion des accès à ce document (optionnel).

---

Comment spécifier les attributs d'accès

• Bien qu'il soit possible de spécifier les attributs d'accès de chaque document (voir ci-dessous : édition de la table de correspondance), des mécanismes sont prévus pour donner les mêmes attributs à tous les documents d'un répertoire et permettre leur transmission par héritage aux éléments situés plus bas dans l'arborescence de l'objet. Ces mécanismes peuvent être mis en œuvre par défaut pour l'ensemble des documents de l'objet, pendant la phase de mise en forme d'un objet (packaging), après son indexation, ou avant l'exportation de métadonnées vers le service d'archivage.
• La mise à jour de métadonnées permet de réviser entièrement les conditions d'accès sans procéder au dépôt d'une nouvelle version de l'objet. Ces métadonnées ne sont pas utilisées par le service d'archivage ; transmises au service de diffusion, elles sont utilisées par un gestionnaire qui modifie les droits d'accès aux datastreams du serveur Fedora Commons utilisé pour la diffusion.
• Seuls le propriétaire de l'objet, les personnes spécialement autorisées et les administrateurs peuvent modifier les attributs.

Mécanisme d'héritage : tout fichier ou répertoire hérite des attributs du répertoire qui le contient, sauf pour les attributs spécifiés à son niveau. Cette règle ne s'applique pas aux attributs Identifiant d'autorisation et Commentaire.

Spécification par défaut (au niveau de l'objet)

• Elle est saisie immédiatement après la création de la fiche. Les fenêtres d'édition des paramètres sont visibles sur la fiche descriptive de l'objet lorsqu'un utilisateur est identifié comme le propriétaire, une personne spécialement autorisée ou un administrateur.

• À ce niveau on définit :

  • la catégorie de dérogation ;
  • la date de début de la dérogation: en l'absence d'information le système utilise la date de dépôt de l'objet ;
  • les dates de début et de fin de l'autorisation (optionnel). La présence d'une date de début signifie qu'une autorisation est existante. Remarquer sur la figure que les noms de fichiers des autorisations sont automatiquement affichés si celles-ci ont été rangées dans le répertoire §autorisations correspondant à l'objet.

Spécification à la mise en forme de l'objet

• L'agencement des documents dans l'arborescence d'un objet peut être utilisé pour modifier les attributs d'accès. Il suffit pour cela d'attribuer des noms particuliers aux répertoires concernés :

  • Tous les éléments contenus dans un répertoire nommé 'PUBLIC' ou 'stream' ou '(stream)' ont pour statut public.
  • Tous les éléments contenus dans un répertoire nommé 'PRIVATE' ou héritent directement des attributs par défaut de l'objet, et leur statut est privé.
  • Tous les éléments contenus dans un répertoire nommé 'SECRET' ou '(SECRET)' ont pour code de dérogation AR048, leur statut est privé et les noms de fichiers sont masqués aux utilisateurs.

Spécification après indexation (au niveau des répertoires)

• Un utilisateur identifié comme le propriétaire d'un objet, ou un administrateur, peuvent afficher l'arborescence des documents contenus à la source de l'objet. (Cette arborescence a pu être modifiée depuis le dernier dépôt de l'objet au service d'archivage.)
• Le système crée automatiquement, dans chaque répertoire de l'arborescence, un fichier accessRights.xml qui contient les attributs de d'accès à appliquer aux éléments de ce répertoire.
• Un bouton 'edit' ouvre un formulaire qui permet de modifier les attributs du répertoire :

• Le fichier accessRights.xml contenant ces informations est accessible dans l'archive via une URL pérenne, exemple http://sldr.org/crdo000019_v4/get/DESC_accessRights5.xml.

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE accessRights [
<!ELEMENT accessRights (path,status,derogation,derogation_startdate,autorisation,autorisation_startdate,autorisation_enddate,autorisation_identifier,comment)>
<!ELEMENT path (#PCDATA)>
<!ELEMENT status (#PCDATA)>
<!ELEMENT derogation (#PCDATA)>
<!ELEMENT derogation_startdate (#PCDATA)>
<!ELEMENT autorisation (#PCDATA)>
<!ELEMENT autorisation_startdate (#PCDATA)>
<!ELEMENT autorisation_enddate (#PCDATA)>
<!ELEMENT autorisation_identifier (#PCDATA)>
<!ELEMENT comment (#PCDATA)>
]>
<accessRights>
<path>crdo000019/§autorisations/(SECRET)/accessRights.xml</path>
<status>private</status>
<derogation>AR048</derogation>
<derogation_startdate>2010-03-16</derogation_startdate>
<autorisation>no</autorisation>
<autorisation_startdate></autorisation_startdate>
<autorisation_enddate></autorisation_enddate>
<autorisation_identifier></autorisation_identifier>
<comment>Privacy of speakers' names</comment>
</accessRights>

• La règle d'héritage s'applique : si un attribut n'est pas spécifié dans le formulaire, sa valeur reste la même qu'au niveau supérieur de l'arborescence.

Spécification avant exportation (au niveau des fichiers)

• Avant de produire les paquets d'information à verser (SIP, Submission Information Packages), le système construit un tableau de correspondances (mapping.txt) qui contient entre autres tous les attributs d'accès aux fichiers/datastreams (documents), que ces attributs aient été spécifiés ou obtenus par héritage à partir des spécifications entrées par les moyens précédents. Ce tableau peut être édité en vue de modifier les attributs individuels.

• Les modifications peuvent être faites à deux occasions :

  • par les administrateurs au moment du dépôt de l'objet en archive, après la copie des objets à verser dans l'espace de versement et avant la production des SIPs ;
  • par le propriétaire de l'objet ou un administrateur, à n'importe quel moment. Dans ce cas, les modifications sont prises en compte par le service de diffusion après l'envoi d'une mise à jour de métadonnées. Le système génère automatiquement une alerte qui permettra aux administrateurs d'expédier cette mise à jour sans être avertis par les propriétaires.
• Important : cette méthode est la seule qui permette de modifier les droits d'accès à des documents archivés dans des versions plus anciennes de l'objet.

• Un exemple de tableau en cours d'édition est donné ici : crdo000714map-edit.pdf (fichier PDF). Ci-contre, un extrait montrant les premiers documents et quelques problèmes à corriger pour mettre la diffusion en conformité avec le Code du patrimoine :

  • Les 4 fichiers MP3 au sommet du tableau ont été réglés en accès restreint (private) alors que, sauf indication contraire, ils bénéficient d'une autorisation de diffusion signée le 12/9/2010. Cette date apparaît entre parenthèses parce que sa valeur est héritée des attributs par défaut de l'objet.
  • La non-conformité est signalée par la couleur rouge de la mention public dans la colonne de droite ; elle signifie que le statut devrait être basculé en public. Autre option : renseigner différemment les spécifications d'existence et de dates des autorisations si une négociation particulière a été menée pour ce qui concerne la diffusion des enregistrements.
  • Le fichier zip (5e ligne) est dans le même cas de figure que les fichiers MP3 puisqu'il ne fait que les regrouper.
  • Les 5 fichiers suivants (format WAV) ne sont pas téléchargeables en raison de l'absence d'une autorisation concernant les fichiers sonores en "haute résolution". La diffusion en MP3 (ou AAC) de leur contenu est suffisante pour assurer le caractère public du contenu des enregistrements, dans la mesure où ces fichiers haute résolutions sont accessibles aux chercheurs moyennant le suivi par une licence non-commerciale. La conformité est confirmée par l'apparition en vert du statut private dans la colonne de droite.
• Les dispositions prises pour la mise en conformité des conditions d'accès peuvent être documentées dans les champs Comment (maintenant disponibles dans les 4 langues de navigation).

• Au sommet du tableau s'affiche un résultat global qui comprend la date de la prochaine révision des droits d'accès ainsi que le pourcentage de documents qui, dans l'état actuel des attributs, respectent les prérogatives du Code du patrimoine :

  • Deadline for setting item access attributes (in this version): 2060-09-12
  • Item compliance (in this version): 68%
• Pour faciliter l'édition des attributs, la première ligne (sur fond jaune) permet d'entrer des valeurs qui sont ensuite copiées, soit dans l'ensemble des lignes du tableau, soit sur les lignes sélectionnées dans la colonne Copy down.

---

L'affichage des attributs d'accès

• Lorsqu'on affiche la liste des fichiers à télécharger (table of contents), par exemple http://sldr.org/crdo000019/toc/fr, des liens de deux sortes sont automatiquement ajoutés aux noms des fichiers :

  • Les liens comme ceux des fichiers [13] et [14] sont ceux des fichiers en libre accès. Ils lancent des requêtes de téléchargement direct des datastreams à partir du service de diffusion.
  • Les liens comme ceux des fichiers [17] à [27] sont ceux des fichiers en accès réservé. Ils ne permettent aucun téléchargement, mais le passage de la souris affiche une bulle contenant l'explication de cette restriction : code de la dérogation, texte du Code du patrimoine (dans la langue de navigation), date d'échéance de cette dérogation, et le cas échéant texte du champ Comment correspondant à ce fichier.

---

Exemple de modification des attributs d'accès

• Nous traitons le cas d'un corpus déjà archivé dont les droits d'accès doivent être ajustés via une mise à jour de métadonnées.
• Ces droits d'accès concernent la version courante (et les versions ultérieures) de l'objet. Toutefois, la modification directe des attributs dans le tableau de correspondance des fichiers permet de modifier les droits d'accès sur les versions antérieures.
• L'utilisateur est identifié comme le propriétaire de l'objet, un administrateur ou une personne spécialement autorisée.

Corrections à la source (au niveau des répertoires)

• On pourrait éditer directement les attributs d'accès dans le tableau de correspondance des fichiers. Toutefois, dans ce cas, l'opération devrait être répétée à chaque dépôt d'une nouvelle version. (L'éditeur du tableau offre pour cela la possibilité de recopier les attributs de la version antérieure pour tout fichier dont le chemin n'a pas été modifié.)
• Sur la fiche descriptive de l'objet apparaît un bouton List of source files (ou son équivalent dans une autre langue de navigation) :

• En cliquant ce bouton, on affiche l'arborescence des fichiers à la source. La suite de l'opération ne sera fiable que si cette arborescence n'a pas été modifiée depuis l'archivage de la dernière version de l'objet.

• Au bas de l'arborescence figure un bouton Update this index. Une fois qu'il a été cliqué, l'affichage de l'arborescence rendra visibles les fichiers accessRights.xml qui ont été automatiquement insérés lors de la première exécution de cette opération (voir ci-contre).
• Ces fichiers accessRights.xml ne contiennent que des attributs vides. En l'absence de spécification, leur valeur est calculée à partir des attributs globaux de droits d'accès pour l'objet.

• Les attributs globaux de droits d'accès pour l'objet sont ici :

  • Derogation AR048

  • Autorisations de diffusion, date de début :

    • Thomas : 2010-09-17
    • Eva : 2010-09-24
    • Claire : 2010-12-25
    • Gaël : 2009-06-02
  • Comme attribut global on prendra la date d'autorisation la plus récente, donc 2010-12-25. Nous verrons comment ajuster les dates au niveau des fichiers lorsque nécessaire.
• La fiche descriptive de l'objet révèle que le pourcentage de compatibilité des attributs d'accès avec le Code du patrimoine est seulement de 68%. Il est donc nécessaire de modifier certains attributs.
• Les accès qui posent problème sont indiqués en rouge sur le tableau de correspondance des fichiers. Ce tableau est accessible à tout utilisateur identifié via le lien http://sldr.org/crdo000714_v2/map. Le tableau complet est ici (format PDF) : http://sldr.org/doc/show/wiki/tableau-entier-crdo000714.pdf
• Les parties à corriger :

• => Fichiers audio au format MP3 (basse résolution) : les autorisations permettent de les basculer en public, sauf le fichier 'zip' donnant accès à un téléchargement en bloc, qui n'a pas été formellement autorisé.

• => Formulaires anonymisés d'autorisation de diffusion. L'autorisation ne concerne pas le formulaire en lui-même. On les laissera donc en private.
• Pour modifier ces droits d'accès on clique les boutons 'edit' apparaissant sur l'arborescence des fichiers source.
• Correction des droits pour les fichiers MP3 (bouton 3) :

• Correction des droits pour les formulaires d'autorisation (bouton 8) :

• Le problème du fichier 'zip' n'est pas réglé car cette méthode s'applique aux répertoires et pas aux fichiers isolés. Nous le règlerons dans le tableau de correspondance des fichiers.

• Les modifications d'attributs ont été automatiquement reportées dans le tableau de correspondance des fichiers de la version courante de l'objet. Toutefois, tant que la mise à jour des métadonnées n'a pas été déposée au service d'archivage, les conditions d'accès sont inchangées sur le service de diffusion. On peut le constater en affichant la table des matières qui a elle aussi été mise à jour : http://sldr.org/crdo000714_v2/toc (voir ci-contre à droite) :

  • En passant la souris sur le fichier [29] on affiche bien la bulle expliquant les raisons de l'interdiction d'accès.
  • Par contre, alors que les fichiers [4], [5], [6], [7] apparaissent en libre accès, en cliquant sur le lien on obtient un message d'erreur du service de diffusion (voir ci-contre à gauche).
• Il est donc urgent de transmettre au service de diffusion les modifications qui ont été saisies. À cet effet, un drapeau de mise à jour de métadonnées a été automatiquement généré dans une file d'attente traitée par les administrateurs. Il est recommandé de les contacter personnellement pour que la procédure soit lancée. Les mises à jour de métadonnées ne transmettent qu'un petit nombre de fichiers de petite taille et sont donc traitées très rapidement par le système OAIS.

Corrections dans le tableau de correspondance (au niveau des documents)

• Après les modifications au niveau des répertoires, le pourcentage de compatibilité entre les droits d'accès et le Code du patrimoine est à 98%. Le tableau de correspondance est ici (format PDF) : http://sldr.org/doc/show/wiki/nouveau-tableau-crdo000714.pdf.
• Pour parvenir à 100% il faudra justifier la non-diffusion des fichiers 'zip'.
• Le tableau fait apparaître d'autre part des dates d'autorisation qui ne correspondent pas à celles inscrites sur les formulaires de consentement.
• Comme précédement, seuls le propriétaire de l'objet, les administrateurs et les personnes spécialement autorisées peuvent modifier les attributs d'accès. Il est donc nécessaire de s'identifier pour suivre les liens indiqués.

Individualisation des dates d'autorisation

• Le lien http://sldr.org/crdo000714/map affiche le tableau de correspondance. Cliquer le lien permettant d'afficher le tableau en entier. Si l'on est autorisé à entrer des modifications, un lien 'edit' apparaît qui permet d'accéder à l'éditeur du tableau.
• Il suffit d'entrer les dates correctes dans le champ Autorisation start puis de cliquer le bouton "enregistrer".

Justifications concernant les fichiers 'zip'

• Dans le tableau de correspondance, inscrire "no" dans le champ Autorisation et inscrire la justification : "Le téléchargement en bloc est réservé aux utilisateurs identifiés.
• En cochant les cases de la colonne Copy down il n'est pas nécessaire de répéter les saisies car elles seront automatiquement copiées :

• Après cette opération, la compatibilité est devenue de 100% et aucune mention public/private n'est affichée en rouge.

Mise à jour des métadonnées

• Cette opération (qui doit être finalisée par un administrateur) transmet aux services d'archivage et de diffusion une mise à jour du contenu du répertoire DEPOT/DESC qui comprend (entre autres) les métadonnées descriptives, des fichiers de description archivables, les scans des autorisations de diffusion et les fichiers accessRights.xml qui viennent d'être modifiés. (Pour plus de détails, voir http://sldr.org/ppdi.)
• La configuration actuelle du service de diffusion (grille Adonis au CC-IN2P3) ne permet pas de transmettre des documents via le répertoire DIFFUSION lors d'une mise à jour de métadonnées. Il serait souhaitable que cette option soit offerte car ce répertoire contient tous les fichiers aux formats non-archivables, comme les fichiers MP3 dans notre exemple.
• Le service ne traite pas les fichiers accessRights.xml dans la version actuelle, mais leur archivage est important pour une reconstruction éventuelle de la source de l'archive. Un fichier public.xml est donc transmis à ce service, contenant la liste de tous les datastreams (documents) qui doivent être en libre accès.
• La génération du SIP (Submission Information Package) correspondant à cette mise à jour de métadonnées peut être lancée par le propriétaire de l'objet, un utilisateur privilégié ou un administrateur. Un bouton send apparaît en effet au-dessus du menu de gauche pour toute mise à jour en attente :

• Le SIP est un répertoire (voir ci-contre) contenant les fichiers descriptifs à expédier au service de diffusion via le service d'archivage. Pendant sa création, une trace des opérations est affichée. Ci-dessous la trace concernant la mise à jour de crdo000714 traitée en exemple :

• Dans la trace ci-dessus, remarquer le changement de statut vers "public" des 4 fichiers MP3 (marquage en rouge) : DIFFUSION_SOURCE_claire.mp3 etc. Les datastreams correspondants seront inclus au fichier public.xml qui est utilisé par le service de diffusion pour ouvrir certains accès. Le nouveau fichier public.xml se présente ainsi :

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE public [
<!ELEMENT public (datastream+)>
<!ELEMENT datastream (#PCDATA)>
]>
<public>
<datastream>DEPOT_DESC_mapping.txt</datastream>
<datastream>cinyras.xml</datastream>
<datastream>DEPOT_DESC_olac.xml</datastream>
<datastream>DEPOT_DESC_version.xml</datastream>
<datastream>DEPOT_DESC_accessRights1.xml</datastream>
<datastream>DEPOT_DESC_accessRights2.xml</datastream>
<datastream>DEPOT_DESC_accessRights3.xml</datastream>
<datastream>DEPOT_DESC_accessRights4.xml</datastream>
<datastream>DEPOT_DESC_accessRights5.xml</datastream>
<datastream>DEPOT_DESC_accessRights6.xml</datastream>
<datastream>DEPOT_DESC_accessRights7.xml</datastream>
<datastream>DEPOT_TRANSCRIPTIONS_DG-E_Claire.pdf</datastream>
<datastream>DEPOT_TRANSCRIPTIONS_DG-E_Eva.pdf</datastream>
<datastream>DEPOT_TRANSCRIPTIONS_DG-E_Gael.pdf</datastream>
<datastream>DEPOT_TRANSCRIPTIONS_DG-E_Thomas.pdf</datastream>
<datastream>DIFFUSION_TRANSCRIPTIONS.zip</datastream>
<datastream>DEPOT_DESC_accessRights8.xml</datastream>
<datastream>DEPOT_DESC_accessRights9.xml</datastream>
<datastream>DIFFUSION_33.mp3</datastream>
<datastream>DIFFUSION_34.mp3</datastream>
<datastream>DIFFUSION_35.mp3</datastream>
<datastream>DIFFUSION_36.mp3</datastream>
<datastream>DIFFUSION_37.jpg</datastream>
<datastream>DIFFUSION_38.jpg</datastream>
<datastream>DIFFUSION_SOURCE_claire.mp3</datastream>
<datastream>DIFFUSION_SOURCE_eva.mp3</datastream>
<datastream>DIFFUSION_SOURCE_gael.mp3</datastream>
<datastream>DIFFUSION_SOURCE_thomas.mp3</datastream>
</public>

• Après la création du SIP apparaissent dans le menu de gauche (voir ci-contre):

  • Un lien vers le tableau de correspondance (mapping) qui peut être encore modifié (peu recommandable) ;
  • Un bouton delete qui permet d'annuler l'opération de création du SIP. Cette annulation est nécessaire si des modifications ont été faites dans les métadonnées descriptives ou les attributs d'accès.
• Les administrateurs ont la charge de verser les SIP au système d'archivage après un contrôle éventuel de leur validité.