En cours de rédaction · Le projet de travail nécessite un manifeste de libération

Manuel technique

Configuration des intégrations

Règles relatives aux identités, à l'EIS, à l'eSSL, aux services de documents et aux autres connecteurs.

Public: Analyste d'intégration, implémenteur, gestionnaire d'identité, fournisseur de systèmes cibles
Résultat: Chaque liaison possède un propriétaire, un contrat, un modèle de sécurité et un chemin d'erreur résoluble.

Le contrat de chaque obligation

source et destination, propriétaire des deux parties et système d'archivage
Version de l'API et compatibilité prise en charge
Orientation du réseau, DNS, TLS et autorités de certification autorisées
authentification du service technique et transfert de l'identité de l'utilisateur réel
Protection contre les délais d'expiration, les nouvelles tentatives, le repli, l'idempotence et la duplication
Identifiant de corrélation, contact d'audit, de surveillance et d'escalade
classification, minimisation, rétention et masquage des données

L'authentification unique (SSO) via OpenID Connect ou SAML 2.0 configure la confiance avec le fournisseur d'identité (IdP)/Keycloak en fonction de l'environnement spécifique.
Une conception prise en charge peut utiliser Microsoft Entra ID, Shibboleth, CAS (Jasig / Apereo), LDAP, NIA ou CAAIS ; la version exacte du protocole, les revendications et le cycle de vie du compte font partie du profil d'intégration.
Un groupe issu d'une identité ne correspond pas automatiquement à un rôle de processus ; le mappage doit être contrôlé et testé.
L'authentification multifacteur (MFA) ou les clés d'accès sont appliquées dans une architecture d'identité prise en charge.
Les comptes techniques disposent de droits minimaux, de secrets renouvelés régulièrement et d'un audit séparé.
La suppression d'un utilisateur et la modification d'un rôle s'authentifient de la même manière que la connexion.

Le dossier, les tâches, les approbations et les motifs de retour sont enregistrés par OOD/SIFYBOX ; le document comptable, le numéro de compte et le statut de comptabilisation officiel sont enregistrés par le système économique.
Le comptable interne peut intervenir directement dans le processus. Le comptable externe peut intégrer les documents approuvés à son système. Le connecteur ne peut créer un document que dans la mesure permise par l'interface spécifique.
SIFYBOX ne conserve que le statut effectivement renvoyé par le système économique : envoyé, techniquement reçu, document créé ou publié. Ces statuts ne sont pas cumulés.
Le budget disponible fait foi dans le système financier lorsque celui-ci fournit l’information ; FS conserve l’instantané déterminant du contrôle. Les allocations ou réservations locales ne font foi dans FS que si le contrat d’intégration le précise explicitement.
Les fournisseurs et les données comptables proviennent d'un système maître désigné ; SIFYBOX détient une copie contrôlée et un identifiant de source.
La nouvelle soumission utilise la même clé d'idempotence. En cas de délai d'attente dépassé et de résultat incertain, une réconciliation est effectuée, et non la création automatique d'un nouveau document.
L'erreur créera une tâche pour un solveur spécifique et ne restera pas uniquement consignée dans le journal technique.

Cette application ne remplace pas un certificat eSSL.
Il transmet le composant, les métadonnées et les identifiants uniques via une interface confirmée selon NSeSSS.
Il enregistre les données d'inscription et le statut renvoyés afin que l'utilisateur n'écrase rien.
La propriété du fichier, les règles d'élimination et le document faisant autorité sont déterminés avant la mise en œuvre.
Les certificats eSSL et leurs versions spécifiques pris en charge sont inclus dans la matrice d'intégration des versions.

Guide suivant