6. Gestion des habilitations

6.1. Introduction

6.1.1. Documents de référence

Document

Date de la version

Remarques

NF Z 44022 – MEDONA – Modélisation des données pour l’archivage

18/01/2014

Standard d’échange de données pour l’archivage – SEDA – v. 2.1

06/2018

Standard d’échange de données pour l’archivage – SEDA – v. 2.2

02/2022

Cette nouvelle version du SEDA est intégrée à la solution logicielle Vitam à partir de la V6.RC.

Standard d’échange de données pour l’archivage – SEDA – v. 2.3

06/2023

Vitam – Structuration des Submission Information Package (SIP)

Vitam – Documentation d’installation

Vitam – Documentation d’exploitation

Vitam – Gestion de multiples stratégies de stockage

6.1.2. Présentation du document

Le document présente les fonctionnalités associées à la gestion et à l’utilisation des habilitations dans la solution logicielle Vitam.

Il s’articule autour des axes suivants :

  • une présentation des différentes habilitations : certificat applicatif, certificat personnel, profil de sécurité, contexte applicatif, contrat d’entrée, contrat d’accès, et de la manière dont le Standard d’échanges de données pour l’archivage (SEDA) et le modèle de données de la solution logicielle Vitam sont utilisés pour les formaliser ;

  • une présentation des mécanismes mis en œuvre dans la solution logicielle Vitam pour gérer ces habilitations ;

  • des recommandations aux ministères porteurs, partenaires et utilisateurs de la solution logicielle Vitam sur la manière d’utiliser les fonctionnalités associées à ces habilitations. Le présent document décrit les fonctionnalités qui seront offertes par la première version de production de la solution logicielle Vitam au terme de la version 6 (mars 2023). Il a vocation à être amendé, complété et enrichi au fur et à mesure de la réalisation de la solution logicielle Vitam et des retours et commentaires formulés par les ministères porteurs et les partenaires du programme.

6.2. Administration des habilitations

Les habilitations sont l’ensemble des droits et permissions attribués par la solution logicielle Vitam à une application externe et permettant à cette dernière d’accéder aux différents services proposés par la solution logicielle Vitam.

La solution logicielle Vitam met à disposition un ensemble d’outils permettant de gérer les habilitations :

  • les certificats applicatifs et les certificats personnels ;

  • les contextes applicatifs, les profils de sécurité, les contrats d’entrée et les contrats d’accès.

6.2.1. Certificat applicatif

6.2.1.1. Description

Le certificat applicatif correspond à une carte d’identité numérique. Il permet d’identifier et d’authentifier une application souhaitant accéder aux services de la solution logicielle Vitam.

Pour ce faire, il doit être obligatoirement :

  • déclaré dans la solution logicielle Vitam ;

  • associé à au moins un contexte applicatif.

6.2.1.2. Formalisation

Les certificats applicatifs sont enregistrés dans la base de données MongoDB, dans la collection « Certificate », sous la forme d’enregistrements au format JSON. Enregistrement d’un certificat :

{
    "_id": "aeaaaaaaaahgnmn7aac46almhn4jtsiaaaaq",
    "SubjectDN": "EMAILADDRESS=support@programmevitam.fr, CN=vitam-vitam, OU=Vitam, O=Vitam, L=Paris, ST=IDF, C=FR",
    "ContextId": "CT-000001",
    "SerialNumber": "4",
    "Certificate": "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUdJVENDQkFtZ0F3SUJBZ0lCQkRBTkJna3Foa2lHOXcwQkFRc0ZBRENCa3pFTE1Ba0dBMVVFQmhNQ1JsSXgKRERBS0JnTl[...]ZZRXR0RXdCS0c3dTgyQ0FjUVE2cS9JQWQxV0gvTS9sbDM1Qwo3NGVqSWxSSWk0YmRxcklaYlFjdVB4UEpQRTZEdE5nNDlYemlQUWJuWnhFREtBNE1zQT09Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0=",
    "IssuerDN": "EMAILADDRESS=support@programmevitam.fr, CN=vitam-root-ca-vitam, OU=Vitam, O=Vitam, L=Paris, ST=IDF, C=FR",
    "Status": "VALID",
   "ExpirationDate": "2025-01-30T22:13:43.000"
}

Un certificat applicatif doit comporter les éléments suivants[1] :

Champ

Description

_id

identifiant unique dans l’ensemble du système, fourni par ce dernier (champ obligatoire).

SubjectDN

identifiant unique du certificat applicatif ou Distinguished Name (champ obligatoire).

ContextId

identifiant signifiant du contexte applicatif associé au certificat applicatif (champ obligatoire).

SerialNumber

numéro de série du certificat applicatif (champ obligatoire).

IssuerDN

identifiant unique ou Distinguished Name de l’autorité de certification (champ obligatoire).

Certificate

clé du certificat applicatif (champ obligatoire).

Status

statut du certificat applicatif (champ obligatoire) :
- Si le certificat est valide et actif, le statut a pour valeur « VALID » ;
- Si le certificat a été révoqué, le statut a pour valeur « REVOKED »,
- Si le certificat est expiré, le statut a pour valeur « EXPIRED ».

ExpirationDate

date d’expiration du certificat (champ obligatoire).

6.2.1.3. Mécanismes mis en œuvre par la solution logicielle Vitam

La solution logicielle Vitam intègre un référentiel des certificats applicatifs, administrable par un utilisateur doté des droits adéquats (administrateur technique) et géré dans une collection particulière[2].

Il est possible de réaliser les opérations présentées ci-dessous.

6.2.1.3.1. Import

Au moment de l’installation de la solution logicielle Vitam

La solution logicielle Vitam intègre par défaut des habilitations, automatiquement importées lors de l’initialisation de la plate-forme, dans le but de permettre un accès direct à l’ensemble de ses services. En plus d’un contexte applicatif, donnant accès à l’ensemble des tenants, et d’un profil de sécurité, référençant l’ensemble des permissions, elle fournit un certificat applicatif, utilisé pour déployer la solution logicielle Vitam[3].
Cette action, relevant d’un acte d’administration technique, fait l’objet d’une journalisation dans les logs, contrairement aux actions d’import du contexte applicatif et du profil de sécurité fournis par défaut par la solution logicielle Vitam, qui sont tracées dans le journal des opérations du tenant d’administration. Points d’attention : le certificat applicatif fourni par défaut par la solution logicielle Vitam n’est pas destiné à être utilisé par une plate-forme en production. Il a vocation à :

  • faciliter le déploiement d’une plate-forme et précéder l’utilisation d’un certificat de production ;

  • être utilisé par une plate-forme de tests.

Après installation de la solution logicielle Vitam

Dans la solution logicielle Vitam, il est possible de générer 1 à n certificat(s) applicatif(s). Cet ajout relève d’opérations d’administration technique et s’effectue au moyen des API.

Par cette génération, 1 à n certificat(s) applicatif(s) sont ajoutés au référentiel des certificats applicatifs[4].

Cette action, relevant d’un acte d’administration technique, fait l’objet d’une journalisation dans les logs, contrairement aux actions d’import du contexte applicatif et du profil de sécurité fournis par défaut par la solution logicielle Vitam, qui sont tracées dans le journal des opérations du tenant d’administration.

6.2.1.3.2. Recherche

La solution logicielle Vitam permet à un exploitant d’accéder à la liste des certificats, ainsi qu’aux habilitations qui lui sont associées. Pour un certificat donné, elle renvoie l’ensemble des informations relatives au :

  • contexte applicatif qui lui est attribué,

  • profil de sécurité déclaré dans ce dernier[5].

Cette action relève d’un acte d’administration technique et ne fait pas l’objet d’une journalisation.

6.2.1.3.3. Mise à jour

La solution logicielle permet de mettre à jour unitairement des certificats[6]. Cette mise à jour consiste à remplacer un certificat en fin de vie par un nouveau certificat et, de fait, entraîne la suppression du certificat en fin de vie. Cette mise à jour peut avoir un impact sur les interactions entre l’application versante et/ou accédante et la solution logicielle Vitam. Cette opération ne s’effectue qu’au moyen des API et relève d’une opération d’administration technique.

Cette action, relevant d’un acte d’administration technique, fait l’objet d’une journalisation dans les logs fournis par défaut par la solution logicielle Vitam.

6.2.1.3.4. Suppression

La solution logicielle permet de supprimer unitairement des certificats[7]. Cette suppression peut avoir un impact sur les interactions entre l’application versante et/ou accédante et la solution logicielle Vitam. Cette opération ne s’effectue qu’au moyen des API et relève d’une opération d’administration technique.

Cette action, relevant d’un acte d’administration technique, fait l’objet d’une journalisation dans les logs fournis par défaut par la solution logicielle Vitam.

6.2.1.4. Conseils de mise en œuvre

À l’issue de cette dernière phase de réalisation de fonctionnalités concernant les habilitations, l’équipe projet Vitam est en mesure de fournir quelques recommandations de mise en œuvre. La solution logicielle permet de créer, modifier et supprimer les certificats applicatifs. Certaines actions peuvent avoir un impact sur les interactions entre l’application versante et/ou accédante et la solution logicielle Vitam.

6.2.1.4.1. Quand et comment créer un certificat applicatif ?

Un service externe souhaitant utiliser les services de la solution logicielle Vitam doit avoir déclaré son certificat applicatif dans la solution logicielle Vitam. Ce certificat doit être associé à un contexte dès la création de celui-ci, sans quoi l’application cherchant à s’authentifier à la solution logicielle Vitam ne pourra accéder à aucun de ses services.

La création d’un certificat applicatif peut intervenir à différents moments :

  • lors de l’initialisation de la plate-forme : il est obligatoire de disposer d’un certificat applicatif, en plus d’un contexte applicatif et d’un profil de sécurité, pour pouvoir utiliser les services de la solution logicielle Vitam. Cette dernière propose un certificat par défaut, destiné à être utilisé dans deux cas :

    • pour le déploiement de la plate-forme, afin de faciliter son installation, ainsi que le paramétrage du certificat applicatif de production, ayant vocation à remplacer ce certificat par défaut ;

    • sur une plate-forme de tests ;

  • lors de l’intégration d’une nouvelle application devant accéder aux services de la solution logicielle Vitam.

La déclaration d’un certificat applicatif dans la solution logicielle Vitam relève d’une opération d’administration technique[8]. De fait, au moment de l’initialisation d’un nouveau certificat, il est recommandé de suivre les étapes suivantes :

Qui ?

Quoi ?

Via l’IHM Vitam ?

Administrateur fonctionnel/ technique

- définit ses besoins en termes d’habilitation :
Quel contexte applicatif utiliser ? quels droits associer à ce contexte applicatif ? quel profil de sécurité utiliser ? quels contrats associer ?
Les habilitations nécessaires existent-elles déjà ? Faut-il créer de nouvelles habilitations ?
Y a-t-il des besoins de sécurité particulier ?
- le cas échéant, liste les habilitations dont il a besoin[9].

Oui / Non

Administrateur technique

Le cas échéant, crée un profil de sécurité.

Non

Administrateur fonctionnel/ technique

Le cas échéant, crée un contexte applicatif, en l’associant à un profil de sécurité, créé pour l’occasion ou déjà existant.

Oui

Administrateur technique

Crée le nouveau certificat applicatif, en l’associant au contexte applicatif, créé pour l’occasion ou déjà existant.

Non

Administrateur fonctionnel

Le cas échéant :
- crée des contrats, d’entrée et/ou d’accès ;
- associe au contexte applicatif des contrats d’entrée et/ou d’accès.

Oui

Administrateur fonctionnel/ technique

Activation du contexte applicatif.

Oui

Administrateur technique / fonctionnel

Test avant utilisation courante.

Oui

Points d’attention :

  • La solution logicielle Vitam rend obligatoire l’intégration d’un certificat applicatif par défaut, afin de pouvoir initialiser et paramétrer la plate-forme. Ce certificat n’a pas vocation à être utilisé en production et doit, dans ce cas-là, être remplacé par un certificat de production.

  • Dans la mesure où un certificat doit être associé à un contexte, lui-même nécessitant un profil de sécurité, il est obligatoire de disposer au préalable d’un profil de sécurité et d’un contexte à associer à ce certificat applicatif.

  • Un même certificat ne peut être utilisé que par un contexte applicatif.

6.2.1.4.2. Comment mettre à jour un certificat applicatif ?

Un certificat applicatif a une durée de vie limitée et nécessite d’être ponctuellement mis à jour, voire remplacé[10]. On peut procéder de la manière suivante :

Qui ?

Quoi ?

Via l’IHM Vitam ?

Commentaires

Administrateur fonctionnel/ technique

Désactivation du contexte associé au certificat applicatif à changer.

Oui

Administrateur technique

Création d’un nouveau certificat applicatif, destiné à remplacer le certificat en production.

Non

NB : déclaration du contexte désactivé.

Administrateur technique

Révocation du précédent certificat applicatif.

Non

But : éviter un conflit de certificats lors de la réactivation du contexte.

Administrateur fonctionnel/ technique

Activation du contexte applicatif.

Oui

Administrateur technique / fonctionnel

Test avant utilisation courante.

Oui

6.2.1.4.3. Quand et comment supprimer un certificat applicatif ?

La suppression ou révocation d’un certificat applicatif peut intervenir à plusieurs occasions :

  • l’application souhaitant s’authentifier à la solution logicielle Vitam est décommissionnée ;

  • son certificat est obsolète et doit être remplacé.

La solution logicielle Vitam permet de le révoquer de la manière suivante :

  • en transmettant à la solution logicielle Vitam la liste des certificats révoqués par une autorité fournissant des certificats applicatifs ;

  • en changeant son statut, de « VALID » à « REVOKED » ou « EXPIRED ». Cela a pour conséquence le rejet de tout accès aux API de la solution logicielle Vitam au moyen de ce certificat révoqué.

La révocation d’un certificat applicatif dans la solution logicielle Vitam relève d’une opération d’administration technique[11].

Point d’attention : la révocation d’un certificat peut être temporaire et la suppression de l’usage du certificat est alors temporaire, tandis qu’un certificat expiré n’est plus utilisable.

6.2.2. Certificat personnel

6.2.2.1. Description

Le certificat personnel correspond à un certificat propre à une personne physique utilisatrice en particulier de l’application souhaitant accéder aux services de la solution logicielle Vitam. Le certificat personnel ne se substitue pas au certificat applicatif qui authentifie une application, et il sert juste à identifier et non à authentifier une personne qui se connecte derrière une application. Le principe de délégation de la phase d’authentification des utilisateurs humains par les front-offices est conservé même dans ce cas, et ce certificat est simplement transmis par le front-office dans les appels REST. À minima, la solution logicielle Vitam vérifie que ce certificat est présent dans la liste des certificats connus.

Son utilisation répond à un besoin de sécurité supplémentaire, associé aux fonctions d’administration avancées ou considérées comme sensibles. L’accès à certaines fonctions (EndPoints) est soumis d’une part à l’autorisation de l’application par son contexte applicatif et d’autre part à la présence d’un certificat personnel connu pour identification de l’utilisateur.

6.2.2.2. Formalisation

Les certificats personnels sont enregistrés dans la base de données MongoDB, dans la collection « PersonalCertificate », sous la forme d’enregistrements au format JSON.

Enregistrement d’un certificat personnel :

{
    "_id": "aeaaaaaaaahgnmn7aacg4allwxzmb6qaaaaq",
    "SubjectDN": "O=VITAM, L=Paris, C=FR",
    "SerialNumber": "2",
    "Certificate": "MIIFRjCCAy6gAwIBAgIBAjANBgkqhkiG9w0BAQsFADAtMQswCQYDVQQGEwJGUjEOMAwGA1UEBxMFUGFyaXMxDjAMBgNVBAoTBVZJVEFNMCAXDTE3MDgwMTExMTcwMFoYDzk5OTkxMjMxMjM1OTU5WjAtMQswCQYDVQQGEwJGUjEOMAwGA1UEBxMFUGFyaXMxDjAMBgN[...]I49Maz5W87bKqNyecYtrBlvML7k5UeOLtgNuUsTBlzFTxMkaQHOSpMyrHZ/yVPNVfuP3cCKvzMPHFGHzJZK0qvz4zdFdx7YzBq+I6YLvRES9b+DkvdrTOpZI2GjKuP5m13kcUjsFeqJR6rb+o1kJuCj/QMC2OjMXMlDqNa8mL5ooGQmYOzHkfq4vdKLG/Fvbpw2DDrwv9jKmw2l6eWLYzuIpvz7sqUHwi30wScXSm/FCKF9DjzODUpSkBvDiaA==",
    "IssuerDN": "O=VITAM, L=Paris, C=FR",
    "Status": "VALID",
    "Hash": "6088f19bc7d328f301168c064d6fda93a6c4ced9d5c56810c4f70e21e77d841d",
   "ExpirationDate": "2025-01-30T22:13:43.000"
}

Un certificat personnel doit comporter les éléments suivants[12] :

Champ

Description

_id

identifiant unique dans l’ensemble du système, fourni par ce dernier (champ obligatoire).

SubjectDN

identifiant unique du certificat personnel ou Distinguished Name (champ obligatoire).

SerialNumber

numéro de série du certificat personnel (champ obligatoire).

IssuerDN

identifiant unique ou Distinguished Name de l’autorité de certification (champ obligatoire).

Certificate

clé du certificat personnel (champ obligatoire).

Hash

empreinte du certificat personnel (champ obligatoire).

Status

statut du certificat personnel (champ obligatoire) :
- Si le certificat est valide et actif, le statut a pour valeur « VALID » ;
- Si le certificat a été révoqué, le statut a pour valeur « REVOKED »,
- Si le certificat est expiré, le statut a pour valeur « EXPIRED ».

ExpirationDate

date d’expiration du certificat (champ obligatoire).

Au niveau de la plate-forme un fichier de configuration définit les services qui peuvent être rendus accessibles aux seuls détenteurs d’un certificat personnel[13]. Par ailleurs, le certificat personnel est enregistré dans le journal des opérations sous forme d’identifiant (agIdPers).

6.2.2.3. Mécanismes mis en œuvre par la solution logicielle Vitam

La solution logicielle Vitam intègre un référentiel des certificats personnels, administrable par un utilisateur doté des droits adéquats (administrateur technique) et géré dans une collection particulière[14].

Il est possible de réaliser les opérations présentées ci-dessous.

6.2.2.3.1. Import

Dans la solution logicielle Vitam, il est possible de générer 0 à n certificat(s) personnel(s). Cet ajout relève d’opérations d’administration technique et s’effectue au moyen des API.

Lors d’un import, 1 à n certificat(s) personnel(s) sont ajoutés au référentiel des certificats personnels[15]. Cette action, relevant d’un acte d’administration technique, fait l’objet d’une journalisation dans les logs de la solution logicielle Vitam.

Point d’attention : cette action requiert au préalable le paramétrage d’un fichier de configuration définissant les services qui peuvent être rendus accessibles aux seuls détenteurs du certificat personnel[16].

6.2.2.3.2. Suppression

La solution logicielle permet de supprimer unitairement des certificats personnels[17]. Cette suppression peut avoir un impact sur les interactions entre l’application versante et/ou accédante et la solution logicielle Vitam. Cette opération ne s’effectue qu’au moyen des API et relève d’une opération d’administration technique.

Cette action, relevant d’un acte d’administration technique, fait l’objet d’une journalisation dans les logs de la solution logicielle Vitam.

6.2.2.4. Conseils de mise en œuvre

À l’issue de cette dernière phase de réalisation de fonctionnalités concernant les habilitations, l’équipe projet Vitam est en mesure de fournir quelques recommandations de mise en œuvre. La solution logicielle permet de créer, paramétrer et supprimer les certificats personnels. Certaines actions peuvent avoir un impact sur les interactions entre l’application versante et/ou accédante et la solution logicielle Vitam.

6.2.2.4.1. Quand et comment créer un certificat personnel ?

Un service externe souhaitant utiliser les services de la solution logicielle Vitam peut disposer de certificats personnels pour tracer les actions de certains utilisateurs.

La création d’un certificat personnel et l’attribution des privilèges qui lui sont associés relèvent d’une opération d’administration technique[18]. La création d’un certificat personnel peut intervenir à différents moments :

  • lors de l’initialisation de la plate-forme : il n’est pas obligatoire de disposer d’un certificat personnel pour pouvoir utiliser les services de la solution logicielle Vitam, mais sa création répond à des besoins supplémentaires d’authentification ;

  • lors de l’intégration d’une nouvelle application devant accéder aux services de la solution logicielle Vitam avec des habilitations particulières pour certains de ses utilisateurs.

Tout comme les droits octroyés par un profil de sécurité, les privilèges accordés par un certificat personnel correspondent aux services proposés par la solution logicielle Vitam (EndPoint). Ils doivent en outre se conformer aux droits définis dans le profil de sécurité du contexte applicatif utilisé[19].

Cette liste de privilèges, associée à un certificat personnel, est unique sur l’ensemble de la plate-forme[20].

Il est recommandé de n’utiliser ce type de certificat que pour des utilisateurs en nombre restreint :

  • des administrateurs de la solution logicielle Vitam, ayant vocation à accéder à l’ensemble des services mis à disposition par cette dernière ;

  • des personnes ayant des droits d’accès à certains services en particulier (on pourrait envisager d’utiliser un certificat personnel dans le cas de la gestion des archives protégées au titre du secret de la défense nationale, sur une instance classifiée).

De fait, au moment de l’initialisation d’une plate-forme ou de l’intégration d’une nouvelle application, il est recommandé de suivre les étapes suivantes :

Qui ?

Quoi ?

Via l’IHM Vitam ?

Administrateur fonctionnel/ technique

- définit ses besoins en termes d’habilitation :
Quel contexte applicatif utiliser ? quels droits associer à ce contexte applicatif ? quel profil de sécurité utiliser ? quels contrats associer ?
Les habilitations nécessaires existent-elles déjà ? Faut-il créer de nouvelles habilitations ?
Y a-t-il des besoins de sécurité particulier ?
Faut-il un certificat personnel pour authentifier un certain groupe d’utilisateurs ?
- le cas échéant, liste les habilitations dont il a besoin, ainsi que les privilèges à associer au certificat personnel.

Oui / Non

Administrateur technique

Le cas échéant, crée un profil de sécurité.

Non

Administrateur technique

Le cas échéant, met à jour le fichier de configuration des permissions associées au certificat personnel et génère le certificat personnel.

Non

Administrateur fonctionnel/ technique

Le cas échéant, crée un contexte applicatif, en l’associant à un profil de sécurité, créé pour l’occasion ou déjà existant.

Oui

Administrateur technique

Crée le nouveau certificat applicatif, en l’associant au contexte applicatif, créé pour l’occasion ou déjà existant.

Non

Administrateur fonctionnel

Le cas échéant :
- crée des contrats, d’entrée et/ou d’accès ;
- associe au contexte applicatif des contrats d’entrée et/ou d’accès.

Oui

Administrateur fonctionnel/ technique

Activation du contexte applicatif.

Oui

Administrateur technique / fonctionnel

Test avant utilisation courante.

Oui

Points d’attention :

  • Les permissions associées à un certificat personnel doivent se conformer aux droits accordés par un profil de sécurité à un contexte donné.

  • Les permissions associées à un certificat personnel sont uniques sur une plate-forme donnée. De fait, elles ne peuvent être accordées qu’à un groupe particulier d’utilisateurs.

6.2.2.4.2. Comment paramétrer les permissions associées à un certificat personnel ?

Au niveau de la plate-forme, un fichier de configuration définit les services qui peuvent être rendus accessibles aux seuls détenteurs d’un certificat personnel : il s’agit du fichier « personal-certificate-permissions.conf »[21].


Fichier de configuration listant les permissions avec et sans certificat personnel

Ce fichier distingue :

  • les services accessibles sans certificat personnel (« permissionsWithoutPersonalCertificate »). Par défaut, y sont listés l’ensemble des services mis à disposition par la solution logicielle Vitam[22] ;

  • les services accessibles avec certificat personnel (« permissionsRequiringPersonalCertificate »). Par défaut, la solution logicielle Vitam ne générant pas nativement de certificats personnels, cette liste est vide.

Il est possible de :

  • associer des permissions à un certificat personnel, en ajoutant à cette dernière liste vide les services souhaités ;

  • supprimer des permissions accessibles sans certificat personnel. Cette opération relève d’un acte d’exploitation technique.

Points d’attention :

  • Les permissions associées à un certificat personnel doivent se conformer aux droits accordés par un profil de sécurité à un contexte donné.

  • Les permissions associées à un certificat personnel sont uniques sur une plate-forme donnée. De fait, elles ne peuvent être accordées qu’à un groupe particulier d’utilisateurs.

6.2.2.4.3. Comment mettre à jour un certificat personnel ?

Un certificat personnel a une durée de vie limitée et nécessite d’être ponctuellement mis à jour, voire remplacé[23]. On peut procéder de la manière suivante :

Qui ?

Quoi ?

Via l’IHM Vitam ?

Commentaires

Administrateur fonctionnel/ technique

Arrêt momentané d’accès aux services de la solution logicielle Vitam pour le groupe d’utilisateurs concerné.

Oui

Communication externe.

Administrateur technique

Création d’un nouveau certificat personnel, destiné à remplacer le certificat en production.

Non

Administrateur technique

Révocation du précédent certificat personnel.

Non

But : éviter un conflit de certificats lors de la réactivation du service.

Administrateur technique/ fonctionnel

Test avant utilisation courante.

Oui

6.2.2.4.4. Quand et comment supprimer un certificat personnel ?

La suppression ou révocation d’un certificat personnel peut intervenir à plusieurs occasions :

  • l’application souhaitant s’authentifier au moyen d’un certificat personnel à la solution logicielle Vitam est décommissionnée ;

  • ce certificat est obsolète et doit être remplacé.

La solution logicielle Vitam permet de le révoquer de la manière suivante[24]:

  • en transmettant à la solution logicielle Vitam la liste des certificats révoqués par une autorité fournissant des certificats personnels ;

  • en changeant son statut, de « VALID » à « REVOKED » ou « EXPIRED ». Cela a pour conséquence le rejet de tout accès aux API de la solution logicielle Vitam au moyen de ce certificat révoqué.

Point d’attention : la révocation d’un certificat peut être temporaire et la suppression de l’usage du certificat est alors temporaire, tandis qu’un certificat expiré n’est plus utilisable.

6.2.3. Profil de sécurité

6.2.3.1. Description

Pour un contexte applicatif donné, le profil de sécurité formalise les privilèges ou droits octroyés à un service externe par la solution logicielle Vitam, et par conséquent les points d’accès (EndPoints) par lesquels ce service, une fois authentifié, pourra transmettre des requêtes à la solution logicielle Vitam. Un profil de sécurité applicatif détermine les droits suivants :

  • soit un accès à tous les services proposés par la solution logicielle Vitam ;

  • soit une liste de services définis auxquels le profil de sécurité donne accès[25].

6.2.3.2. Formalisation

Les profils de sécurité sont enregistrés dans la base de données MongoDB, dans la collection « SecurityProfile », sous la forme d’enregistrements au format JSON. Enregistrement d’un profil de sécurité :

{
    "_id": "aegqaaaaaahn6o5iab5z6almhpd24eaaaaba",
    "Identifier": "TNR_SEC_PROFILE_OK_2",
    "Name": "TNR_SEC_PROFILE_OK_2",
    "FullAccess": false,
    "Permissions": [
        "contexts:read"
    ],
    "_v": 1
}

Le profil de sécurité est modélisé en JSON comme suit[26] :

Champ

Description

_id

identifiant unique dans l’ensemble du système, fourni par ce dernier (champ obligatoire).

Identifier

identifiant donné au profil de sécurité, généré automatiquement par le système (champ obligatoire).
- S’il est généré par la solution logicielle Vitam, cet identifiant se compose du préfixe SEC_PROFILE, suivi d’un tiret et d’une suite de 6 chiffres incrémentés automatiquement.
- Il peut également être généré par l’application à l’origine de sa création[27]. S’il est généré par une application externe, il ne doit comprendre ni caractère accentué, ni virgule, ni apostrophe, ni parenthèse, ni espace, ni slash, ni élément de ponctuation, ou tout autre caractère spécial. Ne sont recommandés que l’underscore et le tiret comme séparateurs.

Name

nom du profil de sécurité, qui doit être obligatoirement renseigné et unique sur la plate-forme (champ obligatoire)

FullAccess

droit(s) au(x)quel(s) le profil de sécurité donne accès (champ obligatoire). Il peut s’agir de :
- tous les accès (FullAccess = « true »),
- une liste de privilèges ou droits octroyés (FullAccess = « false »).

Permissions

dans le cas où tous les accès ne sont pas octroyés (FullAccess = « false »), liste de privilèges ou droits octroyés, sélectionnés parmi l’ensemble des services proposés par la solution logicielle Vitam au sein d’une liste de permissions (champ facultatif).
Pour chaque service, cette liste précise le type de service concerné et les droits associés (lecture, écriture, suppression).

_v

version du profil de sécurité, fournie par le système (champ obligatoire).

6.2.3.3. Mécanismes mis en œuvre par la solution logicielle Vitam

La solution logicielle Vitam intègre un référentiel des profils de sécurité, administrable par un utilisateur doté des droits adéquats (administrateur fonctionnel et/ou technique) et géré dans une collection particulière[28]. Ce référentiel est multi-tenant. Il est administrable et journalisé depuis le tenant d’administration.

Il est possible de réaliser les opérations présentées ci-dessous.

6.2.3.3.1. Import

Au moment de l’installation de la solution logicielle Vitam

La solution logicielle Vitam intègre par défaut des habilitations, automatiquement importés lors de l’initialisation de la plate-forme, dans le but de permettre un accès direct à l’ensemble de ses services. En plus d’un certificat applicatif, utilisé pour déployer la solution logicielle Vitam, ainsi que d’un contexte applicatif, donnant accès à l’ensemble des tenants, elle fournit un profil de sécurité, référençant l’ensemble des permissions.

Il s’agit d’une opération d’administration, tracée dans le journal des opérations du tenant d’administration (« MASTERDATA »)[29].

Après installation de la solution logicielle Vitam Dans la solution logicielle Vitam, il est possible d’importer uniquement sur le tenant d’administration 1 à n profil(s) de sécurité. Cet ajout relève d’opérations d’administration technique et s’effectue au moyen des API[30]. Par cet import, 1 à n profil(s) de sécurité sont ajoutés au référentiel des profils de sécurité.

Il est également possible de créer un profil de sécurité depuis l’APP VitamUI « Profils de sécurité » .

Il s’agit d’une opération d’administration, tracée dans le journal des opérations du tenant d’administration (« MASTERDATA »)[31]. Lors de cet import, l’opération peut aboutir aux statuts suivants :

Statut

Motifs

Succès

Opération réalisée sans rencontrer de problèmes particuliers.

Échec[32]

Avec journalisation :
- import d’un profil de sécurité déclarant à la fois une liste de permissions et autorisant en même temps tous les accès ;
- import d’un profil de sécurité dont l’identifiant existe déjà dans le système ;
- import d’un profil de sécurité dans lequel des champs sont absents. Il peut s’agir des champs : Identifier, Name ;
- import d’un profil de sécurité dans lequel une permission n’existe pas ;
- import d’un profil de sécurité dans lequel une valeur ne correspond pas au type d’indexation du champ défini dans l’ontologie (ex : valeur textuelle dans le champ « FullAccess » de type « BOOLEAN »).

6.2.3.3.2. Recherche

La solution logicielle Vitam permet de rechercher et d’accéder :

  • soit aux seuls profils de sécurité ;

  • soit aux profils de sécurité dans une forme plus contextualisée, c’est-à-dire avec les certificats applicatifs et les contextes applicatifs auxquels ils sont associés[33].

Cette action relève d’un acte d’administration technique et ne fait pas l’objet d’une journalisation.

6.2.3.3.3. Modification

La modification des champs des profils de sécurité est possible au moyen des API depuis le tenant d’administration[34].

Les champs modifiables sont :

  • le nom du profil de sécurité (Name) ;

  • le(s) droit(s) sur les accès, correspondant aux valeurs « true » et « false » dans le système (FullAccess) ;

  • la liste des permissions (Permissions).

Concernant la liste des permissions, il est possible de :

  • ajouter ou supprimer une permission, dans le cas où tous les accès ne sont pas octroyés (FullAccess = « false ») ;

  • octroyer tous les accès, en passant le statut du contrôle sur les droits (FullAccess) de « false » à « true », tout en supprimant la liste de permissions (Permissions) ;

  • restreindre les accès à une liste de permissions, en passant le statut du contrôle sur les droits (FullAccess) de « true » à « false », tout en ajoutant 1 à n permission(s) (Permissions) ;

  • supprimer l’ensemble des permissions (Permissions), et, de fait, octroyer tous les accès en passant le statut du contrôle sur les droits (FullAccess) de « false » à « true ».

Il est également possible de modifier un profil de sécurité depuis l’APP VitamUI « Profils de sécurité » . Les champs modifiables sont :

  • le(s) droit(s) sur les accès, correspondant aux valeurs « ON » et « OFF » dans l’APP (Gérer les accès) ;

  • la liste des permissions (Permissions), pour lesquelles on peut activer ou désactiver des droits de lecture, de modification et de suppression.

Points d’attention :

  • Lors d’une mise à jour de permissions dans un profil de sécurité, le contrôle sur les accès (FullAccess) du profil de sécurité doit toujours être présent. En revanche, en fonction de son statut, la liste de permissions ne doit pas l’être.

    • dans le cas où tous les accès ne sont pas octroyés (FullAccess = « false »), la liste de privilèges ou droits octroyés, sélectionnés parmi l’ensemble des services proposés par la solution logicielle Vitam au sein d’une liste de permissions (Permissions) doit être obligatoirement renseignée ;

    • dans le cas où tous les accès sont octroyés (FullAccess = « true »), la liste de permissions doit être supprimée.

Cette action provoque la création d’une nouvelle version du profil de sécurité modifié. Les différentes versions du référentiel font l’objet d’une sauvegarde sur les offres de stockage utilisées par la solution logicielle Vitam.

Il s’agit d’une opération d’administration (« MASTERDATA »), tracée dans le journal des opérations du tenant d’administration[35].

Lors de cette mise à jour, l’opération peut aboutir aux statuts suivants :

Statut

Motifs

Succès

Opération réalisée sans rencontrer de problèmes particuliers.

Échec[36]

Avec journalisation :
- suppression d’un champ obligatoire, tel que : Identifier, Name ;
- suppression de l’ensemble de la liste des permissions, alors que le contrôle sur les accès requiert une liste de permissions (FullAccess = false) ;
- ajout d’une permission qui n’existe pas ;
- autorisation donnée sur tous les accès (FullAccess = true), alors que le profil de sécurité définit une liste de permissions ;
- autorisation donnée sur un accès restreint (FullAccess = false), sans avoir défini de liste de permissions ;
- ajout d’un champ inconnu et non défini pour un profil de sécurité.

6.2.3.3.4. Suppression

La solution logicielle permet de supprimer unitairement des profils de sécurité. Cette suppression peut avoir un impact sur les interactions entre l’application versante et/ou accédante et la solution logicielle Vitam. Cette opération ne s’effectue qu’au moyen des API et relève d’une opération d’administration technique[37]. Il s’agit d’une opération d’administration (« MASTERDATA »), tracée dans le journal des opérations du tenant d’administration[38].

6.2.3.3.5. Autorisation d’accès

La solution logicielle Vitam permet d’activer ou de désactiver une autorisation d’accès depuis un profil de sécurité (FullAccess).

  • si la valeur du contrôle est égale à « true », le profil de sécurité autorise une application externe à accéder à l’ensemble des services de la solution logicielle Vitam ;

  • si la valeur du contrôle est égale à « false », le profil de sécurité autorise une application externe à accéder à une liste précise de services. L’application externe accède alors à la solution logicielle Vitam, avec pour seules restrictions les permissions qui lui sont attribuées dans le profil de sécurité associé au contexte applicatif.

Point d’attention : le profil de sécurité, fourni par défaut par la solution logicielle Vitam ne fait aucune restriction d’accès sur les permissions (« true ») et donne accès à l’ensemble des services de la solution logicielle Vitam.

6.2.3.4. Conseils de mise en œuvre

À l’issue de cette dernière phase de réalisation de fonctionnalités concernant les habilitations, l’équipe projet Vitam est en mesure de fournir quelques recommandations de mise en œuvre. La solution logicielle permet de créer et de modifier les profils de sécurité. Certaines actions peuvent avoir un impact sur les interactions entre l’application versante et/ou accédante et la solution logicielle Vitam.

6.2.3.4.1. Quand et comment créer un profil de sécurité ?

Un service externe souhaitant utiliser les services de la solution logicielle Vitam doit disposer d’un profil de sécurité. Ce profil doit être associé à un contexte dès sa création, sans quoi l’application cherchant à s’authentifier à la solution logicielle Vitam ne pourra accéder à aucun de ses services.

La création d’un profil de sécurité peut intervenir à différents moments :

  • lors de l’initialisation de la plate-forme : il est obligatoire de disposer d’un profil de sécurité, en plus d’un contexte applicatif et d’un certificat applicatif, pour pouvoir utiliser les services de la solution logicielle Vitam. Cette dernière propose un profil de sécurité par défaut, destiné à être utilisé dans deux cas :

    • pour le déploiement de la plate-forme, afin de faciliter son installation, ainsi que le paramétrage du profil de sécurité de production, ayant vocation à remplacer ce profil de sécurité par défaut ;

    • sur une plate-forme de tests ;

  • lors de l’intégration d’une nouvelle application devant accéder aux services de la solution logicielle Vitam.

La création d’un profil de sécurité et l’attribution des privilèges qui lui sont associés relèvent d’une opération d’administration technique.

De fait, au moment de l’initialisation d’un nouveau profil de sécurité, il est recommandé de suivre les étapes suivantes :

Qui ?

Quoi ?

Via l’IHM Vitam ?

Administrateur fonctionnel/ technique

- définit ses besoins en termes d’habilitation :
Quel contexte applicatif utiliser ? quels droits associer à ce contexte applicatif ? quel profil de sécurité utiliser ? quels contrats associer ?
Les habilitations nécessaires existent-elles déjà ? Faut-il créer de nouvelles habilitations ?
Y a-t-il des besoins de sécurité particulier ?
- le cas échéant, liste les habilitations dont il a besoin[39].

Oui / Non

Administrateur technique

Le cas échéant, crée un profil de sécurité.

Non

Administrateur fonctionnel/ technique

Le cas échéant, crée un contexte applicatif, en l’associant à un profil de sécurité, créé pour l’occasion ou déjà existant.

Oui

Administrateur technique

Crée le nouveau certificat applicatif, en l’associant au contexte applicatif, créé pour l’occasion ou déjà existant.

Non

Administrateur fonctionnel

Le cas échéant :
- crée des contrats, d’entrée et/ou d’accès ;
- associe au contexte applicatif des contrats d’entrée et/ou d’accès.

Oui

Administrateur fonctionnel/ technique

Activation du contexte applicatif.

Oui

Administrateur technique / fonctionnel

Test avant utilisation courante.

Oui

Points d’attention :

  • La solution logicielle Vitam rend obligatoire l’intégration d’un profil de sécurité par défaut, afin de pouvoir initialiser et paramétrer la plate-forme. Ce profil de sécurité n’a pas vocation à être utilisé en production et doit, dans ce cas-là, être remplacé par un certificat de production. Néanmoins, il peut être utilisé par un système d’information archivistique (SIA) ou une application ayant des droits d’administration de la solution logicielle Vitam.

  • Le profil de sécurité fourni par défaut par la solution logicielle Vitam n’a pas vocation à être supprimé ou à être modifié.

  • Dans la mesure où un certificat doit être associé à un contexte, lui-même nécessitant un profil de sécurité, il est obligatoire de disposer au préalable d’un profil de sécurité et d’un contexte à associer à ce certificat applicatif.

6.2.3.4.2. Comment nommer un profil de sécurité ?

Une application externe dispose d’un certificat applicatif, d’un profil de sécurité, d’un contexte applicatif et d’un à plusieurs contrats, d’entrée et/ou d’accès.

Au travers de ces différents référentiels, il s’agira de paramétrer les habilitations de ce seul service externe. C’est pourquoi, il est recommandé d’adopter des règles de nommage identiques dans les différents référentiels, en utilisant les éléments suivants :

  • nom de l’application versante ou accédante,

  • nom ou type d’objet archivé,

  • nom du service producteur,

  • code métier. En sachant que :

  • un profil de sécurité peut être utilisé par des contextes applicatifs différents ;

  • un contexte applicatif peut être appelé par plusieurs certificats applicatifs ;

  • un contexte applicatif peut déterminer plusieurs tenants, ainsi que plusieurs contrats, d’entrée comme d’accès ;

  • un service producteur peut avoir plusieurs contrats différents ;

  • une application versante ou accédante peut détenir plusieurs contrats.

6.2.3.4.3. Comment paramétrer l’identifiant d’un profil de sécurité ?

Comportement par défaut

Par défaut, la solution logicielle Vitam génère les identifiants des habilitations de la manière suivante (mode « maître ») :

Type d’habilitation

Paramétrage de l’identifiant

Profil de sécurité

préfixe SEC_PROFILE, suivi d’un tiret et d’une suite de 6 chiffres incrémentés automatiquement

Contexte applicatif

préfixe CT, suivi d’un tiret et d’une suite de 6 chiffres incrémentés automatiquement

Contrat d’entrée

préfixe IC, suivi d’un tiret et d’une suite de 6 chiffres incrémentés automatiquement

Contrat d’accès

préfixe AC, suivi d’un tiret et d’une suite de 6 chiffres incrémentés automatiquement

Ce fonctionnement par défaut diffère pour les tenants 0 et 1, où la solution logicielle Vitam est paramétrée par défaut pour ne pas générer d’identifiants pour :

  • les contrats d’entrée et d’accès, les profils d’archivage, les profils de sécurité et les contextes sur le tenant 1, dit « tenant d’administration »,

  • les contrats d’entrée et d’accès sur le tenant 0[40]. Il est, bien sûr, possible de modifier ce paramétrage par défaut.

Paramétrage des identifiants

Il est possible de paramétrer les identifiants, afin qu’ils soient générés par l’application à l’origine de la création des différentes habilitations concernées (mode « esclave »). Cette opération peut avoir lieu :

  • soit au moment de l’installation de la plate-forme,

  • soit après installation, sur une plate-forme en activité. Dans ce cas-là, une interruption temporaire de service sera à prévoir, car l’opération nécessite le redémarrage du service « vitam-functional-administration ».

Pour ce faire, il faut modifier le fichier de configuration « functional-administration.conf », qui définit, entre autres, par tenant, les habilitations dont la solution logicielle Vitam ne génère pas d’identifiant[41].


Fichier de configuration listant, par tenant, les habilitations dont l’identifiant n’est pas généré par Vitam

Il est possible d’associer à un tenant l’habilitation pour laquelle on souhaite voir généré l’identifiant par une application externe, en ajoutant au tenant concerné le nom de l’habilitation concerné.

Le nom de l’habilitation concernée doit être écrit de la manière suivante :

  • « INGEST_CONTRACT » pour les contrats d’entrée ;

  • « ACCESS_CONTRACT » pour les contrats d’accès ;

  • « SECURITY_PROFILE » pour les profils de sécurité (utile seulement sur le tenant d’administration) ;

  • « CONTEXT » pour les contextes applicatifs (utile seulement sur le tenant d’administration).

La gestion des identifiants peut varier d’un tenant à l’autre, comme c’est le cas dans le tableau où :

  • le tenant 1, d’administration, est esclave pour les contrats d’entrée et d’accès, les profils d’archivage, les profils de sécurité et les contextes ;

  • le tenant 0 ne l’est que pour les contrats d’entrée et d’accès.

Cette opération relève d’un acte d’exploitation technique. Elle implique le redémarrage du/des composant(s), selon qu’il soit mono-instance ou multi-instances.

Points d’attention :

  • En mode « esclave », il est fortement recommandé de faire débuter les référentiels avec d’autres chaînes de caractères que celle définies en mode « maître » ;

  • Par ailleurs, en mode « esclave », l’identifiant ne doit comprendre ni caractère accentué, ni virgule, ni apostrophe, ni parenthèse, ni espace, ni slash, ni élément de ponctuation, ou tout autre caractère spécial. Ne sont recommandés que l’underscore et le tiret comme séparateurs ;

  • Il ne faut pas oublier de répercuter cette modification sur le site secondaire.

6.2.3.4.4. Quel accès aux profils de sécurité ?

Gestion des droits

La gestion des habilitations relève d’opérations d’administration. Il est donc recommandé d’en limiter l’accès :

  • un administrateur fonctionnel et/ou technique peut avoir accès à l’exhaustivité de ces référentiels et les mettre à jour ;

  • seul un administrateur technique a vocation à gérer les certificats applicatifs et les certificats personnels ;

  • une application versante et/ou accédante pourra, le cas échéant, avoir accès aux seules habilitations la concernant, en lecture seule ;

  • un tiers n’a pas vocation a prendre connaissance des contextes applicatifs et des profils de sécurité, pour des raisons de sécurité.

Restitution sur une IHM

Dans un projet d’implémentation, il est possible d’envisager la restitution de cette fonctionnalité sur une IHM dédiée.

Dans VitamUI, l’APP « Profils de sécurité » permet de :

  • accéder à :

  • la liste des profils de sécurité créés sur un tenant donné,

  • au détail d’un profil de sécurité ;

  • créer un nouveau profil,

  • modifier un profil.

Profil de sécurité, contrats d’entrée et d’accès sont obligatoirement associés à un contexte applicatif. S’il y a conception d’écrans permettant d’afficher contextes, profils de sécurité, contrats d’entrée et d’accès, il est recommandé de prendre en considération les liens entre eux.

6.2.3.4.5. Comment modifier un profil de sécurité ?

Il est possible de modifier un profil de sécurité utilisé dans un ou plusieurs contexte(s) applicatif(s). Il est conseillé de suivre les étapes suivantes en fonction du contexte d’utilisation du profil de sécurité :

Contexte

Action

Avec un contexte applicatif

Désactivation du contexte applicatif, le temps de procéder à la modification, puis réactivation du contexte applicatif.

Avec plusieurs contextes applicatifs

Désactivation de l’ensemble des contextes applicatifs, le temps de procéder à la modification du profil de sécurité, puis réactivation des contextes applicatifs.
Point d’attention : le profil de sécurité ainsi modifié doit toujours convenir à l’ensemble des contextes auxquels il est associé. Si ce n’est pas le cas, il faudra créer un nouveau profil de sécurité et l’associer aux contextes souhaités.

6.2.4. Contexte applicatif

6.2.4.1. Description

Le contexte applicatif formalise les interactions entre un service externe et la solution logicielle Vitam. Il permet notamment d’authentifier une application et de lui affecter des droits dans la solution logicielle Vitam.

Afin qu’une application externe puisse utiliser les services fournis par la solution logicielle Vitam, son contexte applicatif doit être associé à :

  • 1 certificat applicatif ;

  • 1 à n tenant(s) ;

  • 0 à n contrat(s) d’entrées, selon que l’application doit réaliser ou non des entrées ;

  • 0 à n contrat(s) d’accès, selon que l’application doit accéder ou non à la solution logicielle Vitam ;

  • 1 profil de sécurité.

Un paramètre permet de désactiver ce contrôle sur les tenants et les contrats : le contexte applicatif permet alors à l’application externe d’accéder à l’ensemble des services mis à disposition par la solution logicielle Vitam.

6.2.4.2. Formalisation

6.2.4.2.1. Dans un fichier JSON

Un contexte applicatif prend la forme d’un fichier JSON, pouvant contenir 1 à n contexte(s) applicatif(s)[42].

Exemple de contexte applicatif à importer dans la solution logicielle Vitam :

[
  {
    "Identifier": "CT-00001",
    "Name": "Contexte_du_SIA",
    "SecurityProfile": "admin-security-profile"
 }
 ]

Un contexte applicatif donné doit obligatoirement comporter les informations suivantes :

  • identifiant signifiant (Identifier). Ce champ est obligatoire seulement s’il est généré par l’application à l’origine de sa création. Si cet identifiant est généré par la solution logicielle Vitam, il n’est pas nécessaire de le renseigner dans le fichier JSON ;

  • nom du contexte (Name) ;

  • identifiant du profil de sécurité associé au contexte (SecurityProfile).

Une liste des permissions (Permissions), une date d’activation (ActivationDate) et de désactivation (DeactivationDate), un statut (Status) et un contrôle sur les tenants (EnableControl), facultatifs, peuvent venir compléter ces informations. Concernant les deux derniers items :

  • Le premier peut contenir les valeurs « ACTIVE » ou « INACTIVE » ;

  • Le deuxième les valeurs « true » ou « false ».

S’ils ne sont pas renseignés, la solution logicielle Vitam fournira automatiquement une valeur par défaut pour ces deux items :

  • valeur «  INACTIVE » pour le statut ;

  • valeur « false » pour le contrôle sur les tenants.

6.2.4.2.2. Dans la solution logicielle Vitam

Les contextes applicatifs sont enregistrés dans la base de données MongoDB, dans la collection « Context », sous la forme d’enregistrements au format JSON. Le contexte applicatif est modélisé en JSON comme suit[43] :

Champ

Description

_id

identifiant unique dans l’ensemble du système, fourni par ce dernier (champ obligatoire).

Name

nom du contexte, qui doit être obligatoirement renseigné sur la plate-forme (champ obligatoire).

Identifier

identifiant unique donné au contexte (champ obligatoire).
- S’il est généré par la solution logicielle Vitam, cet identifiant se compose du préfixe CT, suivi d’un tiret et d’une suite de 6 chiffres incrémentés automatiquement.
- Il peut également être généré par l’application à l’origine de sa création[44]. S’il est généré par une application externe, il ne doit comprendre ni caractère accentué, ni virgule, ni apostrophe, ni parenthèse, ni espace, ni slash, ni élément de ponctuation, ou tout autre caractère spécial. Ne sont recommandés que l’underscore et le tiret comme séparateurs.

_v

SecurityProfile

identifiant du profil de sécurité associé au contexte (champ obligatoire).

EnableControl

contrôle sur les tenants (champ obligatoire) :
- si la valeur est « true », un contrôle est effectué sur le(s) tenant(s) et contrat(s) défini(s) dans le contexte applicatif quand une application externe accède aux services de la solution logicielle Vitam ;
- si la valeur est « false », aucun contrôle n’est effectué sur le(s) tenant(s) et contrat(s) défini(s) dans le contexte applicatif quand une application externe accède aux services de la solution logicielle Vitam ;
- si la valeur est « null » ou si le champ n’est pas présent dans le contexte applicatif importé, la solution logicielle Vitam la gère comme la valeur précédente et enregistre la valeur « false » : aucun contrôle n’est effectué sur le(s) tenant(s) et contrat(s) défini(s) dans le contexte applicatif quand une application externe accède aux services de la solution logicielle Vitam.

Status

statut « ACTIVE » ou « INACTIVE » (champ obligatoire).
Si le contexte applicatif importé ne contient pas de statut, la solution logicielle Vitam enregistre par défaut la valeur « INACTIVE ».

CreationDate

date de création du contexte, fournie par le système (champ obligatoire).

LastUpdate

dernière date de modification du contexte, fournie et mise à jour par le système (champ obligatoire).

ActivationDate

date d’activation (champ facultatif).

DeactivationDate

date de désactivation (champ facultatif).

Permissions

Un bloc Permissions (champ facultatif), pouvant être vide, détaille le périmètre du contexte, tenant par tenant. Il comprend :
- le tenant dans lequel vont s’appliquer un ou plusieurs contrats (tenant – champ obligatoire si le bloc Permissions n’est pas vide) ;
- le(s) identifiant(s) de(s) contrat(s) d’accès appliqué(s) sur le tenant (AccessContracts – champ facultatif) ;
- le(s) identifiant(s) de(s) contrat(s) d’entrée appliqué(s) sur le tenant (IngestContracts – champ facultatif).

Le contexte applicatif n’est pas déclaré dans le message ArchiveTransfer du SEDA.

En revanche, il est enregistré dans le journal des opérations sous forme d’identifiant de l’opération (agIdApp).

6.2.4.3. Mécanismes mis en œuvre par la solution logicielle Vitam

La solution logicielle Vitam intègre un référentiel des contextes applicatifs, administrable par un utilisateur doté des droits adéquats (administrateur fonctionnel et/ou technique) et géré dans une collection particulière[45].

Ce référentiel est multi-tenant. Il est administrable et journalisé depuis le tenant d’administration.

Il est possible de réaliser les opérations présentées ci-dessous.

6.2.4.3.1. Import

Au moment de l’installation de la solution logicielle Vitam

La solution logicielle Vitam intègre par défaut des habilitations, automatiquement importés lors de l’initialisation de la plate-forme, dans le but de permettre un accès direct à l’ensemble de ses services. En plus d’un certificat applicatif, utilisé pour déployer la solution logicielle Vitam, et d’un profil de sécurité, référençant l’ensemble des permissions, elle fournit un contexte applicatif, donnant accès à l’ensemble des tenants.

Il s’agit d’une opération d’administration, tracée dans le journal des opérations du tenant d’administration (« MASTERDATA »)[46].

Après installation de la solution logicielle Vitam

Dans la solution logicielle Vitam, il est possible d’importer uniquement sur le tenant d’administration 1 à n contexte(s) applicatif(s) sous la forme d’un fichier JSON.
Par cet import, 1 à n contexte(s) applicatif(s) sont ajoutés au référentiel des contextes applicatifs.
Il est également possible de créer un contexte applicatif depuis l’APP VitamUI « Contextes applicatifs ».
Il s’agit d’une opération d’administration (« MASTERDATA »), tracée dans le journal des opérations du tenant d’administration[47].

Lors de cet import, l’opération peut aboutir aux statuts suivants :

Statut

Motifs

Succès

Opération réalisée sans rencontrer de problèmes particuliers.

Échec[48]

Sans journalisation :
- Import d’un référentiel sous la forme d’un fichier qui n’est pas au format JSON ;
- Import d’un référentiel sous la forme d’un fichier qui n’est pas correctement formaté au format JSON ;
- Import d’un référentiel dont au moins un des champs contient une injection HTML ;
- import d’un contexte applicatif dans lequel une valeur ne correspond pas au type d’indexation du champ défini dans l’ontologie (ex : valeur textuelle dans un champ de type « DATE »).

Avec journalisation :
- import d’un contexte applicatif dont l’identifiant existe déjà dans le système sur un tenant en mode « esclave » ;
- import d’un fichier JSON dans lequel un contexte ne déclare pas d’identifiant[49], d’intitulé, de profil de sécurité, de permissions[50] ;
- import d’un contexte applicatif dans lequel un champ ne contient pas de valeur. Il peut s’agir des champs : Identifier[51], Name, SecurityProfile, Status, IngestContracts et AccessContracts[52] ;
- import d’un contexte applicatif qui déclare un contrat d’entrée et/ou d’accès non référencé(s) dans la solution logicielle Vitam.

Point d’attention :
Il est possible d’importer un référentiel complet, comprenant plusieurs items, en une seule fois. La solution logicielle Vitam ne comptabilisera qu’une seule opération, et ne prend pas en compte dans le journal des opérations la création unitaire des différents items compris dans le référentiel importé. Afin d’optimiser la traçabilité de la création des différents référentiels d’habilitations, il est donc recommandé de créer ces derniers un par un.

6.2.4.3.2. Recherche

La solution logicielle Vitam permet de rechercher et d’accéder :

  • soit aux seuls contextes applicatifs ;

  • soit aux contextes applicatifs dans une forme plus contextualisée, c’est-à-dire avec les certificats applicatifs et le profil de sécurité auxquels ils sont associés[53]. Cette action relève d’un acte d’administration technique et ne fait pas l’objet d’une journalisation.

6.2.4.3.3. Modification

La modification des champs des contextes applicatifs est possible au moyen des API, de l’IHM standard et de l’APP VitamUI « Contextes applicatifs » depuis le tenant d’administration. Les champs modifiables sont :

  • depuis l’IHM standard :

    • le nom du contexte applicatif (Name) ;

    • le statut « Actif » ou « Inactif », correspondant aux valeurs « ACTIVE » et « INACTIVE » dans le système (Status) ;

    • le contrôle sur les tenants « Actif » ou « Inactif », correspondant aux valeurs « true » et « false » dans le système (EnableControl) ;

    • les dates d’activation (ActivationDate) et de désactivation (DeactivationDate) ;

  • depuis les API :

    • le profil de sécurité (SecurityProfile) ;

  • depuis l’APP VitamUI « Contextes applicatifs » :

    • le statut « ON » ou « OFF » ;

    • le profil de sécurité ;

    • le contrôle sur les tenants « ON » ou « OFF » Concernant la liste des permissions, il est possible de :

  • ajouter ou supprimer un tenant ;

  • pour un tenant donné :

    • ajouter ou supprimer un contrat d’entrée,

    • ajouter ou supprimer un contrat d’accès.

Points d’attention :

  • le statut du contexte applicatif doit être « Actif » (« ACTIVE ») pour pouvoir procéder à n’importe quelle action sur un tenant donné ou sur l’ensemble des tenants de la solution logicielle Vitam.

  • le contrôle sur les tenants du contexte applicatif doit être :

    • « Inactif » (« false ») pour pouvoir procéder à n’importe quelle action sur l’ensemble des tenants de la solution logicielle Vitam ;

    • « Actif » (« true »), complété par la définition de permissions sur au moins un tenant pour pouvoir procéder à des actions sur au moins un tenant de la solution logicielle Vitam.

Cette action provoque la création d’une nouvelle version du contexte applicatif modifié. Les différentes versions du référentiel font l’objet d’une sauvegarde sur les offres de stockage utilisées par la solution logicielle Vitam.

Il s’agit d’une opération d’administration (« MASTERDATA »), tracée dans le journal des opérations du tenant d’administration[54].

Lors de cette mise à jour, l’opération peut aboutir aux statuts suivants :

Statut

Motifs

Succès

Opération réalisée sans rencontrer de problèmes particuliers.

Échec[55]

- mise à jour d’un contexte applicatif dans lequel une valeur ne correspond pas au type d’indexation du champ défini dans l’ontologie (ex : valeur textuelle dans un champ de type « DATE ») ;
- ajout d’un contrat d’entrée et/ou d’accès non référencé(s) dans la solution logicielle Vitam ;
- suppression du profil de sécurité sans le remplacer par un autre profil de sécurité.

6.2.4.3.4. Suppression

La solution logicielle permet de supprimer unitairement des contextes applicatifs. Cette suppression peut avoir un impact sur les interactions entre l’application versante et/ou accédante et la solution logicielle Vitam. Cette opération ne s’effectue qu’au moyen des API et relève d’une opération d’administration technique.

Il s’agit d’une opération d’administration (« MASTERDATA »), tracée dans le journal des opérations du tenant d’administration[56].

6.2.4.3.5. Activation / Désactivation

La solution logicielle Vitam permet de rendre actif ou inactif un contexte applicatif, un contrat d’entrée ou un contrat d’accès.

En fonction du statut du contexte applicatif et de celui du contrat d’entrée associé, un versement de SIP sera autorisé ou non :

Contexte applicatif

Contrat d’entrée

Résultat

CAS 1

ACTIF

ACTIF

CAS 2

ACTIF

INACTIF

CAS 3

INACTIF

ACTIF

CAS 4

INACTIF

INACTIF

En fonction du statut du contexte applicatif et de celui du contrat d’accès associé, un accès au système sera autorisé ou non :

Contexte applicatif

Contrat d’accès

Résultat

CAS 1

ACTIF

ACTIF

CAS 2

ACTIF

INACTIF

CAS 3

INACTIF

ACTIF

CAS 4

INACTIF

INACTIF

La modification du statut engendre la mise à jour des champs :

  • Date de mise à jour ;

  • Date d’activation OU date de désactivation (service non encore implémenté).

6.2.4.3.6. Contrôle sur les tenants et les contrats

La solution logicielle Vitam permet d’activer ou de désactiver un contrôle sur les tenants et les contrats depuis un contexte applicatif.

  • si la valeur du contrôle est égale à « true », un contrôle est effectué sur le(s) tenant(s) et contrat(s) défini(s) dans le contexte applicatif quand une application externe accède aux services de la solution logicielle Vitam ;

  • si la valeur du contrôle est égale à « false » (valeur par défaut), aucun contrôle n’est effectué sur le(s) tenant(s) et contrat(s) défini(s) dans le contexte applicatif quand une application externe accède aux services de la solution logicielle Vitam. L’application externe accède alors à l’ensemble des tenants de la solution logicielle Vitam, avec pour seules restrictions les permissions qui lui sont attribuées dans le profil de sécurité associé au contexte applicatif.

Exemple 1 : L’application externe accédant aux services de la solution logicielle Vitam au moyen du contexte ci-dessous accédera aux seuls tenants 1 et 2, car le contexte applicatif définit un accès à ces deux tenants et impose un contrôle sur les tenants et les contrats associés.

Exemple 2 : L’application externe accédant aux services de la solution logicielle Vitam au moyen du contexte ci-dessous accédera à tous les tenants, car le contexte applicatif n’impose pas de contrôle sur les tenants et les contrats associés.

Point d’attention : le contexte d’administration, fourni par défaut par la solution logicielle Vitam ne fait aucun contrôle sur les tenants et les contrats (« false ») et donne accès à l’ensemble des services de la solution logicielle Vitam.

6.2.4.4. Conseils de mise en œuvre

À l’issue de cette dernière phase de réalisation de fonctionnalités concernant les habilitations, l’équipe projet Vitam est en mesure de fournir quelques recommandations de mise en œuvre. La solution logicielle permet de créer et de modifier les contextes applicatifs. Certaines actions peuvent avoir un impact sur les interactions entre l’application versante et/ou accédante et la solution logicielle Vitam.

6.2.4.4.1. Quand et comment créer un contexte applicatif ?

La création du contexte applicatif est un préalable à l’octroi de droits supplémentaires, d’entrée comme d’accès, dans la solution logicielle Vitam :

  • une application souhaitant réaliser des entrées ou accéder à des archives doit nécessairement être authentifiée au moyen d’un contexte applicatif déclarant un profil de sécurité ;

  • une application souhaitant réaliser des entrées ou accéder à des archives ne peut effectuer ces actions au moyen des seuls contrats, d’entrée comme d’accès. Dès qu’on souhaite connecter une application à la solution logicielle Vitam, il faut, avant toute chose, l’authentifier au moyen d’un certificat applicatif qui détermine un contexte applicatif, avant de lui associer un profil de sécurité et des contrats, préexistants ou créés à cette occasion.

La création d’un contexte applicatif peut intervenir à différents moments :

  • lors de l’initialisation de la plate-forme : il est obligatoire de disposer d’un contexte applicatif, en plus d’un certificat applicatif et d’un profil de sécurité, pour pouvoir utiliser les services de la solution logicielle Vitam. Cette dernière propose un contexte par défaut, destiné à être utilisé dans deux cas :

    • pour le déploiement de la plate-forme, afin de faciliter son installation ;

    • sur une plate-forme de tests ;

  • lors de l’intégration d’une nouvelle application devant accéder aux services de la solution logicielle Vitam. La déclaration d’un contexte applicatif dans la solution logicielle Vitam relève d’une opération d’administration technico-fonctionnelle. De fait, au moment de l’initialisation d’un nouveau contexte, il est recommandé de suivre les étapes suivantes :

Qui ?

Quoi ?

Via l’IHM Vitam ?

Administrateur fonctionnel/ technique

- définit ses besoins en termes d’habilitation :
Quel contexte applicatif utiliser ? quels droits associer à ce contexte applicatif ? quel profil de sécurité utiliser ? quels contrats associer ?
Les habilitations nécessaires existent-elles déjà ? Faut-il créer de nouvelles habilitations ?
Y a-t-il des besoins de sécurité particulier ?
- le cas échéant, liste les habilitations dont il a besoin[57].

Oui / Non

Administrateur technique

Le cas échéant, crée un profil de sécurité.

Non

Administrateur fonctionnel/ technique

Le cas échéant, crée un contexte applicatif, en l’associant à un profil de sécurité, créé pour l’occasion ou déjà existant.

Oui

Administrateur technique

Crée le nouveau certificat applicatif, en l’associant au contexte applicatif, créé pour l’occasion ou déjà existant.

Non

Administrateur fonctionnel

Le cas échéant :
- crée des contrats, d’entrée et/ou d’accès ;
- associe au contexte applicatif des contrats d’entrée et/ou d’accès.

Oui

Administrateur fonctionnel/ technique

Activation du contexte applicatif.

Oui

Administrateur technique / fonctionnel

Test avant utilisation courante.

Oui

Points d’attention :

  • La solution logicielle Vitam rend obligatoire l’intégration d’un contexte applicatif par défaut, afin de pouvoir initialiser et paramétrer la plate-forme. Ce contexte n’a pas vocation à être utilisé en production et doit, dans ce cas-là, être remplacé par un contexte de production.

  • Dans la mesure où un contexte doit être associé à un profil de sécurité, puis associé à un certificat applicatif, il est obligatoire de disposer au préalable d’un profil de sécurité à associer à ce contexte applicatif.

  • Pour assurer une étanchéité entre les tenants, il est préconisé d’associer un seul tenant par contexte. De cette manière, le mécanisme d’authentification d’une application externe à un tenant ne permet de verser et d’accéder qu’à ce seul tenant.

  • Le mécanisme de multi-tenant pour le contexte applicatif est mis en place pour le cas d’un système d’information des archives (SIA) qui devrait pouvoir accéder à plusieurs tenants.

  • Un même certificat ne peut être utilisé que par un contexte applicatif.

6.2.4.4.2. Comment nommer un contexte applicatif ?

Une application externe dispose d’un certificat applicatif, d’un profil de sécurité, d’un contexte applicatif et d’un à plusieurs contrats, d’entrée et/ou d’accès.
Au travers de ces différents référentiels, il s’agira de paramétrer les habilitations de ce seul service externe. C’est pourquoi, il est recommandé d’adopter des règles de nommage identiques dans les différents référentiels, en utilisant les éléments suivants :

  • nom de l’application versante ou accédante,

  • nom ou type d’objet archivé,

  • nom du service producteur,

  • code métier.

En sachant que :

  • un profil de sécurité peut être utilisé par des contextes applicatifs différents ;

  • un contexte applicatif peut être appelé par plusieurs certificats applicatifs ;

  • un contexte applicatif peut déterminer plusieurs tenants, ainsi que plusieurs contrats, d’entrée comme d’accès ;

  • un service producteur peut avoir plusieurs contrats différents ;

  • une application versante ou accédante peut détenir plusieurs contrats.

6.2.4.4.3. Comment paramétrer l’identifiant d’un contexte applicatif ?

Comportement par défaut

Par défaut, la solution logicielle Vitam génère les identifiants des habilitations de la manière suivante (mode « maître ») :

Type d’habilitation

Paramétrage de l’identifiant

Profil de sécurité

préfixe SEC_PROFILE, suivi d’un tiret et d’une suite de 6 chiffres incrémentés automatiquement

Contexte applicatif

préfixe CT, suivi d’un tiret et d’une suite de 6 chiffres incrémentés automatiquement

Contrat d’entrée

préfixe IC, suivi d’un tiret et d’une suite de 6 chiffres incrémentés automatiquement

Contrat d’accès

préfixe AC, suivi d’un tiret et d’une suite de 6 chiffres incrémentés automatiquement

Ce fonctionnement par défaut diffère pour les tenants 0 et 1, où la solution logicielle Vitam est paramétrée par défaut pour ne pas générer d’identifiants pour :

  • les contrats d’entrée et d’accès, les profils d’archivage, les profils de sécurité et les contextes sur le tenant 1, dit « tenant d’administration »,

  • les contrats d’entrée et d’accès sur le tenant 0[58].

Il est, bien sûr, possible de modifier ce paramétrage par défaut.

Paramétrage des identifiants

Il est possible de paramétrer les identifiants, afin qu’ils soient générés par l’application à l’origine de la création des différentes habilitations concernées (mode « esclave »). Cette opération peut avoir lieu :

  • soit au moment de l’installation de la plate-forme,

  • soit après installation, sur une plate-forme en activité. Dans ce cas-là, une interruption temporaire de service sera à prévoir, car l’opération nécessite le redémarrage du service « vitam-functional-administration ». Pour ce faire, il faut modifier le fichier de configuration « functional-administration.conf », qui définit, entre autres, par tenant, les habilitations dont la solution logicielle Vitam ne génère pas d’identifiant[59].


Fichier de configuration listant, par tenant, les habilitations dont l’identifiant n’est pas généré par Vitam

Il est possible d’associer à un tenant l’habilitation pour laquelle on souhaite voir généré l’identifiant par une application externe, en ajoutant au tenant concerné le nom de l’habilitation concerné. Le nom de l’habilitation concernée doit être écrit de la manière suivante :

  • « INGEST_CONTRACT » pour les contrats d’entrée ;

  • « ACCESS_CONTRACT » pour les contrats d’accès ;

  • « SECURITY_PROFILE » pour les profils de sécurité (utile seulement sur le tenant d’administration) ;

  • « CONTEXT » pour les contextes applicatifs (utile seulement sur le tenant d’administration) . La gestion des identifiants peut varier d’un tenant à l’autre, comme c’est le cas dans le tableau où :

  • le tenant 1, d’administration, est esclave pour les contrats d’entrée et d’accès, les profils d’archivage, les profils de sécurité et les contextes ;

  • le tenant 0 ne l’est que pour les contrats d’entrée et d’accès. Cette opération relève d’un acte d’exploitation technique. Elle implique le redémarrage du/des composant(s), selon qu’il soit mono-instance ou multi-instances.

Points d’attention :

  • En mode « esclave », il est fortement recommandé de faire débuter les référentiels avec d’autres chaînes de caractères que celle définies en mode « maître » ;

  • Par ailleurs, en mode « esclave », l’identifiant ne doit comprendre ni caractère accentué, ni virgule, ni apostrophe, ni parenthèse, ni espace, ni slash, ni élément de ponctuation, ou tout autre caractère spécial. Ne sont recommandés que l’underscore et le tiret comme séparateurs ;

  • Il ne faut pas oublier de répercuter cette modification sur le site secondaire.

6.2.4.4.4. Quel accès aux contextes applicatifs ?

Gestion des droits La gestion des habilitations relève d’opérations d’administration. Il est donc recommandé d’en limiter l’accès :

  • un administrateur fonctionnel et/ou technique peut avoir accès à l’exhaustivité de ces référentiels et les mettre à jour ;

  • seul un administrateur technique a vocation à gérer les certificats applicatifs et les certificats personnels ;

  • une application versante et/ou accédante pourra, le cas échéant, avoir accès aux seules habilitations la concernant, en lecture seule ;

  • un tiers n’a pas vocation a prendre connaissance des contextes applicatifs et des profils de sécurité, pour des raisons de sécurité.

Restitution sur une IHM

Dans un projet d’implémentation, il est possible d’envisager la restitution de cette fonctionnalité sur une IHM dédiée. Dans VitamUI, l’APP « Contextes applicatifs » permet de :

  • accéder à :

  • la liste des contextes créés sur un tenant donné,

  • au détail d’un contexte applicatif ;

  • créer un nouveau contexte,

  • modifier un contexte.

Profil de sécurité, contrats d’entrée et d’accès sont obligatoirement associés à un contexte applicatif. S’il y a conception d’écrans permettant d’afficher contextes, profils de sécurité, contrats d’entrée et d’accès, il est recommandé de prendre en considération les liens entre eux.

6.2.4.4.5. Conseils d’utilisation du contexte applicatif

Intitulé

Description

Niveau de recommandation

Accès aux services de la solution logicielle Vitam à l’initialisation de la plate-forme

Lors de l’installation de la plate-forme, la solution logicielle Vitam crée automatiquement un contexte par défaut, permettant de déployer la plate-forme et d’y effectuer les premiers paramétrages.

Obligatoire

Désactiver ou supprimer le contexte par défaut

Il est interdit de désactiver ou de supprimer le contexte par défaut, sans quoi on risque de ne plus pouvoir accéder aux services de la solution logicielle Vitam au moment de son initialisation ou à l’occasion d’actes d’exploitation.

Interdit

Application devant accéder aux services de la solution logicielle Vitam

Dès qu’on souhaite connecter une application à la solution logicielle Vitam, il faut, avant toute chose, l’authentifier au moyen d’un certificat applicatif qui détermine un contexte applicatif, avant de lui associer un profil de sécurité et des contrats, préexistants ou créés à cette occasion.

Obligatoire

Application devant accéder aux services de la solution logicielle Vitam

Pour assurer une étanchéité entre les tenants, il est préconisé d’associer un seul tenant par contexte applicatif. De cette manière, le mécanisme d’authentification d’une application externe à un tenant ne permet de verser et d’accéder qu’à ce seul tenant.

Conseillé

Système d’information des archives (SIA) devant accéder à tous les tenants et services de la solution logicielle Vitam

Le SIA devant pouvoir accéder à plusieurs tenants et à l’ensemble des services disponibles, il est recommandé de lui attribuer un contexte applicatif lui permettant d’accéder à l’ensemble des tenants et des services de la solution logicielle Vitam.

Recommandé

6.2.5. Contrat d’entrée

6.2.5.1. Description

Le contrat d’entrée formalise les interactions correspondant à des transferts d’archives entre un fournisseur d’archives ou service producteur au sens de la norme NF Z44-022, son opérateur ou service versant au sens de la norme NF Z44-022 et la solution logicielle Vitam ou service d’archives au sens de la norme NF Z44-022.

Il détermine en option :

  • la destination ou point de rattachement des archives transférées dans le système (correspond à une unité archivistique issue d’un bordereau de transfert (unité archivistique dite « standard ») ou correspondant à un niveau de plan de classement ou d’arbre de positionnement) ;

  • l’/les unité(s) archivistique(s)sous le(s)quelle(s) une unité archivistique présente dans un bordereau de transfert et déclarant un nœud de rattachement peut se rattacher ;

  • si les unités archivistiques contenues dans un bordereau de transfert peuvent, doivent ou ne doivent pas déclarer un nœud de rattachement ;

  • si la solution logicielle Vitam doit enregistrer automatiquement en base de données dans un champ spécifique les règles de gestion héritées par l’/les unité(s) archivistique(s) contenue(s) dans un bordereau de transfert ;

  • le(s) profil(s) d’archivage attendu(s) pour les transferts d’archives (messages ArchiveTransfer au sens de la norme NF Z44-022) effectués en application de ce contrat (facultatif) ;

  • si le bordereau doit obligatoirement contenir des objets binaires de type « Master » ;

  • le(s) type(s) d’usage(s) autorisé(s) dans un bordereau de transfert, dans le cas d’ajout(s) ultérieur(s) d’objet(s) binaire(s) à un groupe d’objets techniques ;

  • le(s) format(s) des objets binaires autorisé(s) dans un bordereau de transfert ;

  • si le bordereau peut contenir des objets binaires dont le format n’est pas identifié ;

  • la stratégie de stockage à utiliser pour les unités archivistiques, les groupes d’objets techniques et/ou les objets binaires (fichier numériques) au moyen de la déclaration d’un contrat de gestion.

6.2.5.2. Formalisation

6.2.5.2.1. Dans un fichier JSON

Un contrat d’entrée prend la forme d’un fichier JSON, pouvant contenir 1 à n contrat(s) d’entrée[60].

Exemple de contrat d’entrée à importer dans la solution logicielle Vitam :

[
  {
    "Identifier": "IC-00001",
    "Name": "Contrat d’entrée_du_SIA"
 }
 ]

Un contrat d’entrée donné doit obligatoirement comporter les informations suivantes :

  • identifiant signifiant. Ce champ est obligatoire seulement s’il est généré par l’application à l’origine de sa création (Identifier). Si cet identifiant est généré par la solution logicielle Vitam, il n’est pas nécessaire de le renseigner dans le fichier JSON ;

  • nom du contrat (Name).

D’autres informations, facultatives – une description (Description), un statut (Status), une date d’activation (ActivationDate) et de désactivation (DeactivationDate), une liste de profils d’archivage (ArchiveProfiles), des options de contrôles sur les rattachements des unités archivistiques (LinkParentId, CheckParentId et CheckParentLink), des options de contrôles sur les objets binaires entrants (MasterMandatory, EveryDataObjectVersion ou DataObjectVersion, EveryFormatType ou FormatType, FormatUnidentifiedAuthorized), des options de contrôle sur les documents signés (SignaturePolicy), des paramétrages sur l’enregistrement des règles de gestion héritées dans un champ spécifique (ComputeInheritedRulesAtIngest) et sur la gestion du stockage (ManagementContractId) – peuvent venir compléter ces informations.

À noter pour certaines d’entre elles que, si elles ne sont pas renseignées, la solution logicielle Vitam fournira automatiquement une valeur par défaut :

  • valeur «  INACTIVE » pour le statut ;

  • valeur « AUTHORIZED » relative à l’option permettant à un bordereau de transfert à contenir des nœuds de rattachement, sans que cela soit obligatoire (CheckParentLink) ;

  • valeur « true » pour l’option rendant obligatoire la présence d’un objet binaire de type « Master » dans un transfert (MasterMandatory) ;

  • valeur « false » pour l’option autorisant un à plusieurs usage(s) dans le cas de l’ajout d’un objet binaire à un groupe d’objets techniques existant (EveryDataObjectVersion) ;

  • valeur « false » pour l’option autorisant le transfert d’objets binaires dont le format n’est pas identifié (FormatUnidentifiedAuthorized) ;

  • valeur « true » pour l’option permettant d’accepter tous les formats des objets binaires dans un bordereau de transfert (EveryFormatType) ;

  • valeur « false » pour l’option permettant d’activer l’enregistrement en base de données des règles de gestion héritées dans un champ spécifique (ComputeInheritedRulesAtIngest),

  • valeur « false » pour les contrôles sur les signatures (DeclaredSignature), le jeton d’horodatage (DeclaredTimestamp), les preuves complémentaires (DeclaredAdditionalProof) si le contrôle sur les documents signés (SignedDocument) a pour valeur « ALLOWED » ou « MANDATORY ». Ces informations sont détaillées dans la section suivante du présent document. La solution appliquera par ailleurs une stratégie par défaut, si aucun contrat de gestion n’est défini dans le contrat d’entrée.

6.2.5.2.2. Dans la solution logicielle Vitam

Les contrats d’entrée sont enregistrés dans la base de données MongoDB, dans la collection « IngestContract », sous la forme d’enregistrements au format JSON. Le contrat d’entrée est modélisé en JSON comme suit[61] :

Champ

Description

_id

identifiant unique par tenant, fourni par le système (champ obligatoire).

Identifier

identifiant unique donné au contrat, généré automatiquement par le système (champ obligatoire).
- S’il est généré par la solution logicielle Vitam, cet identifiant se compose du préfixe IC, suivi d’un tiret et d’une suite de 6 chiffres incrémentés automatiquement.
- Il peut également être généré par l’application à l’origine de sa création[62]. S’il est généré par une application externe, il ne doit comprendre ni caractère accentué, ni virgule, ni apostrophe, ni parenthèse, ni espace, ni slash, ni élément de ponctuation, ou tout autre caractère spécial. Ne sont recommandés que l’underscore et le tiret comme séparateurs.

_tenant

tenant dans lequel le contrat s’applique (champ obligatoire).

Name

nom du contrat, qui doit être obligatoirement renseigné sur la plate-forme (champ obligatoire).

Description

description du contrat (champ obligatoire).

_v

version du contrat (champ obligatoire).

Status

statut « ACTIVE » ou « INACTIVE » (champ obligatoire).
Si le contrat d’entrée importé ne contient pas de statut, la solution logicielle Vitam enregistre par défaut la valeur « INACTIVE ».

CreationDate

date de création du contrat, fournie par le système (champ obligatoire).

LastUpdate

dernière date de modification du contrat, fournie et mise à jour par le système (champ obligatoire).

ActivationDate

si le contrat est actif, date d’activation du contrat, fournie par le système (champ obligatoire).

DeactivationDate

si le contrat est inactif, date de désactivation du contrat (champ facultatif).

ArchiveProfiles

identifiant du(des) profil(s) d’archivage associé(s) au contrat (champ facultatif).

ManagementContractId

identifiant du contrat de gestion associé au contrat (champ facultatif).
Si ce champ n’est pas renseigné, une stratégie par défaut sera appliquée, sans qu’elle soit définie dans le contrat d’entrée.

LinkParentId

identifiant du nœud auquel on souhaite rattacher les SIP versés (champ facultatif).

CheckParentId

identifiant(s) du/des noeud(s) sous le(s)quel(s) une unité archivistique présente dans un bordereau de transfert et déclarant un nœud de rattachement peut se rattacher (champ facultatif).

CheckParentLink

option permettant de contrôler la déclaration de nœuds de rattachement dans un bordereau de transfert (valeur par défaut : « AUTHORIZED » – champ obligatoire).
Ce champ peut avoir comme valeurs :
- « AUTHORIZED » : autorise un bordereau de transfert à contenir des nœuds de rattachement, sans que cela soit obligatoire ;
- « REQUIRED » : rend obligatoire la présence d’au moins un nœud de rattachement dans un bordereau de transfert ;
- « UNAUTHORIZED » : interdit la présence de nœuds de rattachement dans un bordereau de transfert.

ComputeInheritedRulesAtIngest

paramètre permettant d’activer l’enregistrement automatique des règles de gestion héritées par une unité archivistique en base de données dans un champ spécifique (valeur par défaut : « false » – champ obligatoire).

MasterMandatory

option permettant de rendre obligatoire ou non la présence d’un objet binaire de type « Master » dans un transfert (valeur par défaut : « true » – champ obligatoire).

EveryDataObjectVersion / DataObjectVersion

usage(s) autorisé(s) dans le cas de l’ajout d’un objet binaire à un groupe d’objets techniques existant. Il peut s’agir de :
- tous les usages (EveryDataObjectVersion, valeur par défaut : « false » – champ obligatoire),
- une sélection d’usages (DataObjectVersion – champ facultatif). Ces usages peuvent être : archives physiques (PhysicalMaster), archives numériques originales (BinaryMaster), copies de diffusion (Dissemination), contenu textuel (TextContent), vignettes (Thumbnail).

EveryFormatType / FormatType

format(s) des objets binaires autorisé(s) dans un bordereau de transfert. Il peut s’agir de :
- tous les formats (EveryFormatType, valeur par défaut : « true » – champ obligatoire),
- une sélection de formats (FormatType – champ facultatif), correspondant à une liste de PUID de format(s) autorisé(s) lors du transfert d’objets binaires.

FormatUnidentifiedAuthorized

option autorisant le transfert d’objets binaires dont le format n’est pas identifié (valeur par défaut : « false » – champ obligatoire).

SignaturePolicy

contrôles sur les documents signés électroniquement (champ facultatif) pour :
- contrôler la présence de documents signés (champ SignedDocument – champ obligatoire). Ce champ peut avoir comme valeurs :
- « ALLOWED » : autorise un bordereau de transfert à contenir des archives signées, sans que cela soit obligatoire ;
- « MANDATORY » : rend obligatoire la présence d’archives signées dans un bordereau de transfert ;
- « FORBIDDEN » : interdit la présence de documents signés
- si les documents signés sont autorisés ou obligatoires, vérifier la présence de la signature (DeclaredSignature - valeur par défaut : « false » – champ facultatif), d’un jeton d’horodatage (DeclaredTimestamp - valeur par défaut : « false » – champ facultatif) et de preuves complémentaires (DeclaredAdditionalProof - valeur par défaut : « false » – champ facultatif).

La solution logicielle Vitam impose de déclarer un contrat d’entrée, au moment de la demande de transfert à un service d’archives (message ArchiveTransfer), dans le bloc ArchivalAgreement.

Par ailleurs, dans le journal des opérations, le contrat d’entrée est enregistré dans le champ rightsStatementIdentifier pour toute opération de transfert (INGEST).

6.2.5.3. Mécanismes mis en œuvre par la solution logicielle Vitam

La solution logicielle Vitam intègre un référentiel des contrats d’entrée, administrable par un utilisateur doté des droits adéquats (administrateur fonctionnel ou technique) et géré dans une collection particulière[63].
Ce référentiel est propre à chaque tenant de la solution logicielle Vitam. Il est possible de réaliser les opérations présentées ci-dessous.

6.2.5.3.1. Import

Dans la solution logicielle Vitam, il est possible d’importer sur n’importe quel tenant 1 à n contrat(s) d’entrée sous la forme d’un fichier JSON. Par cet import, 1 à n contrat(s) d’entrée sont ajoutés au référentiel des contrats d’entrée.

Il est également possible de créer un contrat d’entrée depuis l’APP VitamUI « Contrats d’entrée ».

Il s’agit d’une opération d’administration (« MASTERDATA »), tracée dans le journal des opérations du tenant sur lequel a eu lieu l’opération[64]. Lors de cet import, l’opération peut aboutir aux statuts suivants :

Statut

Motifs

Succès

Opération réalisée sans rencontrer de problèmes particuliers.

Échec[65]

Sans journalisation :
- Import d’un référentiel sous la forme d’un fichier qui n’est pas au format JSON ;
- Import d’un référentiel sous la forme d’un fichier qui n’est pas correctement formaté au format JSON ;
- Import d’un référentiel dont au moins un des champs contient une injection HTML ;
- import d’un contrat d’entrée dans lequel une valeur ne correspond pas au type d’indexation du champ défini dans l’ontologie (ex : valeur textuelle dans un champ de type « DATE »).
Avec journalisation :
- import d’un contrat d’entrée dont l’identifiant existe déjà dans le système sur un tenant en mode « esclave » ;
- import d’un fichier JSON dans lequel un contrat d’entrée ne déclare pas d’identifiant[66] ou d’intitulé ;
- import d’un contrat d’entrée dans lequel un champ ne contient pas de valeur. Il peut s’agir des champs : Identifier[67] ou Name ;
- import d’un contrat d’entrée qui déclare un(des) profil(s) d’archivage non référencé(s) dans la solution logicielle Vitam ;
- import d’un contrat d’entrée qui déclare un contrat de gestion non référencé dans la solution logicielle Vitam ;
- import d’un contrat d’entrée acceptant à la fois tous les formats et n’en autorisant qu’une liste ;
- import d’un contrat d’entrée ne listant pas les formats autorisés, alors qu’il n’accepte pas tous les formats ;
- import d’un contrat d’entrée n’acceptant qu’une liste de formats, mais ne déclarant aucun format ;
- import d’un contrat d’entrée déclarant une liste de formats autorisés, mais dont au moins un format n’est pas référencé dans le référentiel des formats ;
- import d’un contrat d’entrée dont l’une des unités archivistiques présentes dans les options de rattachement n’existe pas dans la solution logicielle Vitam;
- import d’un contrat d’entrée interdisant les documents signés (SignedDocument = FORBIDDEN) et émettant d’autres contrôles sur les documents signés (DeclaredSignature, DeclaredTimestamp, DeclaredAdditionalProof),
- import d’un contrat d’entrée avec contrôle sur les documents signés sans paramètres (champ SignaturePolicy vide).

Point d’attention : Il est possible d’importer un référentiel complet, comprenant plusieurs items, en une seule fois. La solution logicielle Vitam ne comptabilisera qu’une seule opération, et ne prend pas en compte dans le journal des opérations la création unitaire des différents items compris dans le référentiel importé. Afin d’optimiser la traçabilité de la création des différents référentiels d’habilitations, il est donc recommandé de créer ces derniers un par un.

6.2.5.3.2. Modification

La modification des champs des contrats d’entrée est possible au moyen des API, de l’IHM standard et de l’APP VitamUI « Contrats d’entrée » depuis le tenant où ces derniers ont été importés.

Les champs modifiables sont :

  • depuis l’IHM standard et depuis l’APP VitamUI « Contrats d’entrée » :

    • le nom du contrat d’entrée (Name) ;

    • la description (Description) ;

    • le statut « Actif » ou « Inactif », correspondant aux valeurs « ACTIVE » et « INACTIVE » dans le système (Status) ;

  • depuis les API :

    • les dates d’activation (ActivationDate) et de désactivation (DeactivationDate).

Concernant les différentes options contenues dans un contrat d’entrée, il est possible de :

  • ajouter ou supprimer un à plusieurs profil(s) d’archivage (ArchiveProfiles) ;

  • ajouter ou supprimer un nœud auquel on souhaite rattacher les SIP versés (LinkParentId) ;

  • ajouter ou supprimer un à plusieurs noeud(s) sous le(s)quel(s) une unité archivistique présente dans un bordereau de transfert et déclarant un nœud de rattachement peut se rattacher (CheckParentId) ;

  • modifier l’option permettant de contrôler la déclaration de nœuds de rattachement dans un bordereau de transfert et devant correspondre à l’une de ces trois valeurs : « AUTHORIZED », « REQUIRED » et « UNAUTHORIZED » (CheckParentLink) ;

  • modifier l’option permettant d’enregistrer automatiquement en base de données les règles de gestion héritées et devant correspondre à l’une de ces deux valeurs : « true » ou « false » (ComputeInheritedRulesAtIngest) ;

  • modifier l’option permettant de rendre obligatoire ou non la présence d’un objet binaire de type « Master » dans un transfert et devant correspondre à l’une de ces deux valeurs : « true » ou « false » (MasterMandatory) ;

  • modifier l’option autorisant le transfert d’objets binaires dont le format n’est pas identifié et devant correspondre à l’une de ces deux valeurs : « true » ou « false » (FormatUnidentifiedAuthorized) ;

  • modifier l’(es) usage(s) autorisé(s) dans le cas de l’ajout d’un objet binaire à un groupe d’objets techniques existant. Il peut s’agir de :

    • modifier l’option autorisant tous les usages et devant correspondre à l’une de ces deux valeurs : « true » ou « false » (EveryDataObjectVersion) ;

    • ajouter ou supprimer une sélection d’usages (DataObjectVersion), correspondant aux valeurs suivantes : « Original papier » (PhysicalMaster), « Original numérique » (BinaryMaster), « Diffusion » (Dissemination), « Contenu brut » (TextContent), « Vignette » (Thumbnail) ;

  • modifier les format(s) des objets binaires autorisé(s) dans un bordereau de transfert. Il peut s’agir de :

    • modifier l’option autorisant tous les formats (EveryFormatType) et devant correspondre à l’une de ces deux valeurs : « true » ou « false »,

    • ajouter ou supprimer une sélection de formats (FormatType), correspondant à une liste de PUID de format(s) autorisé(s) lors du transfert d’objets binaires.

  • modifier la stratégie de stockage à utiliser (ManagementContractId). Il peut s’agir de :

    • modifier la stratégie de stockage en remplaçant un contrat de gestion par un autre,

    • ajouter ou supprimer un contrat de gestion.

  • modifier, ajouter ou supprimer les contrôles sur les documents signés (SignaturePolicy). Il peut s’agir de :

    • modifier le contrôle sur les documents signés, devant correspondre à l’une de ces trois valeurs : « ALLOWED », « MANDATORY » et « FORBIDDEN » (SignedDocument),

    • modifier le contrôle sur les signatures (DeclaredSignature), le jeton d’horodatage (DeclaredTimestamp), les preuves complémentaires (DeclaredAdditionalProof).

Points d’attention :

  • Le statut du contrat d’entrée doit être « Actif » (« ACTIVE ») pour pouvoir procéder à des transferts d’archives sur un tenant donné.

  • Concernant l’option sur les formats autorisés dans un bordereau de transfert :

    • si l’option autorise tous les formats (« true »), alors la liste des formats devra être vide ;

    • si l’option n’autorise pas tous les formats (« false »), alors le contrat devra obligatoirement définir une liste de formats autorisés.

  • Si l’option sur la stratégie de stockage est supprimée, alors la stratégie par défaut sera implicitement appliquée pour tout transfert utilisant le contrat d’entrée.

  • Concernant le contrôle sur les archives signées électroniquement :

    • si le contrôle interdit les documents signés, alors le contrat ne peut pas définir de contrôles sur les signatures, jetons d’horodatage et preuves complémentaires ;

    • si le contrôle autorise ou rend obligatoires les documents signés, alors le contrat doit définir de contrôles sur les signatures, jetons d’horodatage et preuves complémentaires. Si ces contrôles ne sont pas définis, ils auront « false » comme valeur par défaut.

Cette action provoque la création d’une nouvelle version du contrat d’entrée modifié. Les différentes versions du référentiel font l’objet d’une sauvegarde sur les offres de stockage utilisées par la solution logicielle Vitam. Il s’agit d’une opération d’administration (« MASTERDATA »), tracée dans le journal des opérations du tenant sur lequel a eu lieu l’opération[68].

Lors de cette mise à jour, l’opération peut aboutir aux statuts suivants : |Statut|Motifs| |Succès|Opération réalisée sans rencontrer de problèmes particuliers.| |Échec[69]|Avec journalisation : (section à venir)|

6.2.5.3.3. Activation / Désactivation

La solution logicielle Vitam permet de rendre actif ou inactif un contexte applicatif, un contrat d’entrée ou un contrat de gestion. En fonction du statut du contexte applicatif et de celui du contrat d’entrée associé, un versement de SIP sera autorisé ou non :

  • avec une stratégie de stockage par défaut :

Contexte applicatif

Contrat d’entrée

Résultat

CAS 1

ACTIF

ACTIF

Transfert de SIP dans le système autorisé.

CAS 2

ACTIF

INACTIF

Transfert de SIP dans le système non autorisé.

CAS 3

INACTIF

ACTIF

Transfert de SIP dans le système non autorisé.

CAS 4

INACTIF

INACTIF

Transfert de SIP dans le système non autorisé.

  • avec un contrat de gestion définissant une stratégie de stockage particulière :

Contexte applicatif

Contrat d’entrée

Contrat de gestion

Résultat

CAS 1

ACTIF

ACTIF

ACTIF

Transfert de SIP dans le système autorisé.

CAS 2

ACTIF

ACTIF

INACTIF

Transfert de SIP dans le système non autorisé.

CAS 3

ACTIF

INACTIF

ACTIF

Transfert de SIP dans le système non autorisé.

CAS 4

ACTIF

INACTIF

INACTIF

Transfert de SIP dans le système non autorisé.

CAS 5

INACTIF

ACTIF

ACTIF

Transfert de SIP dans le système non autorisé.

CAS 6

INACTIF

ACTIF

INACTIF

Transfert de SIP dans le système non autorisé.

CAS 7

INACTIF

INACTIF

ACTIF

Transfert de SIP dans le système non autorisé.

CAS 8

INACTIF

INACTIF

INACTIF

Transfert de SIP dans le système non autorisé.

La modification du statut engendre la mise à jour des champs :

  • Date de mise à jour ;

  • Date d’activation OU date de désactivation (service non encore implémenté).

6.2.5.4. Conseils de mise en œuvre

À l’issue de cette dernière phase de réalisation de fonctionnalités concernant les habilitations, l’équipe projet Vitam est en mesure de fournir quelques recommandations de mise en œuvre. La solution logicielle permet de créer et de modifier les contrats d’entrée. Certaines actions peuvent avoir un impact sur les interactions entre l’application versante et/ou accédante et la solution logicielle Vitam.

6.2.5.4.1. Quand et comment créer un contrat d’entrée ?

Tout SIP qui doit être transféré dans la solution logicielle Vitam doit obligatoirement renseigner un contrat d’entrée dans son bordereau de transfert (ArchivalAgreement), sans quoi son transfert échouera.

De fait, avant tout transfert, il est recommandé de :

  • vérifier si le contrat d’entrée déclaré dans le SIP existe dans le système mettant en œuvre la solution logicielle Vitam ;

  • créer un nouveau contrat d’entrée s’il n’existe pas ;

  • le cas échéant, utiliser un contrat d’entrée préalablement créé, destiné à être utilisé par l’application ;

  • vérifier que le contrat d’entrée est actif ;

  • vérifier que le contrat d’entrée est bien déclaré dans le contexte de l’application et que ce dernier est actif ;

  • le cas échéant, vérifier que le(s) profil(s) d’archivage déclaré(s) dans le contrat d’entrée est(sont) actif(s) ;

  • le cas échéant, vérifier que le contrat de gestion déclaré dans le contrat d’entrée est(sont) actif(s).

Quand on crée un contrat d’entrée déclarant un nœud de rattachement ou des cônes de positionnement des rattachements, il faut veiller à ce que ces nœuds déclarés existent dans la solution logicielle Vitam sur le tenant, sans quoi ils ne pourront être enregistrés dans le contrat.

6.2.5.4.2. Comment nommer un contrat d’entrée ?

Une application externe dispose d’un certificat applicatif, d’un profil de sécurité, d’un contexte applicatif et d’un à plusieurs contrats, d’entrée et/ou d’accès.

Au travers de ces différents référentiels, il s’agira de paramétrer les habilitations de ce seul service externe. C’est pourquoi, il est recommandé d’adopter des règles de nommage identiques dans les différents référentiels, en utilisant les éléments suivants :

  • nom de l’application versante ou accédante,

  • nom ou type d’objet archivé,

  • nom du service producteur,

  • code métier.

En sachant que :

  • un profil de sécurité peut être utilisé par des contextes applicatifs différents ;

  • un contexte applicatif peut être appelé par plusieurs certificats applicatifs ;

  • un contexte applicatif peut déterminer plusieurs tenants, ainsi que plusieurs contrats, d’entrée comme d’accès ;

  • un service producteur peut avoir plusieurs contrats différents ;

  • une application versante ou accédante peut détenir plusieurs contrats.

6.2.5.4.3. Comment paramétrer l’identifiant d’un contrat d’entrée ?

Comportement par défaut

Par défaut, la solution logicielle Vitam génère les identifiants des habilitations de la manière suivante (mode « maître ») :

Type d’habilitation

Paramétrage de l’identifiant

Profil de sécurité

préfixe SEC_PROFILE, suivi d’un tiret et d’une suite de 6 chiffres incrémentés automatiquement

Contexte applicatif

préfixe CT, suivi d’un tiret et d’une suite de 6 chiffres incrémentés automatiquement

Contrat d’entrée

préfixe IC, suivi d’un tiret et d’une suite de 6 chiffres incrémentés automatiquement

Contrat d’accès

préfixe AC, suivi d’un tiret et d’une suite de 6 chiffres incrémentés automatiquement

Contrat de gestion

préfixe MC, suivi d’un tiret et d’une suite de 6 chiffres incrémentés automatiquement

Ce fonctionnement par défaut diffère pour les tenants 0 et 1, où la solution logicielle Vitam est paramétrée par défaut pour ne pas générer d’identifiants pour :

  • les contrats d’entrée et d’accès, les profils d’archivage, les profils de sécurité et les contextes sur le tenant 1, dit « tenant d’administration »,

  • les contrats d’entrée et d’accès sur le tenant 0[70]. Il est, bien sûr, possible de modifier ce paramétrage par défaut.

Paramétrage des identifiants

Il est possible de paramétrer les identifiants, afin qu’ils soient générés par l’application à l’origine de la création des différentes habilitations concernées (mode « esclave »). Cette opération peut avoir lieu :

  • soit au moment de l’installation de la plate-forme,

  • soit après installation, sur une plate-forme en activité. Dans ce cas-là, une interruption temporaire de service sera à prévoir, car l’opération nécessite le redémarrage du service « vitam-functional-administration ».

Pour ce faire, il faut modifier le fichier de configuration « functional-administration.conf », qui définit, entre autres, par tenant, les habilitations dont la solution logicielle Vitam ne génère pas d’identifiant[71].


Fichier de configuration listant, par tenant, les habilitations dont l’identifiant n’est pas généré par Vitam

Il est possible d’associer à un tenant l’habilitation pour laquelle on souhaite voir généré l’identifiant par une application externe, en ajoutant au tenant concerné le nom de l’habilitation concerné. Le nom de l’habilitation concernée doit être écrit de la manière suivante :

  • « INGEST_CONTRACT » pour les contrats d’entrée ;

  • « ACCESS_CONTRACT » pour les contrats d’accès ;

  • « MANAGEMENT_CONTRACT » pour les contrats de gestion ;

  • « SECURITY_PROFILE » pour les profils de sécurité (utile seulement sur le tenant d’administration) ;

  • « CONTEXT » pour les contextes applicatifs (utile seulement sur le tenant d’administration). La gestion des identifiants peut varier d’un tenant à l’autre, comme c’est le cas dans le tableau où :

  • le tenant 1, d’administration, est esclave pour les contrats d’entrée et d’accès, les profils d’archivage, les profils de sécurité et les contextes ;

  • le tenant 0 ne l’est que pour les contrats d’entrée et d’accès. Cette opération relève d’un acte d’exploitation technique. Elle implique le redémarrage du/des composant(s), selon qu’il soit mono-instance ou multi-instances.

Points d’attention :

  • En mode « esclave », il est fortement recommandé de faire débuter les référentiels avec d’autres chaînes de caractères que celle définies en mode « maître » ;

  • Par ailleurs, en mode « esclave », l’identifiant ne doit comprendre ni caractère accentué, ni virgule, ni apostrophe, ni parenthèse, ni espace, ni slash, ni élément de ponctuation, ou tout autre caractère spécial. Ne sont recommandés que l’underscore et le tiret comme séparateurs ;

  • Il ne faut pas oublier de répercuter cette modification sur le site secondaire.

6.2.5.4.4. Quel accès aux contrats d’entrée ?

Gestion des droits La gestion des habilitations relève d’opérations d’administration. Il est donc recommandé d’en limiter l’accès :

  • un administrateur fonctionnel et/ou technique peut avoir accès à l’exhaustivité de ces référentiels et les mettre à jour ;

  • seul un administrateur technique a vocation à gérer les certificats applicatifs et les certificats personnels ;

  • une application versante et/ou accédante pourra, le cas échéant, avoir accès aux seules habilitations la concernant, en lecture seule ;

  • un tiers n’a pas vocation a prendre connaissance des contextes applicatifs et des profils de sécurité, pour des raisons de sécurité.

Restitution sur une IHM

Dans un projet d’implémentation, il est possible d’envisager la restitution de cette fonctionnalité sur une IHM dédiée.

Dans VitamUI, l’APP « Contrats d’entrée » permet de :

  • accéder à :

  • la liste des contrats d’entrée créés sur un tenant donné,

  • au détail d’un contrat d’entrée ;

  • créer un nouveau contrat,

  • modifier un contrat. Profil de sécurité, contrats d’entrée et d’accès sont obligatoirement associés à un contexte applicatif. S’il y a conception d’écrans permettant d’afficher contextes, profils de sécurité, contrats d’entrée et d’accès, il est recommandé de prendre en considération les liens entre eux.

6.2.5.4.5. Comment modifier un contrat d’entrée ?

Il est possible de modifier un contrat d’entrée utilisé dans un contexte applicatif particulier. Il est conseillé de suivre les étapes suivantes en fonction du contexte d’utilisation du contrat :

Contexte

Action

Avec un contrat d’entrée

Désactivation du contexte applicatif ou du seul contrat d’entrée, le temps de procéder à la modification.

Avec un contrat d’entrée et un contrat d’accès

Désactivation du seul contrat d’entrée, le temps de procéder à la modification, de manière à ne pas interrompre l’accès associé au contexte applicatif.

Avec plusieurs contrats d’entrée

Désactivation d’un seul contrat d’entrée, le temps de procéder à la modification, de manière à ne pas interrompre l’utilisation des autres contrats d’entrée associés au contexte applicatif.

Avec un ou plusieurs contrats d’entrée

- Création d’un nouveau contrat d’entrée contenant les modifications à apporter.
- Association de ce contrat d’entrée au contexte applicatif.
- Activation de ce contrat d’entrée.
- Déclaration de ce nouveau contrat d’entrée dans les bordereaux de transfert.
- Désactivation de l’ancien contrat d’entrée.
- Suppression du lien entre l’ancien contrat d’entrée et le contexte applicatif.

6.2.6. Contrat d’accès

6.2.6.1. Description

Le contrat d’accès formalise les interactions correspondant à des accès aux fonds et aux archives entre un service externe et la solution logicielle Vitam. Il détermine les filtres suivants :

  • le tenant à utiliser, obligatoirement déclaré et correspondant au tenant sur lequel a été importé le contrat ;

  • 0 à n catégorie(s) de règle de gestion arrivée(s) à échéance ;

  • tous ou 0 à n service(s) producteur(s) ;

  • tous ou 0 à n nœud(s) au(x)quel(s) il aura accès ;

  • tous ou 0 à n nœud(s) au(x)quel(s) il n’aura pas accès ;

  • tous ou 0 à n usage(s) au(x)quel(s) il aura accès.

Il permet de :

  • octroyer des droits de lecture et d’écriture. Les droits d’écriture correspondent, par exemple, aux possibilités de modifier les métadonnées de description et de gestion des unités archivistiques ;

  • restreindre le droit d’écriture aux seules métadonnées de description ;

  • activer la génération de logs en cas d’accès aux objets binaires conservés sur la plate-forme.

6.2.6.2. Formalisation

6.2.6.2.1. Dans un fichier JSON

Un contrat d’accès prend la forme d’un fichier JSON, pouvant contenir 1 à n contrat(s) d’accès[72].

Exemple de contexte applicatif à importer dans la solution logicielle Vitam :

[
  {
    "Identifier": "AC-00001",
    "Name": "Contrat d’accès_du_SIA"
 }
 ]

Un contrat d’accès donné doit obligatoirement comporter les informations suivantes :

  • identifiant signifiant. Ce champ est obligatoire seulement s’il est généré par l’application à l’origine de sa création (Identifier). Si cet identifiant est généré par la solution logicielle Vitam, il n’est pas nécessaire de le renseigner dans le fichier JSON ;

  • nom du contrat (Name).

D’autres informations, facultatives – une description (Description), un statut (Status), une date d’activation (ActivationDate) et de désactivation (DeactivationDate), des options d’accès en fonction des services producteurs (EveryOriginatingAgency ou OriginatingAgencies), de l’usage des objets binaires (EveryDataObjectVersion ou DataObjectVersion), de filtre sur des catégories de règle de gestion arrivées à échéance (RuleCategoryToFilter) ou de niveaux de description (RootUnits et ExcludeRootUnits), des droits d’écriture (WritingPermission et WritingRestrictedDesc) ou encore une option de génération de logs d’accès (AccessLog) –, peuvent venir compléter ces informations.

À noter pour certaines d’entre elles que, si elles ne sont pas renseignées, la solution logicielle Vitam fournira automatiquement une valeur par défaut :

  • valeur « INACTIVE » pour le statut ;

  • valeur « false » pour l’option autorisant l’accès tous les usage(s) (EveryDataObjectVersion) ;

  • valeur « false » pour les droits d’écriture sur les archives (WritingPermission) ;

  • valeur « false » pour les droits permettant de modifier l’ensemble des métadonnées d’une unité archivistique ou ses seules métadonnées descriptives (WritingRestrictedDesc) ;

  • valeur « INACTIVE » pour l’option permettant de générer automatiquement des logs sur les accès.

Ces informations sont détaillées dans la section suivante du présent document. La solution n’appliquera pas, par ailleurs, de filtre sur les règles de gestion arrivées à échéance, si aucun filtre sur le sujet n’est défini dans le contrat d’accès.

6.2.6.2.2. Dans la solution logicielle Vitam

Les contrats d’accès sont enregistrés dans la base de données MongoDB, dans la collection « AccessContract », sous la forme d’enregistrements au format JSON. Le contrat d’accès est composé des éléments suivants[73] :

Champ

Description

_id

identifiant unique par tenant, fourni par le système (champ obligatoire).

Identifier

identifiant unique donné au contrat, généré automatiquement par le système (champ obligatoire).
- S’il est généré par la solution logicielle Vitam, cet identifiant se compose du préfixe AC, suivi d’un tiret et d’une suite de 6 chiffres incrémentés automatiquement.
- Il peut également être généré par l’application à l’origine de sa création[74]. S’il est généré par une application externe, il ne doit comprendre ni caractère accentué, ni virgule, ni apostrophe, ni parenthèse, ni espace, ni slash, ni élément de ponctuation, ou tout autre caractère spécial. Ne sont recommandés que l’underscore et le tiret comme séparateurs.

_tenant

tenant dans lequel le contrat s’applique, fourni par le système ( champ obligatoire).

Name

nom du contrat, qui doit être obligatoirement renseigné sur la plate-forme (champ obligatoire).

Description

description du contrat (champ facultatif).

_v

version du contrat, fournie par le système (champ obligatoire).

Status

statut « ACTIVE » ou « INACTIVE » (obligatoire).
Si le contrat d’accès importé ne contient pas de statut, la solution logicielle Vitam enregistre par défaut la valeur « INACTIVE ».

CreationDate

date de création du contrat, fournie par le système (champ obligatoire).

LastUpdate

dernière date de modification du contrat, fournie et mise à jour par le système (champ obligatoire).

ActivationDate

si le contrat est actif, date d’activation du contrat, fournie par le système (champ obligatoire).

DeactivationDate

si le contrat est inactif, date de désactivation du contrat (champ facultatif).

EveryOriginatingAgency / OriginatingAgencies

service(s) producteur(s) associé(s) au contrat et accédant de fait au(x) fonds et archives déclarant ce(s) même(s) service(s) producteur(s). Il peut s’agir de :
- tous les services producteurs (EveryOriginatingAgency, valeur par défaut : « false » – champ obligatoire),
- une sélection de services producteurs (OriginatingAgencies – champ facultatif).

EveryDataObjectVersion / DataObjectVersion

usage(s) au(x)quel(s) le contrat donne accès. Il peut s’agir de :
- tous les usages (EveryDataObjectVersion, valeur par défaut : « false » – champ obligatoire),
- une sélection d’usages (DataObjectVersion – champ facultatif). Ces usages peuvent être : archives physiques (PhysicalMaster), archives numériques originales (BinaryMaster), copies de diffusion (Dissemination), contenu textuel (TextContent), vignettes (Thumbnail).

RootUnits

identifiant du nœud ou des nœuds au(x)quel(x) et à partir des/duquel(s) on souhaite donner accès (champ facultatif).

ExcludeRootUnits

identifiant du nœud ou des nœuds au(x)quel(s) et à partir de(s)quel(s) on souhaite interdire l’accès (champ facultatif).

WritingPermission

droit d’écriture sur les archives (valeur par défaut : « false » – champ obligatoire).

WritingRestrictedDesc

droit de modification de l’ensemble des métadonnées d’une unité archivistique ou de ses seules métadonnées descriptives (valeur par défaut : « false » – champ obligatoire).

AccessLog

droit d’enregistrer les accès sur les objets binaires dans un log (valeur par défaut : « INACTIVE » – champ obligatoire).

RuleCategoryToFilter

catégorie(s) de règle de gestion arrivée(s) à échéance à filtrer (pas de valeur par défaut – champ facultatif).

Le contrat d’accès n’est actuellement pas déclaré dans le message ArchiveTransfer du SEDA.

La solution logicielle Vitam n’impose pas l’utilisation d’un contrat d’accès pour filtrer les accès à ses services au moyen des API.

Dans le journal des opérations, il est désormais enregistré dans le champ rightsStatementIdentifier pour toute opération de mise à jour des métadonnées de description et de gestion des unités archivistiques (UPDATE).

6.2.6.3. Mécanismes mis en œuvre par la solution logicielle Vitam

La solution logicielle Vitam intègre un référentiel des contrats d’accès, administrable par un utilisateur doté des droits adéquats (administrateur fonctionnel ou technique) et géré dans une collection particulière[75]. Ce référentiel est propre à chaque tenant de la solution logicielle Vitam. Il est possible de réaliser les opérations présentées ci-dessous.

6.2.6.3.1. Import

Dans la solution logicielle Vitam, il est possible d’importer sur n’importe quel tenant 1 à n contrat(s) d’accès sous la forme d’un fichier JSON.
Par cet import, 1 à n contrat(s) d’accès sont ajoutés au référentiel des contrats d’accès.
Il est également possible de créer un contrat d’accès depuis l’APP VitamUI « Contrats d’accès ».
Il s’agit d’une opération d’administration (« MASTERDATA »), tracée dans le journal des opérations du tenant sur lequel a eu lieu l’opération[76]. Lors de cet import, l’opération peut aboutir aux statuts suivants :

Statut

Motifs

Succès

Opération réalisée sans rencontrer de problèmes particuliers.

Échec[77]

Sans journalisation :
- Import d’un référentiel sous la forme d’un fichier qui n’est pas au format JSON ;
- Import d’un référentiel sous la forme d’un fichier qui n’est pas correctement formaté au format JSON ;
- Import d’un référentiel dont au moins un des champs contient une injection HTML ;
- import d’un contrat d’accès dans lequel une valeur ne correspond pas au type d’indexation du champ défini dans l’ontologie (ex : valeur textuelle dans un champ de type « DATE »).

Échec

Avec journalisation :
- import d’un contrat d’accès dont l’identifiant existe déjà dans le système sur un tenant en mode « esclave » ;
- import d’un fichier JSON dans lequel un contrat d’accès ne déclare pas d’identifiant[78] ou d’intitulé ;
- import d’un contrat d’accès dans lequel un champ ne contient pas de valeur. Il peut s’agir des champs : Identifier[79] ou Name.
(section à compléter)

Point d’attention : Il est possible d’importer un référentiel complet, comprenant plusieurs items, en une seule fois. La solution logicielle Vitam ne comptabilisera qu’une seule opération, et ne prend pas en compte dans le journal des opérations la création unitaire des différents items compris dans le référentiel importé. Afin d’optimiser la traçabilité de la création des différents référentiels d’habilitations, il est donc recommandé de créer ces derniers un par un.

6.2.6.3.2. Modification

La modification des champs des contrats d’accès est possible au moyen des API, de l’IHM standard et l’APP VitamUI « Contrat d’accès » depuis le tenant où ces derniers ont été importés.

Les champs modifiables sont :

  • depuis l’IHM standard et l’APP VitamUI « Contrats d’accès » :

    • le nom du contrat d’accès (Name) ;

    • la description (Description) ;

    • le statut « Actif » ou « Inactif », correspondant aux valeurs « ACTIVE » et « INACTIVE » dans le système (Status).

  • depuis les API :

    • les dates d’activation (ActivationDate) et de désactivation (DeactivationDate).

Concernant les différentes options contenues dans un contrat d’accès, il est possible de :

  • ajouter ou supprimer 1 à n nœuds de consultation (RootUnits) et/ou d’exclusion (ExcludeRootUnits) ;

  • ajouter, modifier ou supprimer 1 à n catégories de règle de gestion à filtrer (RuleCategoryToFilter) ;

  • modifier les usage(s) au(x)quel(s) l’accès est autorisé(s). Il peut s’agir de :

    • modifier l’option autorisant l’accès à tous les usages et devant correspondre à l’une de ces deux valeurs : « true » ou « false » (EveryDataObjectVersion) ;

    • ajouter ou supprimer une sélection d’usages (DataObjectVersion), correspondant aux valeurs suivantes : « Original papier » (PhysicalMaster), « Original numérique » (BinaryMaster), « Diffusion » (Dissemination), « Contenu brut » (TextContent), « Vignette » (Thumbnail) ;

  • modifier les service(s) producteur(s) au(x)quel(s) l’accès est autorisé(s). Il peut s’agir de :

    • modifier l’option autorisant l’accès à tous les services producteurs et devant correspondre à l’une de ces deux valeurs : « true » ou « false » (EveryOriginatingAgency) ;

    • ajouter ou supprimer une sélection de services producteurs (OriginatingAgencies), devant correspondre à des identifiants de services producteurs référencés dans le référentiel des services producteurs ;

  • modifier l’option permettant d’octroyer des droits d’écriture aux unités archivistiques et devant correspondre à l’une de ces deux valeurs : « true » ou « false » (WritingPermission) ;

  • modifier l’option permettant d’octroyer des droits de modification de l’ensemble des métadonnées d’une unité archivistique ou de ses seules métadonnées descriptives et devant correspondre à l’une de ces deux valeurs : « true » ou « false » (WritingRestrictedDesc) ;

  • modifier l’option permettant d’activer la génération de logs des accès et devant correspondre à l’une de ces deux valeurs : « true » ou « false » (AccessLog).

Points d’attention :

  • Le statut du contrat d’accès doit être « Actif » (« ACTIVE ») pour pouvoir accéder à des archives sur un tenant donné.

  • Il est obligatoire d’indiquer dans un contrat d’accès actif si le service externe, une fois authentifié par la solution logicielle Vitam, a accès :

    • à tous les services producteurs ou au moins à l’un d’entre eux,

    • à tous les usages ou au moins à l’un d’entre eux. Si aucun de ces éléments n’est renseigné, même si le contrat d’accès est actif, le service externe ne pourra accéder à aucun service de la solution logicielle Vitam.

Cette action provoque la création d’une nouvelle version du contrat d’accès modifié. Les différentes versions du référentiel font l’objet d’une sauvegarde sur les offres de stockage utilisées par la solution logicielle Vitam. Il s’agit d’une opération d’administration (« MASTERDATA »), tracée dans le journal des opérations du tenant sur lequel a eu lieu l’opération[80].

Lors de cette mise à jour, l’opération peut aboutir aux statuts suivants :

Statut

Motifs

Succès

Opération réalisée sans rencontrer de problèmes particuliers.

Échec[81]

Avec journalisation : (section à venir)

6.2.6.3.3. Activation / Désactivation

La solution logicielle Vitam permet de rendre actif ou inactif un contexte applicatif, un contrat d’entrée, un contrat de gestion ou un contrat d’accès. En fonction du statut du contexte applicatif et de celui du contrat d’accès associé, un accès au système sera autorisé ou non :

Contexte applicatif

Contrat d’accès

Résultat

CAS 1

ACTIF

ACTIF

Accès au système autorisé.

CAS 2

ACTIF

INACTIF

Accès au système non autorisé.

CAS 3

INACTIF

ACTIF

Accès au système non autorisé.

CAS 4

INACTIF

INACTIF

Accès au système non autorisé.

La modification du statut engendre la mise à jour des champs :

  • Date de mise à jour ;

  • Date d’activation OU date de désactivation (service non encore implémenté).

6.2.6.4. Conseils de mise en œuvre

6.2.6.4.1. Quand et comment créer un contrat d’accès ?

Pour accéder aux données conservées dans la solution logicielle Vitam, un service externe peut disposer :

  • soit d’un contexte applicatif, n’effectuant aucun contrôle sur le(s) tenant(s) et les contrat(s) (EnableControl = false),

  • soit d’un contrat d’accès, associé à un contexte applicatif et formalisant d’un point de vue fonctionnel ses accès.

Dans le cas de l’utilisation d’un contrat d’accès, une application ayant des droits d’administration de la solution logicielle Vitam, par exemple un système d’information archivistique (SIA), doit détenir un contrat d’accès lui permettant d’accéder à l’ensemble des fonds conservés dans la solution logicielle Vitam (EveryOriginatingAgency = true).

Pour une application transférant des archives dans la solution logicielle Vitam, la situation est la suivante :

  • si elle ne doit pas nécessairement consulter ses archives, une fois ces dernières transférées, il ne sera pas utile de lui attribuer un contrat d’accès ;

  • si elle a besoin de consulter ses archives et les journaux de transferts (journal du cycle de vie des unités archivistiques et des groupes d’objets techniques), il faudra créer un contrat d’accès lui permettant d’accéder à ses seules archives.

Points d’attention :

  • Il est obligatoire d’indiquer dans un contrat d’accès actif si le service externe, une fois authentifié par la solution logicielle Vitam, a accès :

    • à tous les services producteurs ou au moins à l’un d’entre eux,

    • à tous les usages ou à au moins l’un d’entre eux. Si aucun de ces éléments n’a été renseigné, même si le contrat d’accès est actif, le service externe ne pourra accéder à aucun service de la solution logicielle Vitam.

  • Le(s) nœud(s) déclaré(s) dans un contrat d’accès pour autoriser ou interdire l’accès doivent exister dans la solution logicielle Vitam, sans quoi il(s) ne pourra/ont être enregistré(s) dans le contrat.

  • Si on n’utilise pas de contrat d’accès pour filtrer les accès d’un service externe à la solution logicielle Vitam, il reviendra au front office d’assurer ces filtres.

6.2.6.4.2. Comment nommer un contrat d’accès ?

Une application externe dispose d’un certificat applicatif, d’un profil de sécurité, d’un contexte applicatif et d’un à plusieurs contrats, d’entrée et/ou d’accès.

Au travers de ces différents référentiels, il s’agira de paramétrer les habilitations de ce seul service externe. C’est pourquoi, il est recommandé d’adopter des règles de nommage identiques dans les différents référentiels, en utilisant les éléments suivants :

  • nom de l’application versante ou accédante,

  • nom ou type d’objet archivé,

  • nom du service producteur,

  • code métier.

En sachant que :

  • un profil de sécurité peut être utilisé par des contextes applicatifs différents ;

  • un contexte applicatif peut être appelé par plusieurs certificats applicatifs ;

  • un contexte applicatif peut déterminer plusieurs tenants, ainsi que plusieurs contrats, d’entrée comme d’accès ;

  • un service producteur peut avoir plusieurs contrats différents ;

  • une application versante ou accédante peut détenir plusieurs contrats.

6.2.6.4.3. Comment paramétrer l’identifiant d’un contrat d’accès ?

Comportement par défaut

Par défaut, la solution logicielle Vitam génère les identifiants des habilitations de la manière suivante (mode « maître ») :

Type d’habilitation

Paramétrage de l’identifiant

Profil de sécurité

préfixe SEC_PROFILE, suivi d’un tiret et d’une suite de 6 chiffres incrémentés automatiquement

Contexte applicatif

préfixe CT, suivi d’un tiret et d’une suite de 6 chiffres incrémentés automatiquement

Contrat d’entrée

préfixe IC, suivi d’un tiret et d’une suite de 6 chiffres incrémentés automatiquement

Contrat d’accès

préfixe AC, suivi d’un tiret et d’une suite de 6 chiffres incrémentés automatiquement

Contrat de gestion

préfixe MC, suivi d’un tiret et d’une suite de 6 chiffres incrémentés automatiquement

Ce fonctionnement par défaut diffère pour les tenants 0 et 1, où la solution logicielle Vitam est paramétrée par défaut pour ne pas générer d’identifiants pour :

  • les contrats d’entrée et d’accès, les profils d’archivage, les profils de sécurité et les contextes sur le tenant 1, dit « tenant d’administration »,

  • les contrats d’entrée et d’accès sur le tenant 0[82]. Il est, bien sûr, possible de modifier ce paramétrage par défaut.

Paramétrage des identifiants

Il est possible de paramétrer les identifiants, afin qu’ils soient générés par l’application à l’origine de la création des différentes habilitations concernées (mode « esclave »). Cette opération peut avoir lieu :

  • soit au moment de l’installation de la plate-forme,

  • soit après installation, sur une plate-forme en activité. Dans ce cas-là, une interruption temporaire de service sera à prévoir, car l’opération nécessite le redémarrage du service « vitam-functional-administration ».

Pour ce faire, il faut modifier le fichier de configuration « functional-administration.conf », qui définit, entre autres, par tenant, les habilitations dont la solution logicielle Vitam ne génère pas d’identifiant[83].


Fichier de configuration listant, par tenant, les habilitations dont l’identifiant n’est pas généré par Vitam

Il est possible d’associer à un tenant l’habilitation pour laquelle on souhaite voir généré l’identifiant par une application externe, en ajoutant au tenant concerné le nom de l’habilitation concerné. Le nom de l’habilitation concernée doit être écrit de la manière suivante :

  • « INGEST_CONTRACT » pour les contrats d’entrée ;

  • « ACCESS_CONTRACT » pour les contrats d’accès ;

  • « MANAGEMENT_CONTRACT » pour les contrats de gestion ;

  • « SECURITY_PROFILE » pour les profils de sécurité (utile seulement sur le tenant d’administration) ;

  • « CONTEXT » pour les contextes applicatifs (utile seulement sur le tenant d’administration).

La gestion des identifiants peut varier d’un tenant à l’autre, comme c’est le cas dans le tableau où :

  • le tenant 1, d’administration, est esclave pour les contrats d’entrée et d’accès, les profils d’archivage, les profils de sécurité et les contextes ;

  • le tenant 0 ne l’est que pour les contrats d’entrée et d’accès.

Cette opération relève d’un acte d’exploitation technique. Elle implique le redémarrage du/des composant(s), selon qu’il soit mono-instance ou multi-instances.

Points d’attention :

  • En mode « esclave », il est fortement recommandé de faire débuter les référentiels avec d’autres chaînes de caractères que celle définies en mode « maître » ;

  • Par ailleurs, en mode « esclave », l’identifiant ne doit comprendre ni caractère accentué, ni virgule, ni apostrophe, ni parenthèse, ni espace, ni slash, ni élément de ponctuation, ou tout autre caractère spécial. Ne sont recommandés que l’underscore et le tiret comme séparateurs ;

  • Il ne faut pas oublier de répercuter cette modification sur le site secondaire.

6.2.6.4.4. Quel accès aux contrats d’accès ?

Gestion des droits

La gestion des habilitations relève d’opérations d’administration. Il est donc recommandé d’en limiter l’accès :

  • un administrateur fonctionnel et/ou technique peut avoir accès à l’exhaustivité de ces référentiels et les mettre à jour ;

  • seul un administrateur technique a vocation à gérer les certificats applicatifs et les certificats personnels ;

  • une application versante et/ou accédante pourra, le cas échéant, avoir accès aux seules habilitations la concernant, en lecture seule ;

  • un tiers n’a pas vocation a prendre connaissance des contextes applicatifs et des profils de sécurité, pour des raisons de sécurité.

Restitution sur une IHM

Dans un projet d’implémentation, il est possible d’envisager la restitution de cette fonctionnalité sur une IHM dédiée.
Dans VitamUI, l’APP « Contrats d’accès » permet de :

  • accéder à :

  • la liste des contrats d’accès créés sur un tenant donné,

  • au détail d’un contrat d’accès ;

  • créer un nouveau contrat,

  • modifier un contrat.

Profil de sécurité, contrats d’entrée et d’accès sont obligatoirement associés à un contexte applicatif. S’il y a conception d’écrans permettant d’afficher contextes, profils de sécurité, contrats d’entrée et d’accès, il est recommandé de prendre en considération les liens entre eux.

6.2.6.4.5. Comment modifier un contrat d’accès ?

Il est possible de modifier un contrat d’accès utilisé dans un contexte applicatif particulier. Il est conseillé de suivre les étapes suivantes en fonction du contexte d’utilisation du contrat :

Contexte

Action

Avec un contrat d’accès

Désactivation du contexte ou du seul contrat d’accès, le temps de procéder à la modification

Avec un contrat d’accès et un contrat d’entrée

Désactivation du seul contrat d’accès, le temps de procéder à la modification, de manière à ne pas interrompre les transferts du contrat d’entrées associé au contexte applicatif.

Avec plusieurs contrats d’accès

Désactivation d’un seul contrat d’accès, le temps de procéder à la modification, de manière à ne pas interrompre l’utilisation des autres contrats d’accès associés au contexte applicatif.

Avec un ou plusieurs contrats d’accès

- Création d’un nouveau contrat d’accès contenant les modifications à apporter.
- Association de ce contrat d’accès au contexte applicatif.
- Activation de ce contrat d’accès.
- Désactivation de l’ancien contrat d’accès.
- Suppression du lien entre l’ancien contrat d’accès et le contexte applicatif.

6.2.7. Contrat de gestion

6.2.7.1. Description

Le contrat de gestion permet de définir une stratégie de stockage, voire de mettre en place une stratégie différenciée, dite multi-stratégie, pour les unités archivistiques, les groupes d’objets techniques et les objets binaires (fichiers numériques)[84].

Il détermine une stratégie de stockage déterminée pour :

  • les métadonnées correspondant aux unités archivistiques,

  • les métadonnées correspondant aux groupes d’objets techniques,

  • les objets binaires (fichiers numériques).

Il définit également :

  • une politique de préservation des objets numériques de manière générique ou de manière spécifique,

  • une stratégie d’identification pérenne.

Point d’attention :

  • Au terme de la version 8.0, les paramètres liés à la définition d’une politique de préservation ne sont qu’informatifs. En effet, ils ne sont actuellement pas applicables dans des workflows existants (opérations de préservation, opérations de suppression de versions d’objets à la demande).

  • Au terme de la version 8.0, la stratégie d’identification pérenne qu’il est possible de mettre en œuvre ne couvre que l’identification ARK.

6.2.7.2. Formalisation

6.2.7.2.1. Dans un fichier JSON

Un contrat de gestion prend la forme d’un fichier JSON, pouvant contenir 1 à n contrat(s) de gestion[85]. Exemple de contrat de gestion à importer dans la solution logicielle Vitam :

[
  {
    "Identifier": "MC-00001",
    "Name": "Contrat de gestion_du_SIA"
 }
 ]

Un contrat de gestion donné doit obligatoirement comporter les informations suivantes :

  • identifiant signifiant. Ce champ est obligatoire seulement s’il est généré par l’application à l’origine de sa création (Identifier). Si cet identifiant est généré par la solution logicielle Vitam, il n’est pas nécessaire de le renseigner dans le fichier JSON ;

  • nom du contrat (Name).

D’autres informations, facultatives – une description (Description), un statut (Status), une date d’activation (ActivationDate) et de désactivation (DeactivationDate), une définition de la gestion du stockage (Storage) et de la politique de préservation (VersionRetentionPolicy) et de la stratégie d’identification pérenne (PersistentIdentifierPolicy) – peuvent venir compléter ces informations.

À noter pour certaines d’entre elles que, si elles ne sont pas renseignées, la solution logicielle Vitam fournira automatiquement une valeur par défaut :

  • valeur «  INACTIVE » pour le statut,

  • valeur « true » pour la conservation de la version initiale de tous les usages d’objets et valeur « LAST » pour la conservation des versions intermédiaires quel que soit l’usage des objets.

Ces informations sont détaillées dans la section suivante du présent document.

6.2.7.2.2. Dans la solution logicielle Vitam

Les contrats de gestion sont enregistrés dans la base de données MongoDB, dans la collection « ManagementContract », sous la forme d’enregistrements au format JSON. Le contrat de gestion est modélisé en JSON comme suit[86] :

Champ

Description

_id

identifiant unique par tenant, fourni par le système (champ obligatoire).

Identifier

identifiant unique donné au contrat, généré automatiquement par le système (champ obligatoire).
- S’il est généré par la solution logicielle Vitam, cet identifiant se compose du préfixe MC, suivi d’un tiret et d’une suite de 6 chiffres incrémentés automatiquement.
- Il peut également être généré par l’application à l’origine de sa création[87]. S’il est généré par une application externe, il ne doit comprendre ni caractère accentué, ni virgule, ni apostrophe, ni parenthèse, ni espace, ni slash, ni élément de ponctuation, ou tout autre caractère spécial. Ne sont recommandés que l’underscore et le tiret comme séparateurs.

_tenant

tenant dans lequel le contrat s’applique (champ obligatoire).

Name

nom du contrat, qui doit être obligatoirement renseigné sur la plate-forme (champ obligatoire).

Description

description du contrat (champ obligatoire).

_v

version du contrat (champ obligatoire).

Status

statut « ACTIVE » ou « INACTIVE » (champ obligatoire).
Si le contrat de gestion importé ne contient pas de statut, la solution logicielle Vitam enregistre par défaut la valeur « INACTIVE ».

CreationDate

date de création du contrat, fournie par le système (champ obligatoire).

LastUpdate

dernière date de modification du contrat, fournie et mise à jour par le système (champ obligatoire).

ActivationDate

si le contrat est actif, date d’activation du contrat, fournie par le système (champ obligatoire).

DeactivationDate

si le contrat est inactif, date de désactivation du contrat (champ facultatif).

Storage

définition d’une stratégie de stockage (champ facultatif) pour :
- les métadonnées correspondant aux unités archivistiques (UnitStrategy – champ facultatif) ;
- les métadonnées correspondant aux groupes d’objets techniques (ObjectGroupStrategy – champ facultatif) ;
- les métadonnées correspondant aux objets binaires (ObjectStrategy – champ facultatif).

VersionRetentionPolicy

définition d’une politique de préservation (champ obligatoire) pour :
- tous les usages :
-> conservation de la valeur initiale des objets (InitialVersion – champ obligatoire), dont la valeur est obligatoirement égale à « true » (valeur par défaut : « true » ;
-> conservation des versions intermédiaires des objets (IntermediaryVersion – champ obligatoire), dont la valeur peut être égale à « ALL » ou à « LAST » (valeur par défaut : « LAST) ;
- un usage en particulier (Usages – champ facultatif) :
-> nom de l’usage d’objet concerné (UsageName – champ facultatif), dont la valeur peut être égale à « BinaryMaster, Dissemination, TextContent, Thumbnail, PhysicalMaster) ;
-> conservation de la valeur initiale des objets (InitialVersion – champ facultatif), dont la valeur est obligatoirement égale à « true » pour les objets d’usage « BinaryMaster » ;
-> conservation des versions intermédiaires des objets (IntermediaryVersion – champ facultatif), dont la valeur peut être égale à « ALL », à « LAST » ou « NONE », ce dernier n’étant pas accepté pour les objets d’usage « BinaryMaster ».

PersistentIdentifierPolicy

définition d’une politique de préservation (champ obligatoire) pour :
- un type d’identification pérenne, dont la valeur doit être égale à « ARK » (PersistentIdentifierPolicyType – champ obligatoire) ;
- une autorité nommante en particulier (PersistentIdentifierAuthority – champ facultatif), correspondant à un numéro de 5 ou 9 chiffres pour l’identification de type ARK. Si le contrat de gestion importé ne contient pas d’autorité nommante, la solution logicielle Vitam enregistre par défaut la valeur « 0 » ;
- un périmètre donné :
-> les unités archivistiques associées à un groupe d’objets techniques, dont la valeur est égale à « true » ou « false » (PersistentIdentifierUnit – champ obligatoire). Si le contrat de gestion importé ne contient pas de valeur, la solution logicielle Vitam enregistre par défaut la valeur « false ».
-> un à plusieurs usage(s) (PersistentIdentifierUsages – champ obligatoire, mais pouvant être vide) :
->>nom de l’usage d’objet concerné (UsageName – champ facultatif), dont la valeur peut être égale à « BinaryMaster, Dissemination, TextContent, Thumbnail, PhysicalMaster) ;
->> génération d’un identifiant pérenne pour la version initiale des objets (InitialVersion – champ obligatoire), dont la valeur est égale à « true » ou « false ». Si le contrat de gestion importé ne contient pas de valeur, la solution logicielle Vitam enregistre par défaut la valeur « false ».
->> génération d’un identifiant pérennes pour les versions intermédiaires des objets (IntermediaryVersion – champ obligatoire), dont la valeur peut être égale à « ALL », « LAST » ou « NONE ».

La solution logicielle Vitam n’impose pas l’utilisation d’un contrat de gestion, en proposant une stratégie de stockage active par défaut.

6.2.7.3. Mécanismes mis en œuvre par la solution logicielle Vitam

La solution logicielle Vitam intègre un référentiel des contrats de gestion, administrable par un utilisateur doté des droits adéquats (administrateur fonctionnel ou technique) et géré dans une collection particulière[88].

Ce référentiel est propre à chaque tenant de la solution logicielle Vitam.
Il est possible de réaliser les opérations présentées ci-dessous.

6.2.7.3.1. Import

Dans la solution logicielle Vitam, il est possible d’importer sur n’importe quel tenant 1 à n contrat(s) de gestion sous la forme d’un fichier JSON. Par cet import, 1 à n contrat(s) de gestion sont ajoutés au référentiel des contrats de gestion.

Il est également possible de créer un contrat de gestion depuis l’APP VitamUI « Contrats de gestion ».

Il s’agit d’une opération d’administration (« MASTERDATA »), tracée dans le journal des opérations du tenant sur lequel a eu lieu l’opération[89].

Lors de cet import, l’opération peut aboutir aux statuts suivants :

Statut

Motifs

Succès

Opération réalisée sans rencontrer de problèmes particuliers.

Échec[90]

Sans journalisation :
- Import d’un référentiel sous la forme d’un fichier qui n’est pas au format JSON ;
- Import d’un référentiel sous la forme d’un fichier qui n’est pas correctement formaté au format JSON ;
- Import d’un référentiel dont au moins un des champs contient une injection HTML ;
- Import d’un contrat de gestion dont le champ « Status » ne contient pas de valeur ou contient une valeur ne correspondant ni à « ACTIVE », ni à « INACTIVE » ;
- Import d’un contrat de gestion dans lequel une valeur ne correspond pas au type d’indexation du champ défini dans l’ontologie (ex : valeur textuelle dans un champ de type « DATE ») ou à la valeur attendue (ex : valeur autre que « ARK » pour le champ « PersistentIdentifierPolicyType »).

Échec

Avec journalisation :
- import d’un contrat de gestion dont l’identifiant existe déjà dans le système sur un tenant en mode « esclave » ;
- import d’un fichier JSON dans lequel un contrat de gestion ne déclare pas d’identifiant[91] ou d’intitulé ;
- import d’un contrat de gestion dans lequel un champ obligatoire ne contient pas de valeur. Il peut s’agir des champs : Identifier[92] ou Name ;
- import d’un contrat de gestion qui déclare une(des) stratégie(s) de stockage non référencée(s) ou invalide(s) dans la solution logicielle Vitam ;
- import d’un contrat de gestion qui déclare un usage inconnu ou mal écrit dans la politique de préservation ou dans la stratégie d’identification pérenne ;
- import d’un contrat de gestion qui demande la conservation d’aucune version intermédiaire d’un objet d’usage « BinaryMaster » ;
- import d’un contrat de gestion qui définit une stratégie d’identification pérenne sans déclarer un champ obligatoire tel que : PersistentIdentifierPolicyType, PersistentIdentifierUsages, UsageName et IntermediaryVersion pour un usage donné.

Point d’attention : il est possible d’importer un référentiel complet, comprenant plusieurs items, en une seule fois. La solution logicielle Vitam ne comptabilisera qu’une seule opération, et ne prend pas en compte dans le journal des opérations la création unitaire des différents items compris dans le référentiel importé. Afin d’optimiser la traçabilité de la création des différents référentiels d’habilitations, il est donc recommandé de créer ces derniers un par un.

6.2.7.3.2. Modification

La modification des champs des contrats de gestion est possible au moyen des API,de l’IHM standard et l’APP VitamUI « Contrat de gestion » depuis le tenant où ces derniers ont été importés. Les champs modifiables sont :

  • depuis l’IHM standard et l’APP VitamUI « Contrats de gestion » :

    • le nom du contrat de gestion (Name) ;

    • la description (Description) ;

    • le statut « Actif » ou « Inactif », correspondant aux valeurs « ACTIVE » et « INACTIVE » dans le système (Status) ;

  • depuis les API :

    • les dates d’activation (ActivationDate) et de désactivation (DeactivationDate). Concernant les options contenues dans un contrat de gestion, il est possible de :

  • ajouter, modifier ou supprimer une stratégie de stockage appliquées aux unités archivistiques (UnitStrategy) ;

  • ajouter, modifier ou supprimer une stratégie de stockage appliquées aux groupes d’objets techniques (ObjectGroupStrategy) ;

  • ajouter, modifier ou supprimer une stratégie de stockage appliquées aux objets binaires (ObjectStrategy) ;

  • ajouter, modifier ou supprimer une stratégie d’identification pérenne (PersistentIdentifierPolicy).

Point d’attention :

  • Le statut du contrat de gestion doit être « Actif » (« ACTIVE ») pour pouvoir appliquer la stratégie de stockage qu’il définit.

  • Il n’est pas possible de supprimer une stratégie de stockage ou une stratégie d’identification pérenne depuis l’APP VitamUI « Contrats de gestion ».

Cette action provoque la création d’une nouvelle version du contrat de gestion modifié. Les différentes versions du référentiel font l’objet d’une sauvegarde sur les offres de stockage utilisées par la solution logicielle Vitam.

Il s’agit d’une opération d’administration (« MASTERDATA »), tracée dans le journal des opérations du tenant sur lequel a eu lieu l’opération[93].

Lors de cette mise à jour, l’opération peut aboutir aux statuts suivants :

Statut

Motifs

Succès

Opération réalisée sans rencontrer de problèmes particuliers.

Échec[94]

Avec journalisation :
- mise à jour d’un contrat de gestion dans lequel une valeur ne correspond pas au type d’indexation du champ défini dans l’ontologie (ex : valeur textuelle dans un champ de type « DATE ») ;
- mise à jour d’une valeur par une valeur ne correspondant pas à la valeur attendu par le champ (ex : dans le champ « Status », remplacement de la valeur « ACTIVE » par la valeur « TOTO » au lieu de « INACTIVE ») ;
- ajout d’une stratégie de stockage non référencée par la solution logicielle Vitam ;
- mise à jour de l’identifiant d’un contrat de gestion par un identifiant existant déjà dans le système sur un tenant en mode « esclave » ;
- ajout d’un usage inconnu ou mal écrit dans la politique de préservation ;
- modification d’un contrat de gestion qui demande la conservation d’aucune version intermédiaire d’un objet d’usage « BinaryMaster ».

6.2.7.3.3. Activation / Désactivation

La solution logicielle Vitam permet de rendre actif ou inactif un contexte applicatif, un contrat d’entrée ou un contrat de gestion.
En fonction du statut du contexte applicatif et de celui du contrat d’entrée associé, un versement de SIP sera autorisé ou non :

  • avec une stratégie de stockage par défaut :

Contexte applicatif

Contrat d’entrée

Résultat

CAS 1

ACTIF

ACTIF

Transfert de SIP dans le système autorisé.

CAS 2

ACTIF

INACTIF

Transfert de SIP dans le système non autorisé.

CAS 3

INACTIF

ACTIF

Transfert de SIP dans le système non autorisé.

CAS 4

INACTIF

INACTIF

Transfert de SIP dans le système non autorisé.

  • avec un contrat de gestion définissant une stratégie de stockage particulière :

Contexte applicatif

Contrat d’entrée

Contrat de gestion

Résultat

CAS 1

ACTIF

ACTIF

ACTIF

Transfert de SIP dans le système autorisé.

CAS 2

ACTIF

ACTIF

INACTIF

Transfert de SIP dans le système non autorisé.

CAS 3

ACTIF

INACTIF

ACTIF

Transfert de SIP dans le système non autorisé.

CAS 4

ACTIF

INACTIF

INACTIF

Transfert de SIP dans le système non autorisé.

CAS 5

INACTIF

ACTIF

ACTIF

Transfert de SIP dans le système non autorisé.

CAS 6

INACTIF

ACTIF

INACTIF

Transfert de SIP dans le système non autorisé.

CAS 7

INACTIF

INACTIF

ACTIF

Transfert de SIP dans le système non autorisé.

CAS 8

INACTIF

INACTIF

INACTIF

Transfert de SIP dans le système non autorisé.

La modification du statut engendre la mise à jour des champs :

  • Date de mise à jour ;

  • Date d’activation OU date de désactivation (service non encore implémenté).

6.2.7.4. Conseils de mise en œuvre

6.2.7.4.1. Quand et comment créer un contrat de gestion ?

La création d’un contrat de gestion n’est pas obligatoire quand un service externe se connectant à la solution logicielle Vitam n’utilise qu’une seule stratégie de stockage. En effet, la solution logicielle Vitam n’impose pas l’utilisation d’un contrat de gestion. Par défaut, sera utilisée la stratégie configurée lors de l’installation de la plate-forme.

En revanche, quand on souhaite assurer un stockage particulier, différent de la stratégie par défaut, pour un type d’archives en particulier, que ce soient des unités archivistiques, des groupes d’objets techniques et/ou des objets binaires, il sera nécessaire de créer un contrat de gestion. Le choix d’une multi-stratégie peut s’expliquer par le souhait d’offrir des niveaux de service différents, en termes de stockage, pour des raisons :

  • de coûts,

  • de gestion des risques (mettre à disposition davantage de copies pour des données dont on veut garantir à tout prix la pérennité et moins de copies pour des documents éliminables à court terme),

  • d’accès (déporter sur des offres froides des objets binaires peu consultés et conserver les objets très consultés sur des offres chaudes),

  • de contexte (tiers-archivage).

La création d’un contrat de gestion s’avère également nécessaire si l’on souhaite définir une stratégie d’identification pérenne.

La création de contrats de gestion peut intervenir à différents moments :

  • lors de l’initialisation de la plate-forme :

    • si l’on souhaite mettre en place différents niveaux de service de stockage en définissant plusieurs stratégies de stockage, en plus de la stratégie par défaut, il est recommandé de créer des contrats de gestion utilisant ces différentes stratégies de stockage, correspondant à autant de niveaux de service ;

    • si l’on souhaite définir une ou plusieurs stratégie(s) d’identification pérenne, il est nécessaire de créer au moins un contrat de gestion ;

  • lors de l’intégration d’une nouvelle application requérant un stockage particulier, différent de la stratégie de stockage par défaut, ou requérant une identification pérenne spécifique pour ses archives.

Point d’attention : Au terme de la version 5.RC, les paramètres liés à la définition d’une politique de préservation ne sont qu’informatifs. En effet, ils ne sont actuellement pas applicables dans des workflows existants (opérations de préservation, opérations de suppression de versions d’objets à la demande). La déclaration d’un contrat de gestion dans la solution logicielle Vitam relève d’une opération d’administration technico-fonctionnelle. Elle nécessite la configuration préalable d’une à plusieurs stratégie(s) de stockage.

De fait, au moment de la création d’un nouveau contrat de gestion, il est recommandé de suivre les étapes suivantes :

Qui ?

Quoi ?

Via l’IHM Vitam ?

Administrateur fonctionnel/ technique

- définit ses besoins en termes de stockage :
Quelles offres de stockage utiliser ? Combien d’offres ? de copies (unités archivistiques, groupes d’objets techniques, objets binaires) ? De stratégies de stockage appliquer ?
Les habilitations nécessaires existent-elles déjà ? Faut-il créer de nouvelles habilitations ?
Y a-t-il des besoins de sécurité particulier ?
- le cas échéant, liste les habilitations dont il a besoin.

Oui / Non

Administrateur technique

Le cas échéant, configurer une à plusieurs stratégie(s) de stockage

Non

Administrateur fonctionnel/ technique

Le cas échéant, crée un à plusieurs contrat(s) de gestion

Oui

Administrateur fonctionnel/ technique

Le cas échéant, documente les stratégies de stockage en usage, ainsi que les contrats de gestion associés.

Non

Administrateur fonctionnel

Le cas échéant, crée un contrat d’entrée et y associe un contrat de gestion

Oui

Administrateur fonctionnel/ technique

Activation des services (contrat de gestion, contrat d’entrée).

Oui

Administrateur technique / fonctionnel

Test avant utilisation courante.

Oui

Points d’attention :

  • La solution logicielle Vitam rend obligatoire l’intégration d’une stratégie de stockage par défaut, afin de pouvoir initialiser la plate-forme.

  • Afin de conserver une cohérence de stockage, il est recommandé d’utiliser une stratégie identique pour le stockage des métadonnées des unités archivistiques et des groupes d’objets techniques. Seuls les objets binaires (fichiers numériques) peuvent disposer d’une stratégie différente. Néanmoins, cette stratégie devra nécessairement déclarer une offre de stockage identique à celle des métadonnées[95].

6.2.7.4.2. Comment nommer un contrat de gestion ?

Une application externe dispose d’un certificat applicatif, d’un profil de sécurité, d’un contexte applicatif et d’un à plusieurs contrats, d’entrée, de gestion et/ou d’accès.

Au travers de ces différents référentiels, il s’agira de paramétrer les habilitations de ce seul service externe. C’est pourquoi, il est recommandé d’adopter des règles de nommage identiques dans les différents référentiels, en utilisant les éléments suivants :

  • nom de l’application versante ou accédante,

  • nom ou type d’objet archivé,

  • nom du service producteur,

  • code métier.

En sachant que :

  • un profil de sécurité peut être utilisé par des contextes applicatifs différents ;

  • un contexte applicatif peut être appelé par plusieurs certificats applicatifs ;

  • un contexte applicatif peut déterminer plusieurs tenants, ainsi que plusieurs contrats, d’entrée comme d’accès ;

  • un contrat de gestion peut être utilisé par plusieurs contrats d’entrée ;

  • un service producteur peut avoir plusieurs contrats différents ;

  • une application versante ou accédante peut détenir plusieurs contrats.

6.2.7.4.3. Comment paramétrer l’identifiant d’un contrat de gestion ?

Comportement par défaut

Par défaut, la solution logicielle Vitam génère les identifiants des habilitations de la manière suivante (mode « maître ») :

Type d’habilitation

Paramétrage de l’identifiant

Profil de sécurité

préfixe SEC_PROFILE, suivi d’un tiret et d’une suite de 6 chiffres incrémentés automatiquement

Contexte applicatif

préfixe CT, suivi d’un tiret et d’une suite de 6 chiffres incrémentés automatiquement

Contrat d’entrée

préfixe IC, suivi d’un tiret et d’une suite de 6 chiffres incrémentés automatiquement

Contrat d’accès

préfixe AC, suivi d’un tiret et d’une suite de 6 chiffres incrémentés automatiquement

Contrat de gestion

préfixe MC, suivi d’un tiret et d’une suite de 6 chiffres incrémentés automatiquement

Ce fonctionnement par défaut diffère pour les tenants 0 et 1, où la solution logicielle Vitam est paramétrée par défaut pour ne pas générer d’identifiants pour :

  • les contrats d’entrée, de gestion et d’accès, les profils d’archivage, les profils de sécurité et les contextes sur le tenant 1, dit « tenant d’administration »,

  • les contrats d’entrée et d’accès sur le tenant 0[96]. Il est, bien sûr, possible de modifier ce paramétrage par défaut.

Paramétrage des identifiants

Il est possible de paramétrer les identifiants, afin qu’ils soient générés par l’application à l’origine de la création des différentes habilitations concernées (mode « esclave »). Cette opération peut avoir lieu :

  • soit au moment de l’installation de la plate-forme,

  • soit après installation, sur une plate-forme en activité. Dans ce cas-là, une interruption temporaire de service sera à prévoir, car l’opération nécessite le redémarrage du service « vitam-functional-administration ».

Pour ce faire, il faut modifier le fichier de configuration « functional-administration.conf », qui définit, entre autres, par tenant, les habilitations dont la solution logicielle Vitam ne génère pas d’identifiant[97].


Fichier de configuration listant, par tenant, les habilitations dont l’identifiant n’est pas généré par Vitam

Il est possible d’associer à un tenant l’habilitation pour laquelle on souhaite voir généré l’identifiant par une application externe, en ajoutant au tenant concerné le nom de l’habilitation concerné. Le nom de l’habilitation concernée doit être écrit de la manière suivante :

  • « INGEST_CONTRACT » pour les contrats d’entrée ;

  • « ACCESS_CONTRACT » pour les contrats d’accès ;

  • « MANAGEMENT_CONTRACT » pour les contrats de gestion ;

  • « SECURITY_PROFILE » pour les profils de sécurité (utile seulement sur le tenant d’administration) ;

  • « CONTEXT » pour les contextes applicatifs (utile seulement sur le tenant d’administration). La gestion des identifiants peut varier d’un tenant à l’autre, comme c’est le cas dans le tableau où :

  • le tenant 1, d’administration, est esclave pour les contrats d’entrée et d’accès, les profils d’archivage, les profils de sécurité et les contextes ;

  • le tenant 0 ne l’est que pour les contrats d’entrée et d’accès.

Cette opération relève d’un acte d’exploitation technique. Elle implique le redémarrage du/des composant(s), selon qu’il soit mono-instance ou multi-instances.

Points d’attention :

  • En mode « esclave », il est fortement recommandé de faire débuter les référentiels avec d’autres chaînes de caractères que celle définies en mode « maître » ;

  • Par ailleurs, en mode « esclave », l’identifiant ne doit comprendre ni caractère accentué, ni virgule, ni apostrophe, ni parenthèse, ni espace, ni slash, ni élément de ponctuation, ou tout autre caractère spécial. Ne sont recommandés que l’underscore et le tiret comme séparateurs ;

  • Il ne faut pas oublier de répercuter cette modification sur le site secondaire.

6.2.7.4.4. Quel accès aux contrats de gestion ?

Gestion des droits

La gestion des habilitations relève d’opérations d’administration. Il est donc recommandé d’en limiter l’accès :

  • un administrateur fonctionnel et/ou technique peut avoir accès à l’exhaustivité de ces référentiels et les mettre à jour ;

  • seul un administrateur technique a vocation à gérer les certificats applicatifs et les certificats personnels, voire les contrats de gestion ;

  • une application versante et/ou accédante pourra, le cas échéant, avoir accès aux seules habilitations la concernant, en lecture seule ;

  • un tiers n’a pas vocation a prendre connaissance des contextes applicatifs et des profils de sécurité, pour des raisons de sécurité.

Restitution sur une IHM

Dans un projet d’implémentation, il est possible d’envisager la restitution de cette fonctionnalité sur une IHM dédiée.

Dans VitamUI, l’APP « Contrats de gestion » permet de :

  • accéder à :

  • la liste des contrats de gestion créés sur un tenant donné,

  • au détail d’un contrat de gestion ;

  • créer un nouveau contrat,

  • modifier un contrat.Profil de sécurité, contrats d’entrée et d’accès sont obligatoirement associés à un contexte applicatif. En outre, un contrat de gestion peut être associé à un contrat d’entrée. S’il y a conception d’écrans permettant d’afficher contextes, profils de sécurité, contrats d’entrée, de gestion et d’accès, il est recommandé de prendre en considération les liens entre eux.

6.2.7.4.5. Conseils d’utilisation d’un contrat de gestion

Intitulé

Description

Niveau de recommandation

Système d’archivage numérique ne définissant qu’une stratégie de stockage

Si le système utilise seulement la stratégie de stockage par défaut, initialisée lors de l’installation de la solution logicielle Vitam, il n’est pas nécessaire de créer de contrats de gestion.
En effet, l’utilisation d’un contrat de gestion n’est requise que si le système d’archivage numérique utilise plusieurs stratégies de stockage.

Recommandé

Système d’archivage numérique définissant plusieurs stratégies de stockage

Si le système utilise plusieurs stratégies de stockage, il est obligatoire de créer autant de contrats de gestion qu’il y a de stratégies envisagées.

Obligatoire

Système d’archivage numérique définissant plusieurs stratégies de stockage

Dans un contrat de gestion, il est recommandé de déclarer la même stratégie pour les métadonnées des unités archivistiques et des groupes d’objets techniques, afin de ne pas rompre la cohérence du stockage des données.

Recommandé

Système d’archivage numérique définissant plusieurs stratégies de stockage

Dans un contrat de gestion, il est possible de déclarer une stratégie différente pour, d’un côté, les métadonnées des unités archivistiques et des groupes d’objets techniques et, de l’autre, les objets binaires.

Possible

6.2.7.4.6. Comment modifier un contrat de gestion ?

Il est possible de modifier un contrat de gestion utilisé dans au moins un contrat d’entrée et contexte applicatif particuliers. Il est conseillé de suivre les étapes suivantes en fonction du contexte d’utilisation du contrat :

Contexte

Action

Avec un seul contrat d’entrée

Désactivation du seul contrat d’entrée déclarant le contrat de gestion, le temps de procéder à la modification, de manière à ne pas interrompre l’utilisation des autres contrats d’entrée associé au contexte applicatif.

Avec plusieurs contrats d’entrée

Désactivation du contexte applicatif et/ou interruption des services de transfert, le temps de procéder à la modification.

Avec un ou plusieurs contrats d’entrée

- Création d’un nouveau contrat de gestion contenant les modifications à apporter.
- Association de ce nouveau contrat de gestion au(x) contrat(s) d’entrée.
- Activation de ce contrat de gestion.
- Désactivation de l’ancien contrat de gestion.

6.3. Authentification

6.3.1. Mécanismes mis en œuvre par la solution logicielle Vitam

Un service externe doit toujours s’authentifier à la solution logicielle Vitam au moyen de son certificat applicatif qui détermine un contexte applicatif.

La solution logicielle Vitam effectuera les tâches et traitements suivants au niveau de l’API externe :

  • vérification que le certificat applicatif du service externe qui cherche à se connecter à la solution logicielle Vitam dispose d’un contexte applicatif qui existe bien dans le référentiel des contextes applicatifs et qui est actif ;

  • si un certificat personnel a été mis en place, vérification que le certificat personnel utilisé par le service externe pour se connecter à la solution logicielle Vitam est dans la liste des certificats personnels déclarés dans la solution logicielle Vitam ;

  • vérification sur le(s) tenant(s) déclaré(s) dans le contexte applicatif ;

  • vérification de l’existence de(s) contrat(s) d’entrée ou d’accès déclaré(s) dans le contexte applicatif ;

  • vérification de l’existence du profil de sécurité déclaré dans le contexte applicatif.

Le contrôle de cohérence entre le(s) contrat(s) d’entrée et le contexte applicatif s’effectuera au niveau de l’API interne, au moment du transfert d’un SIP. L’authentification est une étape préalable à toute opération d’entrée ou d’accès.

Si un élément fait défaut, le service externe ne pourra pas accéder aux services de la solution logicielle Vitam.

6.3.2. Conseils de mise en œuvre

À l’issue de cette dernière phase de réalisation de fonctionnalités concernant les habilitations, l’équipe projet Vitam est en mesure de fournir quelques recommandations de mise en œuvre.

6.3.2.1. Que faire lors de l’initialisation de la plate-forme ?

6.3.2.1.1. Comportement par défaut

La création d’un certificat applicatif, d’un profil de sécurité et d’un contexte applicatif est un préalable à l’accès aux services de la solution logicielle Vitam. C’est pourquoi, lors de l’installation de la solution logicielle Vitam, sont initialisés par défaut :

  • un profil de sécurité, référençant l’ensemble des permissions ;

  • un contexte applicatif, donnant accès à l’ensemble des tenants ;

  • un certificat applicatif.

Un administrateur fonctionnel n’a pas besoin, a priori, de créer de profil de sécurité ou de contexte applicatif pour accéder aux services de la solution logicielle Vitam récemment installée. Il s’agit d’un acte d’exploitation technique.

Points d’attention : après initialisation de la plate-forme, il n’est pas recommandé :

  • à l’administrateur fonctionnel de modifier ces habilitations par défaut, sous peine de se voir interdire l’accès aux services de la solution logicielle Vitam en raison d’une mauvaise manipulation ;

  • à l’administrateur technique et/ou fonctionnel de supprimer l’une de ces habilitations par défaut, pour la même raison.

6.3.2.1.2. Paramétrage de la plate-forme

Après ou au moment de l’initialisation de la plate-forme, il est recommandé de configurer les modalités de génération d’identifiant, tenant par tenant, pour chacune des habilitations concernées (profil de sécurité, contexte applicatif, contrat d’entrée, contrat d’accès).

Si la plate-forme a pour vocation une mise en production, il est nécessaire de :

  • utiliser un certificat applicatif propre,

  • créer un contexte applicatif propre, qui ne sont pas les certificat et contexte applicatifs fournis par défaut par la solution logicielle Vitam. Il peut être judicieux de faire de même avec le profil de sécurité, mais cette action n’est en rien obligatoire, si le profil de sécurité par défaut n’a pas vocation à être modifié.

Il s’agit d’un acte d’exploitation technique.

6.3.2.1.3. à quoi servent les habilitations par défaut ?

Les habilitations par défaut (certificat, contexte, profil de sécurité) sont nécessaires pour :

  • déployer la solution logicielle Vitam, notamment pour initialiser le référentiel des formats ;

  • lancer certains actes d’exploitation, tels que :

    • la configuration des identifiants des référentiels ;

    • des migrations, nécessitant des appels aux points d’API externes.

De fait, il est obligatoire de disposer d’un certificat client nommé « vitam-admin-int », créé à l’installation de la plate-forme[98]. Ce certificat peut correspondre à :

  • la PKI (certificat) de tests de la solution logicielle Vitam, si la plate-forme est installée à des fins de recette ;

  • une PKI (certificat) mise en place par l’exploitant et propre à son organisation, si la plate-forme a pour finalité un usage en production.

En raison de leur utilisation pour des actes d’exploitation, il n’est pas recommandé de :

  • modifier ces habilitations par défaut ;

  • supprimer ces habilitations par défaut.

6.3.2.2. Comment gérer une nouvelle application ?

Pour connecter une application à la solution logicielle Vitam, il est recommandé de suivre les étapes suivantes :

Qui ?

Quoi ?

Via l’IHM Vitam ?

Commentaires

Administrateur fonctionnel/ technique

- Définition des privilèges à octroyer à une application et à associer ultérieurement à un profil de sécurité,
- Définition des profils utilisateurs à mettre en place dans le Front Office et définition de leur mode de connexion (LDAP, certificat personnel, authentification gérée par le Front Office).

Non

Administrateur technique

Création d’un profil de sécurité

Non

Préalable à la création d’un contexte

Administrateur fonctionnel/ technique

Création d’un contexte :
- sans permission
- avec un profil de sécurité
- statut « Inactif »

Oui

Préalable à la création d’un certificat

Administrateur technique

Création d’un certificat applicatif

Non

Déclare le contexte précédemment créé

Administrateur technique

Création de certificat(s) personnel(s)

Non

Étape facultative.

Administrateur fonctionnel

Création et paramétrages des contrats d’entrée et/ou d’accès

Oui

Administrateur fonctionnel

Association des contrats d’entrée et/ou d’accès au contexte applicatif

Oui

Administrateur fonctionnel

Activation du contexte

Oui

À la date souhaitée pour commencer les interactions entre l’application versante et/ou accédante et la solution logicielle Vitam

Administrateur technique / fonctionnel

Test avant utilisation courante

Oui

6.4. Entrées

6.4.1. Mécanismes mis en œuvre par la solution logicielle Vitam

6.4.1.1. Processus d’entrée

Un SIP doit toujours déclarer un contrat d’entrée.

Dans le cadre du processus d’entrée d’un ensemble d’archives, suite à la réception d’un message ArchiveTransfer du SEDA, la solution logicielle Vitam effectue les tâches et traitements de contrôles internes suivants pour les archives déclarant un contrat d’entrée :

  • authentification de l’application versante à la solution logicielle Vitam par l’intermédiaire d’un certificat applicatif qui vérifie la validité de son contexte ;

  • vérification que le contrat d’entrée déclaré dans le SIP est conforme au contexte applicatif qui le déclare dans le référentiel des contextes applicatifs ;

  • vérification que le contrat déclaré dans le SIP (ArchivalAgreement) existe bien dans le référentiel des contrats d’entrée et est actif.

Point d’attention : un contrat d’entrée ne donne pas accès au registre des fonds et aux archives. Si le service externe doit verser des archives et y accéder, il doit nécessairement disposer d’un contrat d’entrée et d’un contrat d’accès.

6.4.1.2. Options de contrôle des métadonnées

La solution logicielle Vitam permet de contrôler, au moyen d’un profil d’archivage, la conformité des bordereaux de transfert qui lui sont adressés.

Points d’attention : pour que le contrôle soit effectif :

  • le profil d’archivage doit être associé au contrat d’entrée déclaré dans le bordereau de transfert ;

  • le profil d’archivage doit également être déclaré dans le bordereau de transfert.

Dans le cadre du processus d’entrée d’un ensemble d’archives, suite à la réception d’un bordereau de transfert (message ArchiveTransfer du SEDA) et après l’étape vérifiant que le contrat d’entrée déclaré dans le SIP (ArchivalAgreement) existe bien dans le référentiel des contrats d’entrée et est actif, la solution logicielle Vitam effectue les tâches et traitements internes suivants pour les archives déclarant ce contrat d’entrée disposant d’une option de contrôle de métadonnées :

  • vérification que le profil d’archivage déclaré dans le SIP (ArchivalProfile) est conforme au contrat d’entrée qui le déclare dans le référentiel des contrats d’entrée et est actif ;

  • vérification que le SIP est conforme à son profil d’archivage. Lors de l’étape de vérification de la conformité entre le profil d’archivage déclaré dans le bordereau de transfert et le contrat d’entrée :

  • Si le bordereau de transfert déclare un profil d’archivage et un contrat d’entrée qui référence ce même profil d’archivage, la tâche de vérification aura un statut « OK » et la solution logicielle Vitam passera à la tâche suivante de vérification de la conformité du bordereau au profil d’archivage ;

  • Si le bordereau de transfert déclare un profil d’archivage et un contrat d’entrée qui ne sont pas conformes pour les raisons suivantes :

    • le profil d’archivage n’est pas déclaré dans le contrat d’entrée,

    • il ne correspond pas au profil d’archivage déclaré dans le contrat d’entrée,

    • la notice descriptive du profil d’archivage est inactive, Alors le transfert du SIP échouera à la tâche de vérification entre le contrat d’entrée et le profil d’archivage et ne passera pas à la tâche suivante[99].

Exemple : message d’erreur sur la tâche de contrôle de conformité entre un contrat d’entrée et un profil d’archivage.

<Operation>
        <Event>
            <EventTypeCode>STP_INGEST_CONTROL_SIP</EventTypeCode>
            <EventType>Processus de contrôle du SIP</EventType>
            <EventDateTime>2018-05-25T13:19:27.570</EventDateTime>
            <Outcome>KO</Outcome>
            <OutcomeDetail>STP_INGEST_CONTROL_SIP.KO</OutcomeDetail>
            <OutcomeDetailMessage>Échec du processus du contrôle du bordereau du
                SIP</OutcomeDetailMessage>
        </Event>
        <Event>
            <EventTypeCode>CHECK_HEADER</EventTypeCode>
            <EventType>Vérification générale du bordereau de transfert</EventType>
            <EventDateTime>2018-05-25T13:19:27.570</EventDateTime>
            <Outcome>KO</Outcome>
            <OutcomeDetail>CHECK_HEADER.DIFF.KO</OutcomeDetail>
            <OutcomeDetailMessage>Échec de la vérification générale du bordereau de transfert :
                différence entre le profil déclaré dans le bordereau de transfert et celui déclaré
                dans le contrat Detail= OK:2 KO:1</OutcomeDetailMessage>
            <EventDetailData>{"evDetTechData":"The profile PR-000018 was not found in the ingest
                contract","ArchivalProfile":"PR-000018","EvDetailReq":"Catherine JABLASY :
                mails","ArchivalAgreement":"IC-000001"}</EventDetailData>
        </Event>
        <Event>
            <EventTypeCode>CHECK_HEADER.CHECK_IC_AP_RELATION</EventTypeCode>
            <EventType>Vérification de la relation entre le contrat d'entrée et le profil
                d'archivage</EventType>
            <EventDateTime>2018-05-25T13:19:27.572</EventDateTime>
            <Outcome>KO</Outcome>
            <OutcomeDetail>CHECK_HEADER.CHECK_IC_AP_RELATION.DIFF.KO</OutcomeDetail>
            <OutcomeDetailMessage>Échec du contrôle de cohérence entre le profil d'archivage déclaré
                dans le bordereau de transfert et celui déclaré dans le contrat d'entrée Detail=
                KO:1</OutcomeDetailMessage>
        </Event>
    </Operation>

Lors de l’étape de vérification de la conformité du bordereau de transfert à son profil d’archivage :

  • Si le bordereau de transfert est conforme à son profil d’archivage, c’est-à-dire s’il correspond au modèle de données défini dans le profil d’archivage, la tâche de vérification de la conformité au profil d’archivage aura un statut « OK » et la solution logicielle Vitam passera au traitement suivant, à savoir la vérification de la conformité du SIP au SEDA ;

  • Si le bordereau de transfert n’est pas conforme à son profil d’archivage, son transfert dans la solution logicielle Vitam n’aboutira pas. Un message de réponse (ArchiveTransferReply ou ATR) indique que le transfert a échoué à la tâche de vérification de la conformité au profil d’archivage et précise la première erreur rencontrée dans le détail de l’événement (EventDetailData).

Exemple : message d’erreur sur la tâche de contrôle de conformité entre un bordereau de transfert et un profil d’archivage.

<Operation>
        <Event>
            <EventTypeCode>STP_INGEST_CONTROL_SIP</EventTypeCode>
            <EventType>Processus de contrôle du SIP</EventType>
            <EventDateTime>2018-05-25T13:37:19.300</EventDateTime>
            <Outcome>KO</Outcome>
            <OutcomeDetail>STP_INGEST_CONTROL_SIP.KO</OutcomeDetail>
            <OutcomeDetailMessage>Échec du processus du contrôle du bordereau du
                SIP</OutcomeDetailMessage>
        </Event>
        <Event>
            <EventTypeCode>CHECK_HEADER</EventTypeCode>
            <EventType>Vérification générale du bordereau de transfert</EventType>
            <EventDateTime>2018-05-25T13:37:19.300</EventDateTime>
            <Outcome>KO</Outcome>
            <OutcomeDetail>CHECK_HEADER.KO</OutcomeDetail>
            <OutcomeDetailMessage>Échec de la vérification générale du bordereau de transfert
                Detail= OK:3 KO:1</OutcomeDetailMessage>
            <EventDetailData>{"evDetTechData":"character content of element \"Rule\" invalid; must
                be equal to \"APP-00001\"","ArchivalProfile":"PR-000018","EvDetailReq":"Catherine
                JABLASY : mails","ArchivalAgreement":"IC-000001"}</EventDetailData>
        </Event>
        <Event>
            <EventTypeCode>CHECK_HEADER.CHECK_ARCHIVEPROFILE</EventTypeCode>
            <EventType>Vérification de la conformité au profil d'archivage</EventType>
            <EventDateTime>2018-05-25T13:37:19.300</EventDateTime>
            <Outcome>KO</Outcome>
            <OutcomeDetail>CHECK_HEADER.CHECK_ARCHIVEPROFILE.KO</OutcomeDetail>
            <OutcomeDetailMessage>Échec de la vérification de la conformité au profil d'archivage
                Detail= KO:1</OutcomeDetailMessage>
        </Event>
    </Operation>

Point d’attention :
Le profil d’archivage ne sert pas à générer automatiquement le contenu d’un bordereau de transfert lors de son transfert dans la solution logicielle Vitam. Il n’est utilisé que pour effectuer des contrôles de conformité du bordereau par rapport à ses attentes. De facto, le bordereau de transfert, associé à un profil d’archivage, doit avoir été conçu, en amont du transfert, conformément aux attentes du profil d’archivage.

6.4.1.3. Options de rattachement

La solution logicielle Vitam permet :

  • de rattacher systématiquement des SIP à un arbre de positionnement, un plan de classement ou une unité archivistique issue d’un bordereau de transfert (dite « standard ») préalablement versés dans la solution logicielle Vitam, en déclarant, dans un contrat d’entrée, l’identifiant système (le GUID) de l’unité archivistique auquel le SIP doit être rattaché. Si cette option est activée, l’/les unité(s) archivistique(s) racine(s) du SIP seront disposées sous cette unité archivistique ;

  • de contrôler les nœuds de rattachement contenus dans les bordereaux de transfert, en déclarant un/des identifiant(s) système (le GUID) de l’/des unité(s) archivistique(s) racine(s) déterminant un périmètre autorisé pour les rattachements. Si un ou plusieurs nœuds sont déclarés, un bordereau de transfert ne pourra pas déclarer un nœud de rattachement positionné à un niveau supérieur de l’arborescence par rapport à celui(ceux) qui est(sont) déclaré(s) dans son contrat ou à un tout autre niveau sans lien avec ce(s) dernier(s). La solution logicielle Vitam empêchera alors l’import.

  • d’autoriser ou non les rattachements par bordereau de transfert d’unités archivistiques à des unités archivistiques déjà présentes dans la solution logicielle Vitam :

    • si l’option « AUTHORIZED » est retenue, , le bordereau de transfert peut contenir des unités archivistiques déclarant un rattachement, sans que cela soit un prérequis obligatoire pour pouvoir être transféré avec succès dans la solution logicielle Vitam ;

    • si l’option « REQUIRED » est retenue, le bordereau de transfert doit obligatoirement contenir au moins une unité archivistique déclarant un rattachement pour pouvoir être transféré avec succès dans la solution logicielle Vitam ;

    • si l’option « UNAUTHORIZED » est retenue, le bordereau de transfert ne doit pas contenir d’unités archivistiques déclarant un rattachement pour pouvoir être transféré avec succès dans la solution logicielle Vitam.

En fonction de ces trois filtres, un versement de SIP sera autorisé ou non :

Contrat d’entrée

Bordereau de transfert sans nœud de rattachement

Bordereau de transfert avec au moins un nœud de rattachement

Déclaration d’un nœud de rattachement

Présence d’au moins un rattachement dans le bordereau de transfert

Déclaration d’un ou plusieurs cônes de positionnement des rattachements

Dans l’unité archivistique racine

Dans l’unité archivistique non racine

Dans l’unité archivistique racine

Dans l’unité archivistique non racine

CAS 1

présent

AUTHORIZED

/

Entrée en succès
Rattachement au nœud présent dans le contrat

Entrée en succès
Pas de rattachement

Entrée en succès
Rattachement au nœud présent dans le contrat et, le cas échéant, au nœud du bordereau.

Entrée en succès
Rattachement, le cas échéant, au nœud du bordereau.

CAS 2

présent

AUTHORIZED

présent(s)

Entrée en succès
Rattachement au nœud présent dans le contrat

Entrée en succès
Pas de rattachement

Entrée en succès, seulement si la position du nœud est conforme au(x) cône(s) du contrat
Rattachement au nœud présent dans le contrat et, le cas échéant, au nœud du bordereau.

Entrée en succès, seulement si la position du nœud est conforme au(x) cône(s) du contrat
Rattachement, le cas échéant, au nœud du bordereau.

CAS 3

présent

REQUIRED

/

Entrée en échec

Entrée en échec

Entrée en succès
Rattachement au nœud présent dans le contrat et, le cas échéant, au nœud du bordereau.

Entrée en succès
Rattachement, le cas échéant, au nœud du bordereau.

CAS 4

présent

REQUIRED

présent(s)

Entrée en échec

Entrée en échec

Entrée en succès, seulement si la position du nœud est conforme au(x) cône(s) du contrat
Rattachement au nœud présent dans le contrat et, le cas échéant, au nœud du bordereau.

Entrée en succès, seulement si la position du nœud est conforme au(x) cône(s) du contrat
Rattachement, le cas échéant, au nœud du bordereau.

CAS 5

présent

UNAUTHORIZED

/

Entrée en succès
Rattachement au nœud présent dans le contrat

Entrée en succès
Pas de rattachement

Entrée en échec

Entrée en échec

CAS 6

présent

UNAUTHORIZED

présent(s)

Cas impossible : dans un contrat, il n’est pas possible de déclarer conjointement « UNAUTHORIZED » et un cône de positionnement.

Cas impossible : dans un contrat, il n’est pas possible de déclarer conjointement « UNAUTHORIZED » et un cône de positionnement.

Cas impossible : dans un contrat, il n’est pas possible de déclarer conjointement « UNAUTHORIZED » et un cône de positionnement.

Cas impossible : dans un contrat, il n’est pas possible de déclarer conjointement « UNAUTHORIZED » et un cône de positionnement.

CAS 7

/

AUTHORIZED

/

Entrée en succès
Pas de rattachement

Entrée en succès
Pas de rattachement

Entrée en succès
Rattachement, le cas échéant, au nœud du bordereau.

Entrée en succès
Rattachement, le cas échéant, au nœud du bordereau.

CAS 8

/

AUTHORIZED

présent(s)

Entrée en succès
Pas de rattachement

Entrée en succès
Pas de rattachement

Entrée en succès, seulement si la position du nœud est conforme au(x) cône(s) du contrat
Rattachement, le cas échéant, au nœud du bordereau.

Entrée en succès, seulement si la position du nœud est conforme au(x) cône(s) du contrat
Rattachement, le cas échéant, au nœud du bordereau.

CAS 9

/

REQUIRED

/

Entrée en échec

Entrée en échec

Entrée en succès
Rattachement, le cas échéant, au nœud du bordereau.

Entrée en succès
Rattachement, le cas échéant, au nœud du bordereau.

CAS 10

/

REQUIRED

présent(s)

Entrée en échec

Entrée en échec

Entrée en succès, seulement si la position du nœud est conforme au(x) cône(s) du contrat
Rattachement, le cas échéant, au nœud du bordereau.

Entrée en succès, seulement si la position du nœud est conforme au(x) cône(s) du contrat
Rattachement, le cas échéant, au nœud du bordereau.

CAS 11

/

UNAUTHORIZED

/

Entrée en succès
Pas de rattachement

Entrée en succès
Pas de rattachement

Entrée en échec

Entrée en échec

CAS 12

/

UNAUTHORIZED

présent(s)

Cas impossible : dans un contrat, il n’est pas possible de déclarer conjointement « UNAUTHORIZED » et un cône de positionnement.

Cas impossible : dans un contrat, il n’est pas possible de déclarer conjointement « UNAUTHORIZED » et un cône de positionnement.

Cas impossible : dans un contrat, il n’est pas possible de déclarer conjointement « UNAUTHORIZED » et un cône de positionnement.

Cas impossible :dans un contrat, il n’est pas possible de déclarer conjointement « UNAUTHORIZED » et un cône de positionnement.

6.4.1.4. Options sur les groupes d’objets techniques

Le contrat d’entrée permet également d’effectuer des contrôles sur les groupes d’objets techniques transférés dans la solution logicielle Vitam au moyen de trois fonctionnalités :

  • Une première option permet d’autoriser ou non le transfert de groupes d’objets techniques ne contenant pas d’objets de type « Master » :

    • Si sa valeur est égale à « true », le bordereau de transfert devra nécessairement contenir des objets binaires de type « Master », qu’ils soient binaires (« BinaryMaster ») ou physiques (« PhysicalMaster ») ;

    • Si sa valeur est égale à « false », le bordereau de transfert sera autorisé à contenir des groupes d’objets techniques sans objet binaire de type « Master » ;

    • Si le contrat d’entrée, lors de son initialisation, ne détermine pas l’option retenue, la solution logicielle Vitam appliquera par défaut une valeur égale à « true » et imposera la présence d’objets binaires de type « Master » dans les bordereaux de transfert.

  • Une deuxième option permet de déterminer quel(s) type(s) ou usage(s) d’objets sont attendus dans les bordereaux de transfert, dans le cas où l’on souhaite rattacher un objet binaire à un groupe d’objets techniques déjà conservé dans la solution logicielle Vitam :

    • Si le contrat d’entrée permet le transfert de n’importe quel type d’usage, le bordereau de transfert pourra contenir n’importe quel type d’usage ;

    • Si le contrat d’entrée précise quel(s) usage(s) il autorise à rajouter dans un groupe d’objets techniques déjà conservé dans la solution logicielle Vitam, le bordereau de transfert devra nécessairement contenir le(s) seul(s) usage(s) déclaré(s) dans le contrat d’entrée, sans quoi le transfert échouera ;

    • Si le contrat d’entrée, lors de son initialisation, ne détermine pas l’option retenue, la solution logicielle Vitam n’acceptera aucun usage en entrée et, de fait, aucun bordereau de transfert contenant des fichiers numériques destinés à compléter des groupes d’objets techniques déjà conservés.

  • Une troisième option permet de déterminer quel(s) format(s) d’objets binaires sont attendus dans les bordereaux de transfert :

    • Si le contrat d’entrée permet le transfert de n’importe quel format, le bordereau de transfert pourra contenir des objets binaires de n’importe quel format possible ;

    • Si le contrat d’entrée précise quel(s) format(s) il autorise, le bordereau de transfert devra nécessairement contenir des objets binaires conformes au(x) seul(s) format(s) déclaré(s) dans le contrat d’entrée, sans quoi le transfert échouera ;

    • Si le contrat d’entrée, lors de son initialisation, ne détermine pas l’option retenue, la solution logicielle Vitam acceptera n’importe quel format en entrée.

Il est également possible d’autoriser le transfert d’objets binaires dont le format n’est pas identifié au moyen d’un paramétrage :

  • Si sa valeur est égale à « true », il sera possible de transférer des objets binaires non identifiés dans la solution logicielle Vitam malgré cette absence d’identification ;

  • Si sa valeur est égale à « false » (valeur par défaut), il ne sera possible de transférer dans la solution logicielle Vitam que des objets binaires dont le format est identifié.

6.4.1.5. Options de stockage

Le contrat d’entrée permet de spécifier un stockage particulier pour des archives au moyen de la définition d’un contrat de gestion.

Ce stockage particulier est, de fait, paramétré dans un contrat de gestion qui permet de déclarer une stratégie de stockage particulière pour :

  • les métadonnées des unités archivistiques,

  • les métadonnées des groupes d’objets techniques,

  • les objets binaires (fichiers numériques).

Points d’attention :

  • Pour pouvoir associer un contrat de gestion à un contrat d’entrée, il va de soi que le contrat de gestion doit exister dans le système.

  • Pour pouvoir être utilisé, un contrat de gestion doit définir une stratégie de stockage pour les métadonnées des unités archivistiques, les métadonnées des groupes d’objets techniques et/ou des objets binaires (fichiers numériques). Afin de ne pas rompre la cohérence du stockage des données, il est recommandé de déclarer une stratégie identique pour le stockage des unités archivistiques et des groupes d’objets techniques.

  • Les stratégies définies dans un contrat de gestion doivent avoir été préalablement configurées dans la solution logicielle Vitam.

Dans le cadre du processus d’entrée d’un ensemble d’archives, suite à la réception d’un bordereau de transfert (message ArchiveTransfer du SEDA), à l’étape vérifiant que le contrat d’entrée déclaré dans le SIP (ArchivalAgreement) existe bien dans le référentiel des contrats d’entrée et est actif, la solution logicielle Vitam effectue également les tâches et traitements suivants pour les archives déclarant ce contrat d’entrée déclarant un contrat de gestion :

  • vérification que le contrat de gestion est actif ;

  • vérification que la stratégie de stockage définie dans le contrat de gestion existe. Lors de cette étape :

  • Si le contrat de gestion est actif et si la stratégie qu’il déclare existe, la solution logicielle Vitam passera à la tâche ou traitement suivant, puis à l’étape suivante ;

  • Si le contrat de gestion est inactif ou si la stratégie de stockage qu’il déclare n’existe pas, alors le transfert du SIP échouera à la tâche de vérification de la présence et du contrôle du contrat d’entrée. Exemple : message d’erreur sur la tâche de contrôle du contrat d’entrée.

    <Operation>
        <Event>
            <EventTypeCode>STP_INGEST_CONTROL_SIP</EventTypeCode>
            <EventType>Processus de contrôle du SIP</EventType>
            <EventDateTime>2019-10-15T15:08:24.999</EventDateTime>
            <Outcome>KO</Outcome>
            <OutcomeDetail>STP_INGEST_CONTROL_SIP.KO</OutcomeDetail>
            <OutcomeDetailMessage>Échec du processus du contrôle du bordereau du
                SIP</OutcomeDetailMessage>
        </Event>
        <Event>
            <EventTypeCode>CHECK_HEADER</EventTypeCode>
            <EventType>Vérification générale du bordereau de transfert</EventType>
            <EventDateTime>2019-10-15T15:08:24.999</EventDateTime>
            <Outcome>KO</Outcome>
            <OutcomeDetail>CHECK_HEADER.MANAGEMENT_CONTRACT_INACTIVE.KO</OutcomeDetail>
            <OutcomeDetailMessage>!CHECK_HEADER.MANAGEMENT_CONTRACT_INACTIVE.KO! Detail= OK:1
                KO:1</OutcomeDetailMessage>
            <EventDetailData>{"ArchivalAgreement":"IC-000001","evDetTechData":"Management Contract
                inactive","EvDetailReq":"2 images de lac"}</EventDetailData>
        </Event>
        <Event>
            <EventTypeCode>CHECK_HEADER.CHECK_CONTRACT_INGEST</EventTypeCode>
            <EventType>Vérification de la présence et du contrôle du contrat d'entrée</EventType>
            <EventDateTime>2019-10-15T15:08:25</EventDateTime>
            <Outcome>KO</Outcome>
            <OutcomeDetail>CHECK_HEADER.CHECK_CONTRACT_INGEST.MANAGEMENT_CONTRACT_INACTIVE.KO</OutcomeDetail>
            <OutcomeDetailMessage>!CHECK_HEADER.CHECK_CONTRACT_INGEST.MANAGEMENT_CONTRACT_INACTIVE.KO!
                Detail= KO:1</OutcomeDetailMessage>
        </Event>
    </Operation>

Point d’attention : Au terme de la version 5.RC, les paramètres liés à la définition d’une politique de préservation ne sont qu’informatifs. De facto, aucun contrôle n’est réalisé en entrée par rapport à cette politique.

6.4.1.6. Options de génération automatique d’identifiants pérennes

Le contrat d’entrée permet de générer un identifiant pérenne pour des unités archivistiques et/ou des objets techniques au moyen de la définition d’un contrat de gestion.

Cette option est, de fait, paramétrée dans un contrat de gestion qui permet de déclarer une stratégie d’identification pérenne en définissant :

  • un type d’identification pérenne,

  • une autorité nommante,

  • la cible de l’identification pérenne (unité archivistique et/ou objet technique).

Points d’attention :

  • Pour pouvoir associer un contrat de gestion à un contrat d’entrée, il va de soi que le contrat de gestion doit exister dans le système.

  • Pour pouvoir être utilisé, un contrat de gestion doit définir une stratégie d’identification pérenne.

  • Au terme de la version 8.0, la solution logicielle Vitam permet uniquement de définir une stratégie d’identification pérenne de type ARK.

Dans le cadre du processus d’entrée d’un ensemble d’archives, suite à la réception d’un bordereau de transfert (message ArchiveTransfer du SEDA), à l’étape vérifiant que le contrat d’entrée déclaré dans le SIP (ArchivalAgreement) existe bien dans le référentiel des contrats d’entrée et est actif, la solution logicielle Vitam effectue également les tâches et traitements suivants pour les archives déclarant ce contrat d’entrée déclarant un contrat de gestion :

  • vérification que le contrat de gestion est actif ;

  • vérification que la stratégie de stockage définie dans le contrat de gestion existe. Lors de cette étape :

  • Si le contrat de gestion est actif et si la stratégie qu’il déclare existe, la solution logicielle Vitam passera à la tâche ou traitement suivant, puis à l’étape suivante ;

  • Si le contrat de gestion est inactif ou si la stratégie de stockage qu’il déclare n’existe pas, alors le transfert du SIP échouera à la tâche de vérification de la présence et du contrôle du contrat d’entrée.

  • Si le contrat de gestion déclare une stratégie d’identification pérenne, la solution logicielle Vitam enregistrera automatiquement un identifiant pérenne dans les unités archivistiques et/ou les objets techniques en base de données.

  • Si le contrat de gestion ne déclare pas de stratégie d’identification pérenne, la solution logicielle Vitam n’enregistrera pas d’identifiant pérenne dans les unités archivistiques et/ou les objets techniques en base de données.

Point d’attention :

  • L’enregistrement en base de données s’effectuera en fonction des paramètres définis dans le contrat de gestion et les éléments disponibles dans le SIP :

    • Si la stratégie est de générer des identifiants sur les unités archivistiques, alors toutes les unités archivistiques associées à un groupe d’objets techniques seront dotées d’un identifiant pérenne,

    • Si la stratégie est de générer des identifiants sur les objets, alors les objets ciblés dans un groupe d’objets techniques (pour un usage, aucune version, la première version, toutes les versions et/ou la dernière) seront dotés d’un identifiant pérenne,

    • Si la stratégie est de générer des identifiants sur les objets et si le SIP ne contient pas d’objet technique, alors aucun identifiant pérenne ne sera généré ;

  • La solution logicielle Vitam ne contrôle pas la présence d’identifiants pérennes dans les SIP versés. De facto, si un SIP contient des identifiants pérennes et si le contrat d’entrée dispose d’une stratégie d’identification pérenne, alors les archives ciblées disposeront de deux identifiants pérennes.

6.4.1.7. Option de génération automatique des règles de gestion héritées

Il est également possible d’enregistrer automatiquement les règles de gestion héritées par une unité archivistique en base de données, dans un champ spécifique, au moyen d’un paramétrage :

  • Si sa valeur est égale à « true », la solution logicielle Vitam enregistrera automatiquement les règles de gestion héritées par une unité archivistique en base de données ;

  • Si sa valeur est égale à « false » (valeur par défaut), la solution logicielle Vitam n’enregistrera pas automatiquement les règles de gestion héritées par une unité archivistique en base de données.

Point d’attention : si la valeur est égale à « true », la solution logicielle Vitam enregistre dans un champ spécifique les règles de gestion héritées par une unité archivistique seulement si des règles de gestion ont été positionnées dans des niveaux de description supérieurs à cette unité archivistique. Si cette dernière n’hérite pas de règles de gestion et si elle n’en déclare pas, elle ne disposera d’aucune règle de gestion permettant de gérer son cycle de vie dans la solution logicielle Vitam.

6.4.2. Conseils de mise en œuvre

Intitulé

Description

Niveau de recommandation

Application versante disposant d’un unique profil d’archivage

Cette application nécessite un unique contrat d’entrée, dans lequel on définira le profil d’archivage la concernant.

Recommandé

Application versante disposant de plusieurs profils d’archivage

Une application versante peut générer des données nécessitant plus d’un profil d’archivage.
- Ces profils peuvent être déclarés dans un même contrat d’entrée. Il reviendra au SIP de signaler le profil correspondant aux données qu’il contient.
- Il est également possible de créer un contrat d’entrée par profil utilisé.
Il est recommandé de créer un contrat d’entrée par profil. En effet, un contrat unique ne permettrait pas a posteriori, s’il déclare plusieurs profils, de déclarer pour chacun d’eux un nœud de rattachement particulier.

Recommandé

Application devant verser ses archives à un niveau particulier d’arbre de positionnement, de plan de classement ou d’unité archivistique standard

Un contrat d’entrée suffit pour déclarer un nœud unique de rattachement.

Recommandé

Application devant verser ses archives dans plusieurs niveaux d’arbre de positionnement, de plan de classement ou d’unités archivistiques standards

Il est recommandé de créer autant de contrats d’entrée qu’il y aura de nœuds de rattachement où transférer les SIP. Le contrat d’entrée déclaré dans chaque SIP orientera ce dernier vers son nœud de rattachement.
Si on souhaite ne pas multiplier les contrats d’entrée pour cette seule raison, il est recommandé de gérer les rattachements au niveau des unités archivistiques de chaque bordereau de transfert.

Recommandé

Application versante disposant de plusieurs profils d’archivage et devant verser ses archives à un niveau particulier d’un arbre de positionnement, d’un plan de classement ou d’une unité archivistique standard

Il est recommandé d’utiliser un contrat d’entrée unique, contenant à la fois les profils d’archivage et le nœud de rattachement.

Recommandé

Application versante disposant de plusieurs profils d’archivage et devant verser ses archives dans plusieurs niveaux d’arbre de positionnement, de plan de classement ou d’unités archivistiques standards

Il est recommandé de créer autant de contrats d’entrée que de profils d’archivage. Chaque contrat d’entrée fera référence aux profils d’archivage et au nœud de rattachement.

Recommandé

Application versant des originaux numériques

Pour une application devant transférer uniquement des originaux numériques, il est recommandé de contrôler au moyen du contrat d’entrée que les groupes d’objets techniques qu’elle transfère contiennent obligatoirement un objet binaire de type « Master » (« BinaryMaster »)

Recommandé

Application versant des objets binaires d’un même usage à ajouter à des groupes d’objets techniques déjà présents dans le système

Il est recommandé d’indiquer dans le contrat d’entrée quel est l’usage des objets binaires à ajouter à des groupes d’objets techniques déjà existant dans le système, si ces usages sont connus.
Par exemple, un Portail Archives qui diffuse des copies numériques de diffusion pourrait ne devoir verser que des objets de type « Dissemination » pour compléter les groupes d’objets techniques contenant les originaux.

Recommandé

Application versant des objets binaires de différents usages à ajouter à des groupes d’objets techniques déjà présents dans le système

Quand on ne connaît pas les usages des objets binaires qui pourraient être transférés dans la solution logicielle pour compléter les groupes d’objets techniques déjà présents dans le système ou quand on ne souhaite pas imposer un contrôle sur les usages des objets à transférer, il est recommandé d’autoriser le transfert d’objets de tous les types d’usage.

Recommandé

Application versant des objets binaires au(x) format(s) connu(s)

Il est recommandé d’indiquer dans le contrat d’entrée quel(s) est(sont) le(s) format(s) des archives à transférer par une application versante, si ce(s) format(s) sont connus ou si l’on souhaite imposer une liste de formats propre à l’archivage.
Par exemple :
- un Portail Archives qui diffuse des copies numériques de diffusion pourrait ne devoir verser que des objets binaires au format JPEG ;
- un système d’archivage électronique ne souhaitant garantir la conservation d’objets binaires qu’aux formats ODT, ODS, ODP, PDF, TIFF pourrait ne déclarer que des contrats d’entrée n’acceptant que ces seuls formats.

Recommandé

Application versant des objets binaires aux formats différents et non connus à l’avance

Quand on ne connaît pas les formats des archives qui pourraient être transférées dans la solution logicielle ou quand on ne souhaite pas imposer des formats pour les archives à transférer et quand on souhaite, néanmoins, que ces formats soient identifiés par la solution logicielle Vitam lors du transfert des archives, il est recommandé d’autoriser le transfert de groupes d’objets techniques contenant tous les formats possibles.

Recommandé

Application versant des objets binaires aux formats différents et non connus à l’avance

Quand on ne connaît pas les formats des archives qui pourraient être transférées dans la solution logicielle ou quand on ne souhaite pas imposer des formats pour les archives à transférer et quand on souhaite n’effectuer aucun contrôle d’identification de format sur elles au moment de leur transfert dans la solution logicielle Vitam, il est recommandé d’autoriser le transfert de groupes d’objets techniques contenant tous les formats possibles et de désactiver le contrôle d’identification des objets binaires.

Recommandé

Application versante devant filtrer les accès sur ses archives en fonction de leurs règles de gestion après transfert

Il est recommandé d’activer l’enregistrement automatique des règles de gestion héritées lorsque l’application versante a vocation à donner accès aux archives en fonction de leurs règles de gestion, héritées ou non. Il peut s’agir par exemple d’un système d’archivage électronique ou d’un Portail Archives.
L’activation de cette fonctionnalité en entrée du système permet d’anticiper et d’activer dès l’entrée les accès autorisés ou non en fonction des règles de gestion, et, de fait, de ne pas avoir à rechercher a posteriori les archives qui ne portent aucune règle de gestion.

Recommandé

Application versante ne devant pas accéder à ses archives après transfert

Une application versante peut avoir vocation à uniquement transférer ses archives dans la solution logicielle Vitam, mais n’y accédera pas. Il est alors possible de définir dans son contrat d’entrée un contrat de gestion particulier, configurant une stratégie de stockage particulière pour ces archives, par exemple sur offre froide ou sur une offre tiède (disponible non automatiquement).
Point d’attention : si un autre applicatif, par exemple un système d’archivage électronique, a besoin d’accéder à ces archives, notamment aux objets binaires (fichiers numériques), il est nécessaire de proposer une offre de stockage disponible.

Possible

Application versante pouvant accéder à ses métadonnées, mais pas à ses fichiers numériques après transfert

Une application versante peut avoir vocation à transférer ses archives dans la solution logicielle Vitam, mais à n’accéder qu’à ses métadonnées. Il est alors possible de définir dans son contrat d’entrée un contrat de gestion particulier, configurant une stratégie de stockage particulière pour ces archives, lui permettant d’accéder aux métadonnées, mais pas aux objets binaires transférés (fichiers numériques).
Point d’attention : si un autre applicatif, par exemple un système d’archivage électronique, a besoin d’accéder à ces objets binaires, il est nécessaire de proposer une offre de stockage disponible.

Possible

6.5. Accès

6.5.1. Mécanismes mis en œuvre par la solution logicielle Vitam

6.5.1.1. Description

Les contrats d’accès permettent à un service externe authentifié d’accéder aux collections suivantes :

  • unités archivistiques (collection Unit),

  • groupes d’objets techniques (collection ObjectGroup),

  • registre des fonds (collection AccessionRegisterSummary et AccessionRegisterDetail).

Un contrat d’accès filtre les réponses envoyées au service externe en fonction de ce qui a été autorisé dans le contrat.

Par ailleurs, d’autres services de la solution logicielle Vitam faisant appel à la recherche par les unités archivistiques et/ou les groupes d’objets techniques (module « AccessInternal ») pour leur appliquer des traitements sont, par défaut, soumis aux paramétrages du contrat d’accès en activité lors de leur utilisation. Il s’agit des services suivants :

  • audits d’existence, d’intégrité, de cohérence et correctif,

  • relevé de valeur probante,

  • réorganisation des arborescences,

  • préservation,

  • élimination d’archives,

  • consultation des journaux du cycle de vie des unités archivistiques et des groupes d’objets techniques.

Point d’attention : un contrat d’accès ne permet pas de réaliser des transferts d’archives. Si le service externe doit verser des archives et y accéder, il doit nécessairement disposer d’un contrat d’entrée et d’un contrat d’accès.

6.5.1.2. Filtre sur les services producteurs

Un contrat d’accès peut limiter la consultation dans le registre des fonds et les archives au(x) seul(s) producteur(s) qu’il déclare. Ainsi, un service externe ne pourra accéder qu’au(x) fonds et archives du ou des service(s) producteur(s) inscrit(s) dans son contrat d’accès.

Ce filtre permet les usages suivants :

  • Si le contrat d’accès autorise un accès à tous les services producteurs, l’application accédante pourra consulter l’ensemble des unités archivistiques, des groupes d’objets techniques et du registre des fonds, présents dans la solution logicielle Vitam ;

  • Si le contrat d’accès autorise un accès à un à plusieurs services producteurs, l’application accédante pourra consulter uniquement les unités archivistiques, les groupes d’objets techniques et le registre des fonds correspondant à ce(s) service(s) producteur(s) ;

  • Si le contrat d’accès autorise un accès à aucun service producteur, l’application accédante ne pourra consulter aucune unité archivistique, aucun groupe d’objets techniques et aucun registre des fonds.

Points d’attention :

  • Ne peuvent être signalés dans un contrat d’accès que des services producteurs figurant dans le référentiel des services agents.

  • Il est obligatoire d’indiquer dans un contrat d’accès actif si le service externe, une fois authentifié par la solution logicielle Vitam, a accès à tous les services producteurs ou au moins à l’un d’entre eux. Si aucun élément n’a été renseigné, même si le contrat d’accès est actif, le service externe ne pourra accéder à aucune archives conservée dans la solution logicielle Vitam.

6.5.1.3. Filtre sur les usages autorisés

Le contrat d’accès permet de limiter l’accès à certains usages : archives physiques (PhysicalMaster), archives numériques originales (BinaryMaster), copies de diffusion (Dissemination), contenu textuel (TextContent), vignettes (Thumbnail).

Ce filtre permet les usages suivants :

  • Si le contrat d’accès autorise un accès à tous les usages, l’application accédante pourra consulter l’ensemble des objets binaires, présents dans la solution logicielle Vitam, quel que soit leur usage ;

  • Si le contrat d’accès autorise un accès à un à plusieurs usages, l’application accédante pourra consulter uniquement les objets binaires dont l’usage correspond à celui qui est autorisé dans le contrat d’accès ;

  • Si le contrat d’accès autorise un accès à aucun usage, l’application accédante ne pourra consulter aucun objet binaire.

Points d’attention :

  • Ne peuvent être signalés dans un contrat d’accès que les usages figurant dans le SEDA.

  • Il est obligatoire d’indiquer dans un contrat d’accès actif si le service externe, une fois authentifié par la solution logicielle Vitam, a accès :

    • à tous les services producteurs ou au moins à l’un d’entre eux,

    • à tous les usages ou à au moins l’un d’entre eux. Si aucun élément n’a été renseigné, même si le contrat d’accès est actif, le service externe ne pourra accéder à aucun objet binaire conservé dans la solution logicielle Vitam.

6.5.1.4. Filtres sur les niveaux de description accessibles

Le contrat d’accès peut déterminer :

  • le(s) nœud(s) ou niveau(x) de l’arborescence à partir du(es)quel(s) un service externe pourra effectuer des recherches ou obtenir des résultats ;

  • le(s) nœud(s) ou niveau(x) de l’arborescence à partir du(es)quel(s) un service externe n’aura pas accès.

Dans les deux cas, il peut s’agir de tout ou partie d’un arbre de positionnement, d’un plan de classement ou d’unités archivistiques issues d’un bordereau de transfert (dites « standard »).

6.5.1.5. Filtre sur les catégories de règle de gestion

Un contrat de gestion peut imposer des filtres à appliquer sur les unités archivistiques dont une règle de gestion n’est pas échue. Ce filtre peut s’appliquer sur une à plusieurs catégorie(s) de règle de gestion.

Ce filtre permet les usages suivants :

  • Si le contrat d’accès n’applique aucun filtre sur des catégories de règle de gestion (fonctionnement par défaut), que ce filtre soit absent du contrat ou ne contienne aucune information, l’application accédante pourra consulter l’ensemble des unités archivistiques et des groupes d’objets techniques, présents dans la solution logicielle Vitam, quelles que soient les échéances des règles de gestion qui leur sont associées ;

  • Si le contrat d’accès applique un filtre sur une à plusieurs catégorie(s) de règle de gestion, l’application accédante pourra consulter uniquement les unités archivistiques et les groupes d’objets techniques dont la(les) règle(s) de gestion, correspondant à la(aux) catégorie(s) indiquée(s) dans le contrat d’accès, est(sont) arrivée(s) à échéance. S’il est activé pour une à plusieurs catégorie(s) de règle de gestion, la solution logicielle Vitam retourne les unités archivistiques dont la date de fin correspondant à la(aux) catégorie(s) sélectionnée(s) est antérieure ou égale à la date de la requête, que ces unités archivistiques héritent de cette(ces) règle(s) ou la(les) définissent.

Point d’attention : le filtre ne s’applique que si les unités archivistiques ont fait l’objet d’un enregistrement automatique de règle(s) de gestion dont elles héritent, car il s’effectue au moyen des informations enregistrées au moyen de cet enregistrement. De fait, il est recommandé d’effectuer un enregistrement automatique en base de données des règles de gestion héritées dès l’entrée des unités archivistiques dans la solution logicielle Vitam, sans quoi le filtre ne fonctionnera pas.

6.5.1.6. Droits sur les archives accessibles

Un contrat d’accès peut octroyer des droits d’écriture et de modification sur :

  • les unités archivistiques (collection Unit),

  • les groupes d’objets techniques (collection ObjectGroup).

Il peut également attribuer des droits de modification sur les métadonnées associées aux unités archivistiques (collection Unit) au moyen d’une restriction des droits d’écriture :

  • Si sa valeur est égale à « true », le détenteur du contrat peut effectuer des mises à jour seulement sur les métadonnées descriptives ;

  • Si sa valeur est égale à « false » (valeur par défaut), le détenteur du contrat peut effectuer des mises à jour sur les métadonnées descriptives, ainsi que sur les métadonnées de gestion et de contrôle de métadonnées (mise à jour du profil d’unité archivistique). Point d’attention : la solution logicielle Vitam ne fait aucun contrôle de cohérence entre l’octroi d’un droit d’écriture et le paramétrage des droits de mise à jour sur les métadonnées associées aux unités archivistiques. En d’autres termes, il est possible qu’un contrat d’accès déclare à la fois un droit de lecture seule et un droit de révision de l’ensemble des métadonnées d’une unité archivistique. Le premier droit l’emporte sur le second.

6.5.1.7. Activation du log des accès

Une option permet enfin d’activer la génération d’un enregistrement ou log des accès sur les objets binaires conservés dans la solution logicielle Vitam :

  • Si sa valeur est égale à « ACTIVE », tout téléchargement des objets binaires ou toute intégration d’un objet binaire dans un DIP sera enregistré dans un fichier d’enregistrement ou de log des accès ;

  • Si sa valeur est égale à « INACTIVE » (valeur par défaut), aucun enregistrement ou log des accès ne sera généré lors de téléchargement d’objets binaires ou de l’intégration d’un objet binaire dans un DIP[100].

6.5.2. Conseils de mise en œuvre

Intitulé

Description

Niveau de recommandation

Application devant filtrer les accès en fonction de profils utilisateurs

L’utilisation d’un contrat d’accès unique peut ne pas être suffisante pour filtrer les accès. En effet, pour un SIA, on peut vouloir n’octroyer des accès limités qu’à certains types d’archives : des archives de certains domaines fonctionnels par exemple.
Option 1 : Il reviendra à l’application accédante d’ajouter des filtres d’accès supplémentaires afin de réduire le périmètre des archives consultables.
Option 2 : L’autre solution est d’attribuer plusieurs contrats d’accès à l’application.

Recommandé

Application devant accéder à certaines versions des objets archivés

Il est recommandé de créer un seul contrat d’accès comportant les droits d’accès suivants :
- une partie des usages seulement
- tout ou partie des services producteurs.
L’avantage est de ne pas multiplier les contrats d’accès dans son référentiel. Par exemple :
- un Portail Archives détenteur d’un contrat d’accès pourra accéder aux seuls objets binaires de certains producteurs dont l’usage est la diffusion.

Recommandé

Application devant accéder à une liste déterminée de services producteurs

Deux options sont possibles :
- créer un contrat unique,
- créer autant de contrats que de services producteurs.
Option 1 : On peut choisir de ne créer qu’un contrat d’accès par application portant les droits suivants :
- certains services producteurs,
- tout usage,
- le cas échéant, des droits d’écriture.
Par exemple :
- Un SIRH détenteur d’un contrat d’accès pourra accéder aux archives dont le service producteur est la Direction des ressources humaines.
Option 2 : Une application accédante peut disposer de plusieurs contrats d’accès, qui lui servent alors de filtre pour accéder à différents types d’archives. Ainsi, un SIA ou une GED transverse pourront détenir plusieurs contrats qui leur permettront de cibler, dans chacun de ces contrats, les services producteurs ou les types d’objets binaires accessibles.
Dans ce choix d’implémentation, les contrats d’accès servent d’éléments filtrants.
Points d’attention :
- L’utilisation d’un contrat d’accès unique peut ne pas être suffisante pour filtrer les accès. En effet, pour un SIRH, on peut vouloir n’octroyer des accès limités qu’à certains types d’archives : des archives produites par le SIRH qui peuvent n’être qu’une partie des archives versées par la Direction des ressources humaines. Il sera alors nécessaire d’ajouter des filtres d’accès supplémentaires (ex : accès à un ou plusieurs nœuds) afin de réduire le périmètre des archives consultables Si cette solution ne suffit pas, il est recommandé d’attribuer plusieurs contrats d’accès à l’application.
- Le choix de la granularité du service producteur est un élément déterminant. Si on reprend l’exemple du SIRH, plutôt que de lui donner accès à l’ensemble des archives de la Direction, il peut être judicieux de lui octroyer des droits sur les archives d’un service particulier tel que le Service de Gestion des Carrières. Cela est possible si les archives versées l’ont été par service et non pas par direction.

Recommandé

Application devant accéder à un niveau particulier d’arbre de positionnement, de plan de classement ou d’unité archivistique standard

Un seul contrat d’accès suffit pour déclarer un nœud unique auquel l’application doit accéder, mais ce filtre devra nécessairement être couplé avec la déclaration d’un à plusieurs services producteurs, sans quoi l’application n’accédera pas aux contenus de la solution logicielle Vitam.
Déclarer un nœud permet en effet de réduire le périmètre d’accès aux archives relatives à un ou plusieurs services producteurs.
Par exemple :
- Un Portail Agent pourra accéder aux seuls bulletins de paie, préalablement versés par la Direction des ressources humaines au moyen de son contrat, tandis qu’un SIRH aura accès à l’ensemble des archives produites par cette même direction au moyen de son contrat qui, lui, ne précisera pas de nœud en particulier.
L’application accédera ainsi au nœud en question et à son arborescence descendante.
Points d’attention :
- Les nœuds déclarés dans un contrat d’accès doivent obligatoirement exister dans la solution logicielle Vitam sur le tenant concerné.
- L’usage de ce filtre peut s’avérer nécessaire si on souhaite restreindre les accès d’archives d’un service producteur (ex : Bureau des carrières) qui ont été rattachées à un plan de classement d’un autre service producteur (ex : Direction des ressources humaines). Sans filtre sur ses archives, le premier service producteur peut accéder à l’ensemble des archives de l’autre service producteur.
- À des fins de maintien d’une bonne visibilité sur la gestion des nœuds d’accès, il est conseillé d’adopter, dans la mesure du possible, une pratique uniforme sur la déclaration des nœuds. Par exemple, il n’est pas recommandé, pour un service producteur donné, de créer autant de contrat qu’il y a de nœuds de description.

Recommandé

Application devant accéder à un niveau particulier d’arbre de positionnement, de plan de classement ou d’unité archivistique standard

Il est possible de permettre à une application d’accéder à un niveau particulier d’arborescence en excluant l’accès à tous les autres nœuds de même niveau.
Néanmoins, si on crée a posteriori de nouveaux niveaux d’arborescence, il s’avérera nécessaire de rajouter ces nouveaux niveaux dans le périmètre d’exclusion du contrat d’accès, faute de quoi ces nouveaux niveaux seront accessibles.

Déconseillé

Application devant accéder à un niveau particulier d’arbre de positionnement, de plan de classement ou d’unité archivistique standard, mais ne devant pas avoir accès à un sous-niveau

Le contrat d’accès déclarera un niveau d’arborescence accessible. Il indiquera en outre comme inaccessible le répertoire disposé à un niveau inférieur à ce niveau accessible.

Recommandé

Application devant accéder à plusieurs nœuds

Un contrat d’accès unique permet de déclarer plusieurs nœuds auxquels l’application doit accéder, mais ce filtre devra nécessairement être couplé avec la déclaration d’un à plusieurs services producteurs, sans quoi l’application n’accédera pas aux contenus de la solution logicielle Vitam.
La détermination de plusieurs nœuds d’accès permet réellement d’affiner la granularité des accès.

Recommandé

Application devant accéder à plusieurs nœuds

Il est possible de permettre à une application d’accéder à plusieurs niveaux d’arborescence en excluant l’accès à tous les autres nœuds de même niveau.
Néanmoins, si on crée a posteriori de nouveaux niveaux d’arborescence, il s’avérera nécessaire de rajouter ces nouveaux niveaux dans le périmètre d’exclusion du contrat d’accès, faute de quoi ces nouveaux niveaux seront accessibles.

Déconseillé

Application devant accéder à plusieurs nœuds, mais ne devant pas avoir accès à plusieurs sous-niveaux

Le contrat d’accès déclarera les niveaux d’arborescence accessibles. Il indiquera en outre comme inaccessibles les répertoires disposés à un niveau inférieur à ces niveaux accessibles.

Recommandé

Application devant accéder à un seul tenant et pouvant y télécharger un objet binaire ou intégrer un objet binaire à un DIP

Si une application unique doit accéder à un seul tenant de la solution logicielle Vitam et si :
- elle ne requiert pas de besoins particuliers en matière de consultation des objets binaires,
- elle dispose déjà de paramétrages propres de traçabilité (ex : module de reporting, de statistiques, d’audit),
il n’est pas recommandé d’activer la génération des logs d’accès dans son contrat d’accès.

Non recommandé

SIA et/ou SAE devant télécharger un objet binaire ou intégrer un objet binaire à un DIP

Un système d’information archivistique (SIA) et/ou un système d’archivage électronique (SAE) nécessitant un journal des consultations, il est recommandé d’activer la génération d’un log des accès.

Recommandé

Applications diverses devant accéder aux mêmes archives et pouvant télécharger un objet binaire ou intégrer un objet binaire à un DIP

Si plusieurs applications doivent accéder aux mêmes archives et, de fait, aux mêmes objets binaires, il est recommandé d’activer la génération d’un log des accès dans leur contrat d’accès respectif, afin de pouvoir vérifier a posteriori quelle application a accédé à quels objets binaires.

Recommandé

Instance classifiée devant télécharger un objet binaire ou intégrer un objet binaire à un DIP

En vue d’ajouter une garantie supplémentaire de traçabilité, il est recommandé d’activer la génération d’un log des accès dans le contrat d’accès d’une instance classifiée.

Recommandé

Application devant accéder à plusieurs tenants et pouvant y télécharger un objet binaire ou intégrer un objet binaire à un DIP

Si une application peut accéder à plusieurs tenants, il est recommandé d’activer la génération d’un log des accès dans son contrat d’accès, afin de pouvoir vérifier a posteriori quels objets binaires ont été téléchargés ou ont été intégrés dans un DIP sur quel tenant en particulier.

Recommandé

Application devant accéder aux archives pour simple consultation

Une application devant accéder à la solution logicielle Vitam pour la seule consultation d’archives, un portail par exemple, peut disposer d’un contrat d’accès lui attribuant des droits de lecture et non des droits d’écriture.

Recommandé

Application devant accéder aux archives en fonction de profils utilisateurs

L’utilisation d’un contrat d’accès unique peut ne pas être suffisante pour filtrer les droits d’accès. En effet, pour un SIA, on peut vouloir n’octroyer que des accès limités à certains droits : lecture, modification des seules métadonnées descriptives, administration.
Option 1 : Il reviendra à l’application accédante d’ajouter des filtres d’accès supplémentaires afin de réduire le périmètre des droits des utilisateurs sur les archives.
Option 2 : L’autre solution est d’attribuer plusieurs contrats d’accès à l’application, chacun d’eux déterminant une permission particulière :
- l’un, un droit de lecture sur les archives,
- un autre, un droit d’écriture et de mise à jour des seules métadonnées descriptives,
- un dernier, un droit d’écriture et de mise à jour sur l’ensemble des métadonnées associées à une unité archivistique.

Recommandé

Application disposant d’un contrat d’entrée et d’un contrat d’accès

Une application peut être à la fois versante et accédante.
Ce qu’il faut retenir, qu’une application n’ait qu’un ou plusieurs contrats d’accès, avec ou sans contrat d’entrée, est qu’elle est dépendante de la manière dont les archives, quelles qu’elles soient, ont été versées.
Le choix du service producteur est déterminant en entrée. Si une GED transverse multi-producteurs verse des SIP en ne déterminant qu’un seul service producteur, en accès, il ne sera pas possible de créer des contrats d’accès par sous-producteur, dans la mesure où les SIP ne les désignent pas nommément.
Une des solutions pour éviter cet écueil est de rattacher ces SIP à des nœuds déclarant des producteurs différents. Ainsi, on pourra désigner ces derniers dans les contrats d’accès à associer au contexte de la GED transverse. Et en fonction de ces contrats, il sera possible d’accéder à un sous-producteur.

Recommandé

Application devant accéder aux archives en fonction des règles de gestion

Une application peut n’avoir accès qu’à des archives dont une règle de gestion est échue, c’est-à-dire que sa date d’échéance est égale ou antérieure à la date d’aujourd’hui. Par exemple, un Portail Archives ne pouvant diffuser que des archives communicables et diffusables ne doit accèder qu’à des archives dont les règles de communicabilité et de diffusion sont échues.
Il est alors recommandé d’utiliser le filtre sur les catégories de règle de gestion pour paramétrer les catégories de règles de gestion échues sur lesquelles faire porter l’accès.

Recommandé

Une application peut avoir accès à l’ensemble des archives, quelles que soient leurs règles de gestion et qu’elles soient échues ou non. Il peut s’agir par exemple d’un système d’archivage électronique.

Il n’est alors pas nécessaire d’utiliser le filtre sur les catégories de règle de gestion, puisque l’application a vocation à accéder à l’ensemble des archives conservées dans le système.

Non recommandé

6.6. Annexes

6.6.1. Annexe 1 : exemples d’habilitations

Nota bene : les cas présentés ci-dessous sont des exemples fictifs et visent simplement à vérifier la bonne mise en œuvre des mécanismes relatifs aux habilitations dans la solution logicielle Vitam.

6.6.1.1. Certificat applicatif

{
    "_id": "aeaaaaaaaaftuvruabdvkalafg6qe5yaaaaq",
    "SubjectDN": "CN=ihm-demo, O=vitam, L=paris, ST=idf, C=fr",
    "ContextId": "CT-000001",
    "SerialNumber": 252,
    "IssuerDN": "CN=ca_intermediate_client-external, OU=authorities, O=vitam, L=paris, ST=idf, C=fr",
    "Certificate": "Q2VydGlmaWNhdGU6CiA […] 0tLQ==",
    "Status": "VALID"
}

6.6.1.2. Certificat personnel

{
    "_id": "aeaaaaaaaaftuvruabdvkalafg6q2yqaaaaq",
    "SubjectDN": "O=VITAM, L=Paris, C=FR",
    "SerialNumber": 2,
    "IssuerDN": "O=VITAM, L=Paris, C=FR",
    "Certificate": "MIIFRjCCAy6gAwIBAgIBAjANBgkqhkiG9 […] w0BAQsFADAtM",
    "Hash": "6088f19bc7d328f301168c064d6fda93a6c4ced9d5c56810c4f70e21e77d841d"
    "Status": "VALID"
}

6.6.1.3. Contexte applicatif

{
    "Name": "Contexte pour application 1",
    "Status": "ACTIVE",
    "Permissions": [
        {
            "_tenant": 1,
            "AccessContracts": [
                "AC-000017",
                "AC-000060"
            ],
            "IngestContracts": [
                "IC-000060"
            ]
        },
        {
            "_tenant": 2,
            "AccessContracts": [AC-000001],
            "IngestContracts": [IC-000001]
        }
    ],
    "Identifier": "CT-000001",
    "SecurityProfile": "admin-security-profile"
},
{
    "Name": "Contexte pour application 2",
    "Status": "ACTIVE",
    "Permissions": [
        {
            "_tenant": 1,
            "AccessContracts": [
                "AC-000017",
                "AC-000060"
            ]
        },
        {
            "_tenant": 2
        }
    ],
    "Identifier": "CT-000002",
    "SecurityProfile": "admin-security-profile"
},
{
    "Name": "Contexte pour application 3",
    "Status": "ACTIVE",
    "Permissions": [],
    "Identifier": "CT-000003",
    "SecurityProfile": "admin-security-profile"
}

6.6.1.4. Contrat d’entrée

6.6.1.4.1. Avec profil d’archivage
[
    {
        "Name":"Contrat Archives Départementales",
        "Description":"Test entrée - Contrat Archives Départementales",
        "Status" : "ACTIVE",
    },
    {
        "Name":"Contrat Archives Nationales",
        "Description":"Test entrée - Contrat Archives Nationales",
        "Status" : "INACTIVE",
        "ArchiveProfiles": [
          "PR-000001"
        ]
    }
]
6.6.1.4.2. Avec nœud de rattachement, cône de positionnement des rattachements et autorisation de rattachement
[
	{
		"Name":"3328_IC_INVALID",
		"Identifier":"3328_IC_INVALID",
		"Description":"3328_IC_INVALID",
		"Status" : "ACTIVE",
		"LinkParentId": "aeaaaaaaaahejegaabxyyalfwx45ejyaaaaq",
		"CheckParentLink": "AUTHORIZED",
		"CheckParentId": "aeaaaaaaaahejegaabxyyalfwx45ejyaaaaq2",
	}

]
6.6.1.4.3. Avec filtres sur les types d’objets attendus
[
	{
		"Name":"Contrat_FormatUnidentified_EveryFormatType_plus_autres",
		"Identifier":"Contrat_FormatUnidentified_EveryFormatType_plus_autres",
		"Description":"Contrat de test",
		"Status":"ACTIVE",
		"MasterMandatory": false,
		"EveryDataObjectVersion": true,
		"FormatUnidentifiedAuthorized":true,
		"EveryFormatType": false,
		"FormatType":["fmt/17", "x-fmt/279"]
	}
]
6.6.1.4.4. Avec définition d’un contrat de gestion
[
	{
		"Name":"Contrat d’entrée pour stockage particulier",
		"Identifier":"IC-01",
		"Status" : "ACTIVE",
		"ManagementContractId": "MC-000012"
	}
]
6.6.1.4.5. Avec option d’activation de l’enregistrement en base des règles de gestion héritées
[
	{
		"Name":"Contrat d’entrée pour stockage particulier",
		"Identifier":"IC-01",
		"Status" : "ACTIVE",
		"ComputeInheritedRulesAtIngest": true
	}
]

6.6.1.5. Contrat d’accès

6.6.1.5.1. Avec filtre sur les services producteurs
[
    {
        "Name":"Archives du Doubs",
        "Description":"Accès Archives du Doubs",
        "Status" : "ACTIVE",
        "ActivationDate":"10/12/2016",
        "OriginatingAgencies":["FRA-56","FRA-47"]
    },
    {
        "Name":"Archives du Calvados",
        "Description":"Accès Archives du Calvados",
        "Status" : "ACTIVE",
        "ActivationDate":"10/12/2016",
        "DeactivationDate":"10/12/2016",
        "OriginatingAgencies":["FRA-54","FRA-64"]
        "EveryOriginatingAgency": false,
        "EveryDataObjectVersion": true,    },
  
{
	"Name":"Archives de Paris",
	 "Description":"Accès Archives de Paris",
	 "Status" : "INACTIVE",
	 "EveryOriginatingAgency": true
   }
]
6.6.1.5.2. Avec filtre sur les usages
[
	{
		"Name":"Archives du Haut-Rhin",
             "Description":"Accès Archives du Haut-Rhin",
		"Status":"ACTIVE",
		"OriginatingAgencies":["Identifier0"],
		"DataObjectVersion": ["BinaryMaster", "Dissemination"]
	},
    {
        "Name":"Archives du Bas-Rhin",
        "Description":"Accès Archives du Bas-Rhin",
        "Status" : "ACTIVE",
        "OriginatingAgencies":["FRA-54","FRA-64"]
        "EveryOriginatingAgency": false,
        "EveryDataObjectVersion": true
    }
]
6.6.1.5.3. Avec filtre sur les nœuds d’accès et d’exclusion
{
		"Name":"Archives du Vaucluse",
		"Description":"Accès Archives du Vaucluse",
		"Status" : "ACTIVE",
		"EveryOriginatingAgency": true,
		"EveryDataObjectVersion": true,
		"ExcludedRootUnits": ["aeaaaaaaaahejegaabxyyalfwx45ejyaaaaq"],
		"RootUnits": ["aeaaaaaaaahejegaabxyyalfwx45ejyaaaaq ?"]
	}
6.6.1.5.4. Avec filtre sur les catégories de règle de gestion
{
		"Name":"Archives du Vaucluse",
		"Description":"Accès Archives du Vaucluse",
		"Status" : "ACTIVE",
		"RuleCategoryToFilter": ["DisseminationRule", AccessRule"]
	}
6.6.1.5.5. Avec filtre sur les droits
[
    {
        "Name":"NoUpdatesAllowed",
	"Identifier": "NoUpdatesAllowed",
        "Description":"Contrat d'accès - Sans droits de modification des unités archivistiques",
        "Status" : "ACTIVE",
	"EveryOriginatingAgency": true,
	"WritingPermission": false,
	"WritingRestrictedDesc": false
    }, {
        "Name":"AllUpdatesAllowed",
	"Identifier": "AllUpdatesAllowed",
        "Description":"Contrat d'accès - Droit de mise à jour complet",
        "Status" : "ACTIVE",
	"EveryOriginatingAgency": true,
	"WritingPermission": true,
	"WritingRestrictedDesc": false
    }, {
        "Name":"OnlyDescUpdateAllowed",
	"Identifier": "OnlyDescUpdateAllowed",
        "Description":"Contrat d'accès - Droit de modification restraint aux unités archivistiques",
        "Status" : "ACTIVE",
	"EveryOriginatingAgency": true,
	"WritingPermission": true,
	"WritingRestrictedDesc": true
    }, {
        "Name":"DefaultWritePermissions",
	"Identifier": "DefaultWritePermissions",
        "Description":"Contrat d’accès - Modifications autorisées sans précisions supplémentaires",
        "Status" : "ACTIVE",
	"EveryOriginatingAgency": true,
	"WritingPermission": true
    }
]

6.6.1.6. Profil de sécurité

6.6.1.6.1. Avec permissions
{ 
“_id”: “aegqaaaaaaeucszwabglyak64gjmgbyaaaba”, “Identifier”: “SEC_PROFILE-000002, 
“Name”: “demo-security-profile”, 
“FullAccess”: false, 
“Permissions: [
“securityprofiles:create, “securityprofiles:read”, “securityprofiles:id:read”, “securityprofiles:id:update, “accesscontracts:read”, “accesscontracts:id:read”, “contexts:id:update
],
"_v": 0
}
6.6.1.6.2. Avec toutes les permissions
{
    "_id": "aegqaaaaaahe4mtkaa4vwak7ysw3jdyaaaaq",
    "Identifier": "admin-security-profile",
    "Name": "admin-security-profile",
    "FullAccess": true,
    "_v": 0
}

6.6.1.7. Contrat de gestion

6.6.1.7.1. Avec stratégies de stockage
{
    "_id": "aefqaaaaaahjy6rtaahlsalm75wl6waaaaaq",
    "Name": "Contrat de gestion avec stockage",
    "Identifier": "MCDefaultStorageAll",
    "Description": "Contrat de gestion valide déclarant pas de surcharge pour le stockage avec la stratégie par défaut",
    "Status": "ACTIVE",
    "Storage": {
        "UnitStrategy": "default",
        "ObjectGroupStrategy": "default",
        "ObjectStrategy": "default"
    }
}
6.6.1.7.2. Sans stratégie de stockage
{
    "_id": "aefqaaaaaahjy6rtaahlsalm75wl6jqaaaaq",
    "Name": "Contrat de gestion sans stockage",
    "Identifier": "MCNoStorage",
    "Description": "Contrat de gestion valide ne déclarant pas de surcharge pour le stockage",
    "Status": "ACTIVE"
}
6.6.1.7.3. Avec politique de préservation générique
{
		"Name": "Contrat de gestion avec politique de conservation : conservation générale de toutes les versions / aucun cas spécifique par usage",
		"Identifier": "MCDefaultStorageAll-1",
		"Description": "Contrat de gestion valide ne déclarant pas de surcharge pour le stockage avec la stratégie par défaut",
		"Status": "ACTIVE",
		"VersionRetentionPolicy": 
			{
			"InitialVersion": true,
			"IntermediaryVersion": "ALL"
			}
	}
6.6.1.7.4. Avec politique de préservation spécifique
{
		"Name": "Contract with conservation policy 20",
		"Description": "contractWithPolicy20",
		"Identifier": "contractWithPolicy-20",
		"Status": "ACTIVE",
		"VersionRetentionPolicy": {
			"InitialVersion": true,
			"IntermediaryVersion": "LAST",
			"Usages": [
			{
				"UsageName": "BinaryMaster",
				"InitialVersion": true,
				"IntermediaryVersion": "LAST"
			},
			{
				"UsageName": "Dissemination",
				"InitialVersion": false,
				"IntermediaryVersion": "ALL"
			}
			]
		}
	}
6.6.1.7.5. Avec stratégie d’identification pérenne
	{
		"Name": "MCWithIdentificationStrategy-1",
		"Identifier": "MCWithIdentificationStrategy-1",
		"Description": "Contrat de gestion avec politique d'identification : identification de l'unité archivistique, de la version courante + avant-dernière pour tous les usages sauf BinaryMaster où l'on identifie également la première",
		"Status": "ACTIVE",
		"PersistentIdentifierPolicy": [
			{
				"PersistentIdentifierPolicyType": "ARK",
				"PersistentIdentifierUnit": true,
				"PersistentIdentifierAuthority": 12354,
				"PersistentIdentifierUsages": [
					{
						"UsageName": "BinaryMaster",
						"InitialVersion": true,
						"IntermediaryVersion": "LAST"
					},
					{
						"UsageName": "Dissemination",
						"InitialVersion": false,
						"IntermediaryVersion": "NONE"
					},
					{
						"UsageName": "Thumbnail",
						"InitialVersion": false,
						"IntermediaryVersion": "ALL"
					},
					{
						"UsageName": "TextContent",
						"InitialVersion": true,
						"IntermediaryVersion": "LAST"
					},
					{
						"UsageName": "PhysicalMaster",
						"InitialVersion": false,
						"IntermediaryVersion": "LAST"
					}
        ]
      }
    ]
	}

6.6.2. Annexe 2 : cas d’utilisation des habilitations

Nota bene : les cas présentés ci-dessous sont des exemples fictifs. Ils visent simplement à vérifier la bonne mise en œuvre des mécanismes relatifs aux habilitations dans la solution logicielle Vitam.

6.6.2.1. Cas 1

L’ensemble du plan de classement et des SIP ont pour unique producteur « Direction des Ressources humaines ».

  • Contrat d’entrée

    • 1 / Une application comptable devant transférer des états récapitulatifs aura un contrat d’entrée lui permettant de verser des SIP dans le répertoire « État récapitulatif des frais de déplacement ».

    • 2 / Un SIRH doit transférer pour archivage courant des SIP dans les différents dossiers du plan de classement : il faudra créer autant de contrat d’entrée qu’il y a de dossiers de destination dans le plan de classement. Le SIP déclarera le contrat d’entrée mentionnant le nœud de rattachement adéquat.

  • Contrat d’accès

    • 1 / Une application comptable devra accéder aux états récapitulatifs. Son contrat d’accès aura pour paramètres :

      • service producteur = « Direction des ressources humaines »

      • nœud : « État récapitulatif des frais de déplacement » La déclaration du nœud est obligatoire, sans quoi l’application accéderait à l’ensemble des archives de la direction.

    • 2 / Un SIRH doit accéder à l’ensemble des archives de la direction. Son contrat d’accès doit déclarer les éléments suivants :

      • service producteur = « Direction des ressources humaines »

    • 3 / Un SIRH doit accéder à l’ensemble des archives de la direction, sauf à celle du « Service comptable ». Son contrat d’accès doit déclarer les éléments suivants :

      • service producteur = « Direction des ressources humaines »

      • nœuds = « Service de gestion des carrières », « Service de la formation ».

    • 4 / Un SIRH veut filtrer ses accès par service. Il aura autant de contrat d’accès qu’il y a de services, soit 3. Chaque contrat devra déterminer :

      • service producteur = « Direction des ressources humaines »

      • nœud : chaque contrat déterminera le nœud à partir duquel un service pourra consulter ses archives. Dans le cas présent, le nœud correspond au niveau « Service… ».

6.6.2.2. Cas 2

Un plan de classement ayant pour producteur « Direction des Ressources humaines » englobe des plans de classement propres à chaque service, ayant chacun leur propre service producteur. L’un d’eux, « Service comptable », dispose d’un nouveau plan de classement inférieur, pour le « Service de gestion des déplacements ». Ce cas d’usage vaut également si les plans de classement de niveau « Service » sont remplacés par des SIP.

  • Contrat d’entrée

    • Rien ne change dans la déclaration des contrats d’entrée. Les exemples définis précédemment fonctionnent.

  • Contrat d’accès

    • 1 / Une application comptable devra accéder aux états récapitulatifs. Son contrat d’accès aura pour paramètres :

      • service producteur = « Direction des ressources humaines » ou « Service comptable » ou « Service de gestion des déplacements ».

      • nœud : « État récapitulatif des frais de déplacement » La déclaration du nœud est obligatoire, sans quoi l’application accéderait à l’ensemble des archives de la direction ou des services.

    • 2 / Un SIRH doit accéder à l’ensemble des archives de la direction. Son contrat d’accès doit déclarer les éléments suivants :

      • service producteur = « Direction des ressources humaines »

    • 3 / Un SIRH doit accéder à l’ensemble des archives de la direction, sauf à celle du « Service comptable ». Son contrat d’accès doit déclarer les éléments suivants :

      • service producteur = « Service de gestion des carrières » et « Service de la formation ».

    • 4 / Un SIRH veut filtrer ses accès par service. Il aura autant de contrat d’accès qu’il y a de services, soit 3. Chaque contrat devra déterminer :

      • service producteur = le service concerné par le contrat.

    • 5 / Un portail « Ordre de mission » doit accéder au « Dossier de stage » et aux archives du « Service de gestion des déplacements ». Son contrat d’accès comportera les paramètres suivants :

      • service producteur = « Service de la formation » et « Service de gestion des déplacements ».

      • nœud = « Dossier de stage ». Si on ne déclare pas ce nœud, le portail accédera à l’ensemble des archives du Service de la formation.

6.6.3. Annexe 3 : liste des permissions et privilèges

Liste des permissions qui peuvent être associées à :

  • un profil de sécurité,

  • un certificat personnel (à l’exception des trois permissions écrites en italiques).

Nota bene : Cette liste n’est pas forcément exhaustive.

Service

Fonctionnalité

Permission correspondante

Contextes applicatifs

Importer des contextes dans le référentiel

contexts:create:json

Lister le contenu du référentiel des contextes

contexts:read

Lire un contexte donné

contexts:id:read

Effectuer une mise à jour sur un contexte

contexts:id:update

Contrats d’entrée

Importer des contrats d’entrée dans le référentiel

ingestcontracts:create:json

Lister le contenu du référentiel des contrats d’entrée

ingestcontracts:read

Lire un contrat d’entrée donné

ingestcontracts:id:read

Effectuer une mise à jour sur un contrat d’entrée

ingestcontracts:id:update

Contrats d’accès

Importer des contrats d’accès dans le référentiel

accesscontracts:create:json

Lister le contenu du référentiel des contrats d’accès

accesscontracts:read

Lire un contrat d’accès donné

accesscontracts:id:read

Effectuer une mise à jour sur un contrat d’accès

accesscontracts:id:update

Contrat de gestion

Importer des contrats de gestion dans le référentiel

managementcontracts:create:json

Lister le contenu du référentiel des contrats de gestion

managementcontracts:read

Lire un contrat de gestion donné

managementcontracts:id:read

Effectuer une mise à jour sur un contrat de gestion

managementcontracts:id:update

Profils de sécurité

Importer des profils de sécurité dans le référentiel

securityprofiles:create:json

Lister le contenu du référentiel des profils de sécurité

securityprofiles:read

Lire un profil de sécurité donné

securityprofiles:id:read

Effectuer une mise à jour sur un profil de sécurité

securityprofiles:id:update

Ontologie

Importer le référentiel ontologique

ontologies:create:json

Lister le contenu du référentiel ontologique

ontologies:read

Lire un vocabulaire

ontologies:id:read:json

Profils d’unité archivistique

Importer un ou plusieurs profils d’unité archivistique dans le référentiel

archiveunitprofiles:create:binary

Ecrire un ou plusieurs profils d’unité archivistique dans le référentiel

archiveunitprofiles:create:json

Lister le contenu du référentiel des profils d’unité archivistique

archiveunitprofiles:read

Lire un profil d’unité archivistique donné

archiveunitprofiles:id:read:json

Effectuer une mise à jour sur un profil d’unité archivistique

archiveunitprofiles:id:update:json

Profils d’archivage

Importer des profils dans le référentiel

profiles:create:binary

Écrire un profil dans le référentiel

profiles:create:json

Lister le contenu du référentiel des profils

profiles:read

Importer un fichier xsd ou rng dans un profil

profiles:id:update:binaire

Télécharger le fichier xsd ou rng attaché à un profil

profiles:id:read:binary

Lire un profil donné

profiles:id:read:json

Effectuer une mise à jour sur un profil

profiles:id:update:json

Formats

Importer un référentiel des formats

formats:create

Lister le contenu du référentiel des formats

formats:read

Lire un format donné

formats:id:read

Vérifier si le référentiel des formats que l’on souhaite importer est valide

formatsfile:check

Règles de gestion

Lister le contenu du référentiel des règles de gestion

rules:read

Vérifier si le référentiel de règles de gestion que l’on souhaite importer est valide

rulesfile:check

Lire une règle de gestion donnée

rules:id:read

Importer un référentiel des règles de gestion

rules:create

Récupérer le rapport pour une opération d’import de règles de gestion

rulesreport:id:read

Récupérer le référentiel pour une opération d’import de référentiel de règles de gestion

rulesreferential:id:read

Services agents

Vérifier si le référentiel de services agents que l’on souhaite importer est valide

agenciesfile:check

Importer un référentiel des services agents

agencies:create

Trouver un service agents avec son identifier

agencies:id:read

Lister le contenu du référentiel des services agents

agencies:read

Récupérer le référentiel pour une opération d’import de référentiel des services agents

agenciesreferential:id:read

Création d’un projet de versement

project:create

Récupère la liste des projets de versement

project:read

Récupère la liste des projets de versement par critère de recherche

project:query:read

Récupère un projet de versement

project:id:read

Récupérer la liste des transactions du projet

project:id:transactions

Mise à jour d’un projet de versement

project:update

Supprime un projet de versement

project:id:delete

Récupère toutes les unités archivistiques associées à un projet

project:id:units

Collect

Création de la transaction

transaction:create

Mise à jour d’une transaction

transaction:update

Clôture de la transaction

transaction:close

Envoi de la transaction

transaction:send

Abandonner une transaction

transaction:abort

Rouvrir une transaction

transaction:reopen

Récupère une transaction

transaction:id:read

Supprime une transaction

transaction:id:delete

Charge les binaires en lot

transaction:zip:create

Créer une unité archivistique

transaction:unit:create

Verser une archive arborescente ZIP à un projet de versement automatique sans transaction

createproject:id:zip:create

Récupère toutes les unités archivistiques

transaction:unit:read

Récupère les unités archivistiques d’une transaction

transaction:id:units

Récupère une unité archivistique

transaction:unit:id:read

Mettre à jour les unités archivistiques

transaction:id:units:update

Créer un groupe d’objets techniques

transaction:object:upsert

Insérer un objet binaire

transaction:binary:upsert

Récupère un groupe d’objets techniques

transaction:object:read

Télécharge un usage/version du binaire d’un groupe d’objets

transaction:binary:read

Mise à jour unitaire en masse des métadonnées descriptives

transaction:id:units:bulk:update

Entrées

Récupérer l’accusé de réception pour une opération d’entrée donnée

ingests:id:archivetransfertreply:read

Récupérer le bordereau de versement pour une opération d’entrée donnée

ingests:id:manifests:read

Envoyer un SIP à Vitam afin qu’il en réalise l’entrée

ingests:create

Envoyer un SIP en local à Vitam afin qu’il en réalise l’entrée

ingests:local:create

Registre des fonds

Lister le contenu du référentiel des registres des fonds

accessionregisters:read

Lister les détails d’un registre de fonds

accessionregisters:id:accessionregisterdetails:read

Lister les détails d’un registre de fonds symbolique

accessionregisterssymbolic:read

Lister le contenu du référentiel détails des registres des fonds

accessionregisterdetails:read

Unités archivistiques et objets

Récupérer la liste des unités archivistiques

units:read

Récupérer une liste de plus de 10 000 unités archivistiques

units:stream

Récupérer une unité archivistique par identifiant pérenne

units:unitsbypersistentidentifier:id:read

Récupérer la liste des unités archivistiques avec leurs règles de gestion héritées

unitsWithInheritedRules:read

Lancer le processus de calcul des règles héritées à des fins de recherche

computeInheritedRules:action

Lancer la suppression du calcul des règles héritées à des fins de recherche

computeInheritedRules:delete

Récupérer la liste des unités archivistiques avec leurs règles de gestion héritées

unitsWithInheritedRules:read

Récupérer la liste des groupes d’objets techniques

objects:read

Obtenir le détail d’une unité archivistique au format JSON

units:id:read:json

Réaliser la mise à jour d’une unité archivistique

units:id:update

Mise à jour en masse des unités archivistiques

units:update

Mise à jour en masse des règles de gestion des unités archivistiques

units:rules:update

Restauration des métadonnées essentielles

units:update:revert

Mise à jour unitaire des métadonnées descriptives au moyen d’une opération de masse

units:bulk:update

Téléchargement de rapports liés aux mises à jour de masse

distributionreport:id:read

Reclassification d’unités archivistiques

reclassification:update

Télécharger le groupe d’objets techniques de l’unité archivistique donnée

units:id:objects:read:json

Télécharger un objet binaire

units:id:objects:read:binary

Télécharger un objet binaire avec l’identifiant pérenne d’une unité archivistique

objects:unitsbypersistentidentifier:id:objects:read:binary

Télécharger un objet binaire avec identifiant pérenne

objects:objectsbypersistentidentifier:id:read:binary

Créer une demande d’accès à un objet persisté sur une offre froide (bande magnétique)

units:id:objects:accessrequests:create

Vérifier l’état d’un ensemble de demandes d’accès sur une offre froide (bande magnétique)

accessrequests:check

Supprimer une demande d’accès à un objet persisté sur une offre froide (bande magnétique)

accessrequests:remove

DIP

Générer le DIP à partir d’un DSL

dipexport:create

Récupérer le DIP

dipexport:id:dip:read

Journaux

Créer une opération externe

logbookoperations:create

Lister toutes les opérations

logbookoperations:read

Récupérer le journal de cycle de vie d’une unité archivistique

logbookunitlifecycles:id:read

Récupérer le journal de cycle de vie d’un groupe d’objets techniques

logbookobjectslifecycles:id:read

Récupérer le journal d’une opération donnée

logbookoperations:id:read

Télécharger les journaux d’accès

storageaccesslog:read:binary

Traçabilité

Télécharger le logbook sécurisé attaché à une opération de sécurisation

traceability:id:read

Tester l’intégrité d’un journal sécurisé

traceabilitychecks:create

Audit de vérification des journaux sécurisés

traceabilitylinkedchecks:create

Génère un relevé de valeur probante

probativevalue:create

Audit

Lancer un audit de l’existence des objets binaires

audits:create

Audit de traçabilité d’unités archivistiques

evidenceaudit:check

Rectification de données suite à un audit

rectificationaudit:check

Télécharger le rapport d’audit

batchreport:id:read

Lancer un audit de l’existence de référentiel

referentialaudit:check

Élimination

Lance la phase d’analyse dans le cadre d’une élimination

elimination:analysis

Lance la phase d’action dans le cadre d’une élimination

elimination:action

Télécharger le rapport d’élimination

batchreport:id:read

Suppression d’objets

Supprimer des versions d’usage d’objets

objects:deleteGotVersions

Transfert

Générer le SIP à transférer à partir d’une requête DSL

transfers:create

Récupérer le SIP transféré

transfers:id:sip:read

Lance un acquittement de transfert

transfers:reply

Griffons

Importer un référentiel des griffons

griffins:create

Récupérer la liste des griffons

griffins:read

Lire un griffon donné

griffin:read

Scénarios de préservation

Importer un référentiel des scénarios de préservation

preservationScenarios:create

Récupérer la liste des scénarios de préservation

preservationScenarios:read

Lire un scénario de préservation donné

preservationScenario:read

Préservation

Lance le processus de préservation

preservation:update

Télécharger le rapport de préservation

batchreport:id:read

Gestion des opérations

Récupérer les informations sur une opération donnée

operations:read

Récupérer le code HTTP d’une opération donnée

operations:id:read:status

Récupérer le statut d’une opération donnée

operations:id:read

Changer le statut d’une opération donnée

operations:id:update

Annuler une opération donnée

operations:id:delete

Récupérer la liste des tâches des workflows

workflows:read

Force la pause sur un type d’opération et/ou sur un tenant

forcepause:check

Retire la pause sur un type d’opération et/ou sur un tenant

removeforcepause:check

Index

Réindexer une collection

reindex:create

Switch indexes

switchindex:create

6.6.4. Annexe 4 : fonctionnement du log des accès

6.6.4.1. Description

Le contrat d’accès permet de préciser si des logs d’accès doivent être générés. Par défaut, cette option n’est pas activée.

Le log des accès est généré lors d’un accès à l’objet binaire (fichier numérique), que ce soit par téléchargement de l’objet binaire ou export d’un DIP. Les accès à l’unité archivistique ne sont pas concernés.

Les logs de l’heure en cours peuvent être consultés sur les machines hébergeant le composant storage sous l’arborescence « /vitam/log/storage/access-log/ ». Chaque fichier de log est nommé « <id opération>.log ». Toutes les heures, les logs sont archivés et sont alors accessibles dans des containers nommés <environnement>_<tenant>_storageaccesslog.

6.6.4.2. Structure des logs

  • « eventDateTime » : date et heure de l’accès au format AAAA-MM-JJTHH:MM:SS:[3 digits de millisecondes]

  • « xRequestId » : identifiant de l’opération d’export du DIP

  • « applicationId » : identifiant de l’application ayant demandé l’export du DIP

  • « objectIdentifier » : identifiant de l’objet binaire auquel on a accédé

  • « size » : taille en octets de l’objet binaire

  • « qualifier » : usage de l’objet binaire

  • « version » : version de l’usage de l’objet binaire

  • « contextId » : identifiant du contexte utilisé pour l’accès

  • « contractId » : identifiant du contrat utilisé pour l’accès

  • « archivesId » : identifiant de l’unité archivistique dont dépend le groupe d’objets techniques contenant l’objet binaire auquel on a accédé

6.6.4.3. Exemple de log généré lors de l’export d’un DIP d’une unité archivistique ayant un GOT contenant un objet

{"eventDateTime":"2019-01-11T12:50:53.344",
"xRequestId":"aeeaaaaaachfmo4dabyw6aliht3q74aaaaaq",
"applicationId":"MyApplicationId-ChangeIt",
"objectIdentifier":"aeaaaaaaaahk2vrsabz26alhywthyoaaaaba",
"size":"11",
"qualifier":"BinaryMaster",
"version":"1",
"contextId":"CT-000001",
"contractId":"ContratTNR",
"archivesId":"aeaqaaaaaahk2vrsabz26alhywthzbaaaaea"}
6.6.4.3.1. Exemple de logs généré lors de l’export d’un DIP de sept unités archivistiques dont quatre seulement avaient un GOT contenant un objet
{"eventDateTime":"2019-01-11T12:51:46.185",
"xRequestId":"aeeaaaaaachfmo4dabyw6aliht36c6qaaaaq",
"applicationId":"MyApplicationId-ChangeIt",
"objectIdentifier":"aeaaaaaaaaherlfzabz5salhywpmhkaaaaba",
"size":"29403",
"qualifier":"BinaryMaster",
"version":"1",
"contextId":"CT-000001",
"contractId":"ContratTNR",
"archivesId":"aeaqaaaaaaherlfzabz5salhywpmhlyaaaaq"}

{"eventDateTime":"2019-01-11T12:51:46.200",
"xRequestId":"aeeaaaaaachfmo4dabyw6aliht36c6qaaaaq",
"applicationId":"MyApplicationId-ChangeIt",
"objectIdentifier":"aeaaaaaaaaherlfzabz5salhywpmhkiaaaaq",
"size":"68438",
"qualifier":"BinaryMaster",
"version":"1",
"contextId":"CT-000001",
"contractId":"ContratTNR",
"archivesId":"aeaqaaaaaaherlfzabz5salhywpmhlyaaabq"}

{"eventDateTime":"2019-01-11T12:51:46.208",
"xRequestId":"aeeaaaaaachfmo4dabyw6aliht36c6qaaaaq",
"applicationId":"MyApplicationId-ChangeIt",
"objectIdentifier":"aeaaaaaaaaherlfzabz5salhywpmhjyaaaaq",
"size":"29403",
"qualifier":"BinaryMaster",
"version":"1",
"contextId":"CT-000001",
"contractId":"ContratTNR",
"archivesId":"aeaqaaaaaaherlfzabz5salhywpmhliaaaba"}

{"eventDateTime":"2019-01-11T12:51:46.221",
"xRequestId":"aeeaaaaaachfmo4dabyw6aliht36c6qaaaaq",
"applicationId":"MyApplicationId-ChangeIt",
"objectIdentifier":"aeaaaaaaaaherlfzabz5salhywpmhjyaaabq",
"size":"29403",
"qualifier":"BinaryMaster",
"version":"1",
"contextId":"CT-000001",
"contractId":"ContratTNR",
"archivesId":"aeaqaaaaaaherlfzabz5salhywpmhlqaaaba"}

6.6.4.4. Exemple de logs générés lors de l’export d’une unité archivistique ayant un GOT comprenant trois objets

{"eventDateTime":"2019-01-11T13:22:12.686",
"xRequestId":"aeeaaaaaachfmo4dabyw6alihuj4btqaaaaq",
"applicationId":"MyApplicationId-ChangeIt",
"objectIdentifier":"aeaaaaaaaaherlfzabz5salhywnsvrqaaabq",
"size":"44266",
"qualifier":"Thumbnail",
"version":"1",
"contextId":"CT-000001",
"contractId":"ContratTNR",
"archivesId":"aeaqaaaaaaherlfzabz5salhywnsvsaaaaaq"}

{"eventDateTime":"2019-01-11T13:22:12.700",
"xRequestId":"aeeaaaaaachfmo4dabyw6alihuj4btqaaaaq",
"applicationId":"MyApplicationId-ChangeIt",
"objectIdentifier":"aeaaaaaaaaherlfzabz5salhywnsvraaaaaq",
"size":"127244",
"qualifier":"BinaryMaster",
"version":"1",
"contextId":"CT-000001",
"contractId":"ContratTNR",
"archivesId":"aeaqaaaaaaherlfzabz5salhywnsvsaaaaaq"}

{"eventDateTime":"2019-01-11T13:22:12.718",
"xRequestId":"aeeaaaaaachfmo4dabyw6alihuj4btqaaaaq",
"applicationId":"MyApplicationId-ChangeIt",
"objectIdentifier":"aeaaaaaaaaherlfzabz5salhywnsvrqaaaaq",
"size":"57850",
"qualifier":"Dissemination",
"version":"1",
"contextId":"CT-000001",
"contractId":"ContratTNR",
"archivesId":"aeaqaaaaaaherlfzabz5salhywnsvsaaaaaq"}

6.6.4.5. Exemple de log généré lors de l’export d’un seul des usages de la même unité archivistique que ci-dessus

{"eventDateTime":"2019-01-11T14:17:52.472",
"xRequestId":"aeeaaaaaachfmo4dabyw6alihvdlm5aaaaaq",
"applicationId":"MyApplicationId-ChangeIt",
"objectIdentifier":"aeaaaaaaaaherlfzabz5salhywnsvrqaaaaq",
"size":"57850",
"qualifier":"Dissemination",
"version":"1",
"contextId":"CT-000001",
"contractId":"ContratTNR",
"archivesId":"aeaqaaaaaaherlfzabz5salhywnsvsaaaaaq"}

6.6.5. Annexe 5 : Messages d’erreur

Nota bene :

  • les cas présentés ci-dessous n’ont pas vocation à être exhaustif.

  • cette annexe étant encore en construction, des messages d’erreur lors de l’import et/ou de la mise à jour de certaines habilitations ne sont pas encore couverts.

6.6.5.1. Contexte applicatif

6.6.5.1.1. Import d’un contexte

Message retourné par la solution logicielle Vitam

Explication

Résolution

1

{ « contextCheck » : « Import contexts error > fr.gouv.vitam.common.json.JsonSchemaValidationException: Document schema validation failed : \n{« validateJson »:[{« level »: »error », »schema »:{« loadingURI »: »# », »pointer »: » »}, »instance »:{« pointer »: » »}, »domain »: »validation », »keyword »: »required », »message »: »object has missing required properties (["Permissions"]) », »required »:[« CreationDate », »EnableControl », »Identifier », »LastUpdate », »Name », »Permissions », »SecurityProfile », »Status », »_id », »_v »], »missing »:[« Permissions »]}]} » }

Le contexte applicatif ne contient pas de champ « Permissions », pourtant obligatoire, ce qui génère une erreur de validité du contexte applicatif par rapport aux champs attendus par le schéma de contrôle des contextes.

Il est nécessaire de rajouter dans le contexte applicatif un champ « Permissions », tableau pouvant être vide.

2

« outDetail »: « STP_IMPORT_CONTEXT.IDENTIFIER_DUPLICATION.KO »,
 »outMessg »:
 »Échec de l’import du contexte applicatif : l’identifiant est déjà utilisé »
 »evDetData »:
{ « Duplicate field » : « The context Contexte_de_test already exists in database » }

L’utilisateur a importé à deux reprises un contexte applicatif ayant le même identifiant, sur une plate-forme où l’identifiant est géré par le front-office.

Modifier l’identifiant du second contexte applicatif.

3

« outDetail »: « STP_IMPORT_CONTEXT.EMPTY_REQUIRED_FIELD.KO »,
 »outMessg »:
 »Échec de l’import du contexte : au moins un des champs obligatoires n’est pas renseigné »
 »evDetData »:
{ « Mandatory fields » : « The field Name is mandatory » }

Deux possibilités :
- soit le contexte applicatif ne contient pas le champ obligatoire Name ;
- soit le contexte applicatif contient un champ Name sans aucune valeur.

Deux possibilités :
- rajouter dans le fichier JSON correspondant au contexte applicatif le champ obligatoire Name ;
- rajouter une valeur au champ Name présent dans le fichier JSON correspondant au contexte applicatif.

4

« outDetail »: « STP_IMPORT_CONTEXT.EMPTY_REQUIRED_FIELD.KO »,
 »outMessg »:
 »Échec de l’import du contexte : au moins un des champs obligatoires n’est pas renseigné »
 »evDetData »:
{ « Mandatory fields » : « The field Identifier is mandatory » }

Deux possibilités :
- soit le contexte applicatif ne contient pas le champ obligatoire Identifier ;
- soit le contexte applicatif contient un champ Identifier sans aucune valeur.

Deux possibilités :
- rajouter dans le fichier JSON correspondant au contexte applicatif le champ obligatoire Identifier ;
- rajouter une valeur au champ Identifier présent dans le fichier JSON correspondant au contexte applicatif.

5

« outDetail »: « STP_IMPORT_CONTEXT.EMPTY_REQUIRED_FIELD.KO »,
 »outMessg »:
 »Échec de l’import du contexte : au moins un des champs obligatoires n’est pas renseigné »
 »evDetData »:
{ « Mandatory fields » : « The field SecurityProfile is mandatory » }

Deux possibilités :
- soit le contexte applicatif ne contient pas le champ obligatoire SecurityProfile ;
- soit le contexte applicatif contient un champ SecurityProfile sans aucune valeur.

Deux possibilités :
- rajouter dans le fichier JSON correspondant au contexte applicatif le champ obligatoire SecurityProfile ;
- rajouter une valeur au champ SecurityProfile présent dans le fichier JSON correspondant au contexte applicatif.

6

« outDetail »: « STP_IMPORT_CONTEXT.EMPTY_REQUIRED_FIELD.KO »,
 »outMessg »:
 »Échec de l’import du contexte : au moins un des champs obligatoires n’est pas renseigné »
 »evDetData »:
{ « Mandatory fields » : « The field Permissions is mandatory » }

Le contexte applicatif ne contient pas le champ obligatoire Permissions. À noter que l’élément peut être vide, mais doit obligatoirement être présent.

Rajouter dans le fichier JSON correspondant au contexte applicatif le champ obligatoire Permissions.

7

« outDetail »:
 »STP_IMPORT_CONTEXT.UNKNOWN_VALUE.KO »
 »outMessg »:
 »Échec de l’import du contexte applicatif : au moins un objet déclare une valeur inconnue »
 »evDetData »:
{ « Incorrect field » : « The access contract XYZ does not exist » }

Le contexte applicatif contient un contrat d’accès non référencé dans la solution logicielle Vitam, c’est-à-dire qu’il n’existe pas sur le tenant requis.

Importer sur le tenant requis le contrat d’accès, avant de réimporter le contexte applicatif déclarant le contrat d’accès jusque-là en erreur.

8

« outDetail »:
 »STP_IMPORT_CONTEXT.UNKNOWN_VALUE.KO »
 »outMessg »:
 »Échec de l’import du contexte applicatif : au moins un objet déclare une valeur inconnue »
 »evDetData »:
{ « Incorrect field » : « The ingest contract XYZ does not exist » }

Le contexte applicatif contient un contrat d’entrée non référencé dans la solution logicielle Vitam, c’est-à-dire qu’il n’existe pas sur le tenant requis.

Importer sur le tenant requis le contrat d’entrée, avant de réimporter le contexte applicatif déclarant le contrat d’entrée jusque-là en erreur.

6.6.5.1.2. Mise à jour d’un contexte applicatif

Message retourné par la solution logicielle Vitam

Explication

Résolution

1

« outDetail »:
 »STP_UPDATE_CONTEXT.UNKNOWN_VALUE.KO »
 »outMessg »:
 »Échec du processus de mise à jour du contexte applicatif : au moins un objet déclare une valeur inconnue »
 »evDetData »:
{ « Incorrect field » : « The access contract XYZ does not exist » }
OU
{ « contextCheck » : « Invalid identifier of the access contract:XYZ » }

Le contexte applicatif contient un contrat d’accès non référencé dans la solution logicielle Vitam, c’est-à-dire qu’il n’existe pas sur le tenant requis.

Vérifier l’existence du contrat d’accès que l’on souhaite ajouter dans le contexte applicatif, ainsi que son identifiant, avant de retenter la mise à jour du contexte applicatif déclarant le contrat d’accès jusque-là en erreur.

2

« outDetail »:
 »STP_UPDATE_CONTEXT.UNKNOWN_VALUE.KO »
 »outMessg »:
 »Échec du processus de mise à jour du contexte applicatif : au moins un objet déclare une valeur
nconnue »
 »evDetData »:
{ « Incorrect field » : « The ingest contract XYZ does not exist » }
OU
{ « contextCheck » : « Invalid identifier of the ingest contract:XYZ » }

Le contexte applicatif contient un contrat d’entrée non référencé dans la solution logicielle Vitam, c’est-à-dire qu’il n’existe pas sur le tenant requis.

Vérifier l’existence du contrat d’entrée que l’on souhaite ajouter dans le contexte applicatif, ainsi que son identifiant, avant de retenter la mise à jour du contexte applicatif déclarant le contrat d’entrée jusque-là en erreur.

6.6.5.2. Profil de sécurité

6.6.5.2.1. Import d’un profil de sécurité

Message retourné par la solution logicielle Vitam

Explication

Résolution

1

outDetail »:
 »STP_IMPORT_SECURITY_PROFILE.KO »
 »outMessg »:
 »Échec du processus d’import du profil de sécurité « 
 »evDetData »:
{ « errors » : « SecurityProfile service error » }

Le profil de sécurité contient à la fois une liste de permissions et une autorisation d’accès à tous les services (« FullAccess » = « true »), alors qu’on ne peut déclarer que :
- une liste de permissions seule, si et seulement si « FullAccess » a pour valeur « false » ;
- « FullAccess » avec pour valeur « true », sans aucune liste de permissions.

Choisir entre ces deux options dans le profil de sécurité :
- déclarer une liste de permissions, et , de fait, « FullAccess » a pour valeur « false » ;
- autoriser tous les accès (« FullAccess » = « true »), et, de fait, ne placer aucune liste de permissions dans le profil de sécurité.

2

« outDetail »: « STP_IMPORT_SECURITY_PROFILE.KO »,
 »outMessg »: « Échec du processus d’import du profil de sécurité »
 »evDetData »: « {\n « errors » : « Au moins une permission n’existe pas. »\n} »

Le profil de sécurité importé contient au moins une permission qui n’existe pas dans le système.

Supprimer ou modifier la permission qui n’est pas reconnue lors de l’import.

6.6.5.2.2. Mise à jour d’un profil de sécurité

Message retourné par la solution logicielle Vitam

Explication

Résolution

1

outDetail »:
 »STP_UPDATE_SECURITY_PROFILE.KO »
 »outMessg »:
 »Échec du processus de mise à jour du profil de sécurité « 
 »evDetData »:
{ « errors » : « Security profile update failed > fr.gouv.vitam.common.json.JsonSchemaValidationException: Document schema validation failed : \n{« validateJson »:[{« level »: »error », »schema »:{« loadingURI »: »# », »pointer »: » »}, »instance »:{« pointer »: » »}, »domain »: »validation », »keyword »: »additionalProperties », »message »: »object instance has properties which are not allowed by the schema: ["toto"] », »unwanted »:[« toto »]}]} » }

La modification a consisté à ajouter un champ inconnu et non attendu pour décrire un profil de sécurité (dans l’exemple, il s’agit d’un champ « toto »).

Il n’est possible d’ajouter dans un profil de sécurité que des champs attendu par son modèle de données.

2

outDetail »:
 »STP_UPDATE_SECURITY_PROFILE.KO »
 »outMessg »:
 »Échec du processus de mise à jour du profil de sécurité « 
 »evDetData »:
{ « errors » : « Security profile update failed > fr.gouv.vitam.common.json.JsonSchemaValidationException: Document schema validation failed : \n{« validateJson »:[{« level »: »error », »schema »:{« loadingURI »: »# », »pointer »: » »}, »instance »:{« pointer »: » »}, »domain »: »validation », »keyword »: »anyOf », »message »: »instance failed to match at least one required schema among 2 », »nrSchemas »:2, »reports »:{« /anyOf/0 »:[{« level »: »error », »schema »:{« loadingURI »: »# », »pointer »: »/anyOf/0 »}, »instance »:{« pointer »: » »}, »domain »: »validation », »keyword »: »required », »message »: »object has missing required properties (["FullAccess","Permissions"]) », »required »:[« FullAccess », »Identifier », »Name », »Permissions », »_id », »_v »], »missing »:[« FullAccess », »Permissions »]}], »/anyOf/1 »:[{« level »: »error », »schema »:{« loadingURI »: »# », »pointer »: »/anyOf/1 »}, »instance »:{« pointer »: » »}, »domain »: »validation », »keyword »: »required », »message »: »object has missing required properties (["FullAccess"]) », »required »:[« FullAccess », »Identifier », »Name », »_id », »_v »], »missing »:[« FullAccess »]}]}}]} » }

La modification a certainement consisté à supprimer un champ obligatoire (dans l’exemple, il s’agit du champ « FullAccess » et du champ « Permissions »).

Il est interdit de supprimer un champ obligatoire.

3

outDetail »:
 »STP_UPDATE_SECURITY_PROFILE.KO »
 »outMessg »:
 »Échec du processus de mise à jour du profil de sécurité « 
 »evDetData »:
{ « errors » : « Security profile update failed > Document was not updated as there is no changes » }

La modification a porté sur un élément, une permission par exemple, déjà présent dans le profil de sécurité, et n’a en rien modifié le profil de sécurité.

4

« outDetail »: « STP_UPDATE_SECURITY_PROFILE.KO »,
 »outMessg »: « Échec du processus de mise à jour du profil de sécurité « 
 »evDetData »: « {\n « errors » : « Au moins une permission n’existe pas. »\n} »

Le profil de sécurité mis à jour contient au moins une permission qui n’existe pas dans le système.

6.6.5.3. Contrat d’entrée

6.6.5.3.1. Import d’un contrat d’entrée

Message retourné par la solution logicielle Vitam

Explication

Résolution

1

« outDetail »: « STP_IMPORT_INGEST_CONTRACT.IDENTIFIER_DUPLICATION.KO »,
 »outMessg »:
 »Échec de l’import du contrat d’entrée : l’identifiant est déjà utilisé »
 »evDetData »:
{ « Duplicate Field » : « The contract ID1 already exists in database » }

L’utilisateur a importé à deux reprises un contrat d’entrée ayant le même identifiant, sur une plate-forme où l’identifiant est géré par le front-office.

Modifier l’identifiant du second contrat d’entrée.