[RUBY] Partie 1 Exécutez e-Gov à l'aide de la bibliothèque SmartHR kiji (spécifications e-Gov)

1. 1. introduction

La bibliothèque kiji intégrée à SmartHR, un service logiciel de cloud pour le personnel et la main-d'œuvre, est un OSS créé dans Ruby, et tout le monde peut l'obtenir, le modifier et le redistribuer. SmartHR kiji

Dans cet article, nous allons essayer de générer un xml signé en utilisant la bibliothèque kiji (ci-après, kiji) et de l'envoyer au système d'application électronique e-Gov (ci-après, e-Gov) avec la commande curl. Puisque nous déplaçons e-Gov de manière interactive, nous pensons que nous pouvons comprendre en profondeur les spécifications d'e-Gov. De plus, nous définirons les problèmes d'e-Gov et envisagerons la possibilité d'une amélioration du portail mineur. Il convient de noter que l'e-Gov qui a été confirmé pour fonctionner ici est un environnement de vérification ouvert aux développeurs de logiciels.

Cette fois, nous présenterons les spécifications e-Gov comme la première des quatre fois. La deuxième fois est le matériel public e-Gov, la troisième fois est la construction de l'environnement d'exécution et la quatrième fois est la confirmation de la machine réelle.

L'environnement d'exploitation est windows10, ruby 2.6.5p114 (révision 67812 du 01/10/2019) [x64-mingw32], curl 7.58.0 (x86_64-pc-win32) libcurl / 7.58.0 WinSSL zlib / 12.11.

2. Lecteur supposé

Les lecteurs suivants sont supposés.

--Les personnes souhaitant comprendre les spécifications d'e-Gov pour développer des services logiciels

• Les personnes qui utilisent généralement une application électronique et qui souhaitent comprendre les spécifications d'e-Gov
• Les personnes souhaitant faire l'expérience de la signature XML --Les personnes qui veulent déplacer Kiji

3. 3. Qu'est-ce que l'API de liaison externe e-Gov?

L'application électronique vous permet d'effectuer des procédures administratives telles que des demandes papier et des notifications depuis votre ordinateur personnel ou professionnel via Internet. e-Gov publie les spécifications d'une API de liaison externe pour la réalisation d'applications électroniques pour diverses procédures administratives sous la juridiction de chaque ministère et agence pour les services logiciels développés par les développeurs de logiciels.

e-Gov traite les demandes de procédures selon le flux de ① à ④. Parmi celles-ci, les spécifications API pour (1) et (4) sont sujettes à publication. ① L'utilisateur envoie les données d'application créées à e-Gov et reçoit une confirmation d'arrivée. ② e-Gov envoie les données de candidature complétées au ministère compétent. ③ Le ministère responsable de la procédure examine les données de la demande et enregistre le résultat dans e-Gov. ④ L'utilisateur s'adresse à e-Gov et confirme les résultats de l'examen et les données des documents officiels.

L'API de liaison externe e-Gov peut être classée en trois grandes catégories: (1) API d'enregistrement de l'ID utilisateur, (2) API d'authentification utilisateur et (3) diverses API de traitement d'application électronique. Dans les services logiciels, vous pouvez poursuivre la procédure de candidature souhaitée en appelant ces API de liaison externes en combinaison.

L'API de liaison externe e-Gov est illustrée ci-dessous. Pour certaines API, vérifiez l'opération avec la commande curl dans la vérification de la machine réelle.

3.1 API d'enregistrement de l'ID utilisateur

L'ID utilisateur est un ID qui identifie de manière unique l'utilisateur qui crée une application électronique à l'aide du service logiciel. Dans e-Gov, l'ID utilisateur n'est enregistré qu'une seule fois pour chaque utilisateur.

Le service logiciel envoie à e-Gov le XML avec l'ID utilisateur signé avec la clé privée. e-Gov vérifie la signature XML et enregistre l'ID utilisateur et les informations d'identification du certificat de clé publique en association les uns avec les autres.

3.2 API d'authentification des utilisateurs

Dans e-Gov, l'authentification de l'utilisateur est effectuée avant d'exécuter diverses API de traitement d'application électronique.

Le service logiciel envoie le XML avec l'ID utilisateur signé avec la clé privée à e-Gov. e-Gov émettra une clé d'accès s'il n'y a pas de problème après avoir confirmé que l'ID utilisateur a été enregistré dans le système et la correspondance entre l'ID utilisateur et les informations d'identification du certificat.

Désormais, dans les services logiciels, il est nécessaire de définir la clé d'accès dans la partie d'en-tête HTTP lors de l'appel de diverses API de traitement d'application électronique. La clé d'accès a une période valide, et si la clé d'accès expire après la période de validité, l'accès à diverses API ne sera pas autorisé. Dans ce cas, vous devez à nouveau authentifier l'utilisateur et obtenir une nouvelle clé d'accès.

3.3 Diverses API de traitement électronique des demandes

Lors de l'examen d'un scénario dans lequel un utilisateur procède à une procédure de candidature électronique à l'aide d'un service logiciel, il peut être grossièrement divisé en cinq en combinant des API associées.

Tout d'abord, l'utilisateur effectue une demande d'état à partir de l'application batch. Après cela, la demande sera retirée ou modifiée si nécessaire en fonction du résultat de la demande de statut. De plus, nous allons acquérir les documents officiels et les commentaires émis au fur et à mesure de l'avancement de l'examen de la procédure. À un moment différent de ce qui précède, l'utilisateur acquiert une liste d'institutions financières qui peuvent utiliser le paiement électronique et une liste d'informations de paiement si nécessaire, et conserve les informations d'identification du certificat enregistrées dans e-Gov.

Le contenu ci-dessus est résumé.

4. Mesures de sécurité de l'information requises pour les services logiciels

Les services logiciels doivent prendre les mesures de sécurité des informations suivantes afin d'utiliser l'API de liaison externe e-Gov.

• Crypter le chemin de communication entre le service logiciel et e-Gov avec SSL / TLS
• Le service logiciel signe numériquement les données d'application et les fichiers joints envoyés par application électronique afin de confirmer l'authenticité de l'expéditeur et si les données transmises ont été altérées ou non sur e-Gov, et les met dans le format spécifié. Après l'avoir stocké, envoyez-le à e-Gov
• Dans les services logiciels, l'ID logiciel, l'ID utilisateur et la clé d'accès sont cryptés et masqués.
• Lors de l'utilisation de services logiciels, effectuez une authentification du sujet à l'aide du compte et du mot de passe de l'utilisateur
• Lors de l'enregistrement des informations d'authentification du sujet dans le service logiciel, cryptez le contenu.

Les détails sont décrits dans «Spécifications des demandes de sécurité des informations de l'API de liaison externe».

5. Interface de connexion externe e-Gov

Organisez l'interface de connexion externe e-Gov du point de vue de l'entrée et de la sortie.

Ici, après avoir organisé les données d'entrée / sortie, nous expliquerons en détail les données d'application et le xml signé.

(1) Entrée

Étant donné que le service logiciel utilise l'API de liaison externe e-Gov, il accède à l'URI de requête spécifié pour chaque API. Lors de l'accès à l'URI de la demande, spécifiez la clé d'accès et l'ID du logiciel dans l'en-tête HTTP. En outre, spécifiez l'ID d'authentification de base et le mot de passe ensemble uniquement dans l'environnement de vérification.

Lorsque vous accédez à l'URI de la requête avec la commande POST, vous pouvez demander la procédure de candidature à e-Gov en spécifiant les données de l'application, etc. dans la partie corps de la requête et en l'envoyant. Les données d'application sont la conversion de l'ensemble de données d'application dans un format qui peut être accepté par e-Gov. De plus, lors de l'accès à l'URI de la demande avec la commande GET, diverses informations peuvent être obtenues auprès d'e-Gov en spécifiant les informations requises dans le paramètre URI.

L'API d'application électronique e-Gov qui utilise la commande POST est résumée. Pour ces API, spécifiez l'une des (1) données d'application, (2) du xml signé et (3) des autres dans la partie corps de la requête.

(2) Sortie

e-Gov renvoie une réponse à une demande de service logiciel. La réponse comprend le code de réponse et le corps de la réponse (résultat de la réponse XML). Le service logiciel effectue un traitement ultérieur en fonction de la réponse de chaque API.

La balise \ du corps de la réponse (résultat de la réponse XML) de l'API officielle d'acquisition de documents ou de l'API d'acquisition de commentaires contient des données obtenues en codant un fichier au format Zip au format Base64. Il s'agit d'un document officiel ou d'une notification de commentaire émise par le ministère de la procédure compétent, et il est nécessaire que le service logiciel le décode au format Base64, décompresse le fichier au format Zip et fournisse un moyen de le montrer à l'utilisateur.

5.1 Ensemble de données d'application et données d'application

L '"ensemble de données d'application" est un ensemble de données composé de XML de gestion de configuration, de formulaire de demande XML et de fichiers joints, et est utilisé pour une application par lots, une demande de retrait et une demande de modification.

Dans le service logiciel, e-Gov signe le XML de gestion de configuration afin de confirmer l'authenticité de l'expéditeur et si les données transmises ont été falsifiées ou non. En outre, l'ensemble de données d'application contenant le XML de gestion de la configuration signé (xml signé) est converti en fichier zip et encodé au format Base64.

"Données d'application" est le résultat de l'encodage du fichier zip au format Base64 et stocké dans la balise \ de XML, qui est un format qu'e-Gov peut accepter. Le format des données d'application est défini pour chaque API. Les détails sont décrits dans "Spécifications de l'API de liaison externe du système d'application électronique e-Gov (version 1)".

Ensuite, nous expliquerons le XML de gestion de la configuration, le XML du formulaire de candidature et les fichiers joints.

(1) Gestion de la configuration XML

En tant qu'unité logique qui stocke les informations d'attribut de l'ensemble des données d'application, les informations d'application qui ne sont pas incluses dans le XML d'application et la relation entre les unités logiques de l'ensemble des données sont gérées.

Le fichier physique d'informations de gestion de configuration est appelé «XML de gestion de configuration», et à l'exception des demandes de retrait, il est toujours inclus dans l'ensemble de données d'application.

La structure du XML de gestion de la configuration est définie pour chaque application d'application par lots, demande de retrait, demande de retrait et modification. De plus, dans le format de signature de fichier individuel décrit plus loin, la structure de balise des informations de configuration est définie pour le XML de gestion de la configuration pour le formulaire de demande XML, le XML de gestion de la configuration pour la modification et le XML de gestion de la configuration pour les documents joints.

(2) Formulaire de demande XML

Il s'agit d'un formulaire pour remplir les éléments de demande / notification dans chaque procédure administrative. Dans e-Gov, le format XML qui stocke les éléments de demande / notification est appelé «formulaire de demande», et son fichier physique est appelé «formulaire de demande XML».

(3) Fichier joint

Il s'agit d'un document joint qui doit être soumis avec le formulaire de candidature en fonction des éléments de candidature / notification dans chaque procédure administrative. Dans e-Gov, les autres documents qui ne sont pas stockés dans le formulaire de candidature sont appelés «documents joints» et leurs fichiers physiques sont appelés «fichiers joints».

5.2 À propos du XML signé

Dans e-Gov, le certificat électronique (clé publique) utilisé pour chaque ID utilisateur est utilisé pour chaque ID utilisateur afin de confirmer l'identité et de détecter si le document a été falsifié sur la base de l'infrastructure à clé publique (PKI). Il est géré en l'associant à l'ID. Par conséquent, dans le service logiciel, il est nécessaire de créer un xml signé pour les données d'application à l'aide de la clé privée correspondant au certificat numérique géré pour chaque ID utilisateur.

Un xml signé est un fichier xml avec des informations de signature électronique ajoutées. Pour les signatures xml, la recommandation du W3C (https://www.w3.org/TR/xmldsig-core/) spécifie la syntaxe XML pour les signatures numériques.

Les informations de signature électronique sont (1) des informations sur l'algorithme utilisé pour le calcul de la valeur de signature et le calcul du condensé, (2) la valeur de hachage pour confirmer la falsification du document, (3) la signature électronique pour la valeur de hachage, et (4) le certificat électronique (clé publique). Le format des informations de signature électronique est le suivant.

La description de chaque élément de balise de signe xml est réimprimée à partir de Wiki. e-Gov suit également ce contenu.

--L'élément SignedInfo spécifie ce qu'il faut signer et l'algorithme à utiliser. Les éléments SignatureMethod et CanonicalizationMethod sont utilisés par l'élément SignatureValue et sont inclus dans SignedInfo pour les protéger contre la falsification.

• La liste des éléments de référence spécifie la ressource à signer par URI. Le résultat de l'application de l'algorithme digest (hash) (dans l'élément DigestMethod) à la ressource avec toutes les transformations appliquées à la ressource avant de calculer le hachage dans l'élément Transforms (qui est encodé en Base64 dans l'élément DigestValue). Spécifier. --L'élément SignatureValue est la valeur encodée en Base64 de la signature. Cette valeur est la signature (générée par la spécification SignatureMethod) après la sérialisation de l'élément SignedInfo par l'algorithme spécifié par l'élément CanonicalizationMethod. (Voir la section Normalisation XML pour plus d'informations sur la normalisation)
• L'élément KeyInfo est un élément facultatif qui permet au destinataire de la signature d'obtenir la clé nécessaire pour vérifier la signature. En règle générale, vous pouvez insérer une série de certificats X.509. Si elle n'existe pas, le destinataire doit identifier la clé à partir du contenu des données.

Il existe deux types de xml signé e-Gov: le xml signé inclus dans l'ensemble de données d'application et le xml signé spécifié directement dans la partie du corps HTTP. Le premier est utilisé pour l'API d'application par lots, etc., et le dernier est utilisé pour l'API d'enregistrement / d'authentification des utilisateurs, etc.

5.2.1 XML signé inclus dans l'ensemble de données d'application

Lors de l'attribution d'une signature au XML de gestion de la configuration inclus dans l'ensemble de données d'application, (1) «format standard» qui attribue une signature à l'ensemble des données d'application, et (2) «format de signature de fichier individuel» qui attribue une signature à chaque formulaire de demande et fichier joint. Il existe deux types.

Le format des informations de signature électronique est décrit dans "e-Gov Electronic Application System External Linkage API Application Data Specification Common Data Specification".

(1) Format standard

Les données d'application au format standard sont un ensemble de données composé des trois fichiers suivants.

• XML de gestion de la configuration (y compris les informations de signature)
• XML d'application
• Document attaché

Ces fichiers ont les relations suivantes:

Dans le service logiciel, les données d'application sont créées par signature selon la procédure suivante. (1) Calcul de la valeur de hachage à partir des informations de gestion de configuration du XML de gestion de configuration ② Calculez la valeur de hachage à partir du XML de l'application ③ Calculez la valeur de hachage à partir des documents joints ④ Signez toute la valeur de hachage avec la clé privée ⑤ Donner les informations de certificat (clé publique) correspondant à la clé privée ⑥ Consolidez l'ensemble de données au format zip et encodez-le au format Base64 ⑦ Stocker dans les données d'application

À partir des données de candidature reçues, e-Gov vérifiera l'identité et si les données ont été falsifiées ou non par la procédure suivante. (1) Extraire le résultat de l'encodage au format Base64 de l'ensemble de données à partir des données d'application (2) Décoder au format Base64 et convertir en ensemble de données au format zip ③ Décompressez le zip et obtenez le XML de gestion de la configuration (4) Comparez le certificat de gestion de configuration XML avec le certificat géré par e-Gov pour confirmer l'authenticité de l'expéditeur. ⑤ Décryptez la valeur de signature avec le certificat (clé publique) et extrayez la valeur de hachage ⑤ Calculez les valeurs de hachage pour le XML de gestion de la configuration, le XML d'application et les fichiers joints. ⑥ Comparez les valeurs de hachage et si elles correspondent, déterminez qu'il n'y a pas de falsification des données.

Les procédures d'application pour le format standard sont les suivantes.

• Notification de qualification d'assurance-emploi / demande électronique
• Notification de perte du statut d'assuré à l'assurance-emploi (aucun bulletin de chiffre d'affaires émis) / Demande électronique
• Notification du changement de nom de l'assuré de l'assurance-emploi / demande électronique --Divers avis de changement / demandes électroniques pour les établissements d'assurance-emploi
• Relation d'assurance établie (suite) / Demande électronique --Avis de création d'entreprise d'assurance-emploi / application électronique
• Notification de qualification assurée par assurance maladie / rente sociale, assurance des gens de mer / assurance rente sociale notification de qualification assurée / demande électronique
• Notification de changement (correction) de nom de l'assuré d'assurance maladie / pension sociale, notification de correction de changement de nom assuré / demande électronique --Notification de changement (correction) lié à l'assurance maladie / établissement d'assurance de rente sociale / demande électronique --Notification de la nouvelle application de l'assurance maladie / rente sociale, notification de la nouvelle demande de l'assurance des gens de mer / assurance rente sociale / demande électronique --Notification du changement (correction) du lieu du nom de l'établissement commercial couvert par l'assurance maladie / assurance de rente sociale (dans la juridiction) (hors juridiction), notification du changement de nom (nom) adresse (emplacement) du propriétaire du navire de l'assurance des gens de mer / assurance de rente sociale (dans la juridiction) ( Hors juridiction) / Demande électronique

(2) Format de signature de fichier individuel

Les données d'application dans le format de signature de fichier individuel sont un ensemble de données composé des 5 fichiers suivants.

• XML de gestion de configuration
• XML d'application
• Informations de configuration XML pour le formulaire de candidature
• Document attaché
• Informations de configuration XML pour les documents joints

Ces fichiers ont les relations suivantes:

La valeur de hachage calculée à partir du formulaire de candidature XML est signée et la valeur de signature est ajoutée aux informations de configuration XML du formulaire de candidature. En outre, la valeur de hachage calculée à partir du document joint est signée et la valeur de signature est ajoutée aux informations de configuration XML pour le document joint. Contrairement au format standard, il n'y a pas de valeur de signature dans le XML de gestion de la configuration.

Dans le service logiciel, les données d'application sont créées par signature selon la procédure suivante.

(1) Calcul de la valeur de hachage à partir des informations de gestion de configuration des informations de configuration XML pour le formulaire de candidature ② Calculez la valeur de hachage à partir du XML de l'application ③ Créez une valeur de signature avec une clé privée à partir de chaque valeur de hachage ④ Donner les informations de certificat (clé publique) correspondant à la clé privée ⑤ Informations de configuration pour les documents joints Calculez la valeur de hachage à partir des informations de gestion de configuration de XML ⑥ Calculez la valeur de hachage à partir du fichier joint ⑦ Créez une valeur de signature avec une clé privée à partir de chaque valeur de hachage ⑧ Donner les informations de certificat (clé publique) correspondant à la clé privée ⑨ Consolidez l'ensemble de données au format zip et encodez-le au format Base64 ⑩ Stocker dans les données d'application

e-Gov vérifie la vérification d'identité et la présence ou l'absence de falsification de données à partir des données d'application reçues dans la procédure inverse.

La procédure d'application pour le format de signature de fichier individuel est la suivante. Le "type d'écriture continue" est un format qui peut décrire plusieurs noms.

• Relation d'assurance établie (suite) / Demande électronique --Notification de la qualification d'assurance-emploi (type sérialisé) / demande électronique
• Notification de perte du statut d'assuré à l'assurance-emploi (sérialisé) / demande électronique
• Notification de perte du statut d'assuré à l'assurance-emploi (avec bulletin de chiffre d'affaires émis) / Demande électronique --Autorisation / application électronique avec sous-traitant en tant que propriétaire d'entreprise --Demande de délivrance d'un bulletin de chiffre d'affaires après soumission de l'avis de disqualification de l'assurance-emploi / demande électronique --Demande de prestations de maintien de l'emploi vieillesse de l'assurance-emploi (prestation de base de maintien de l'emploi de vieillesse) / demande électronique
• Assurance maladie / assurance de rente sociale Notification de base de l'indemnisation mensuelle assurée (méthode de pièce jointe CSV) / Demande électronique
• Acquisition de la qualification d'assuré national de pension, changement de type, notification de confirmation de type (correspondant à l'assuré n ° 3) / demande électronique

5.2.2 XML signé spécifié directement dans la partie du corps HTTP

Pour les API liées à l'enregistrement de l'ID utilisateur, à l'authentification de l'utilisateur et à l'ajout / la mise à jour / la suppression des informations d'identification du certificat, spécifiez directement le xml signé dans la partie du corps HTTP.

Le format des informations de signature électronique est décrit dans "Spécifications de l'API de liaison externe du système d'application électronique e-Gov (version 1)".

Ces fichiers XML signés ont en commun de calculer la valeur de hachage pour la balise \ entière et de signer cette valeur de hachage. Suivez la procédure ci-dessous pour ajouter des informations de signature. ① Calculez la valeur de hachage pour la balise \ entière ② Signez la valeur de hachage avec la clé privée ⑤ Donner les informations de certificat (clé publique) correspondant à la clé privée

Pour l'enregistrement de l'ID utilisateur et l'authentification de l'utilisateur, ne spécifiez pas le certificat de clé publique dans la balise \ .

6. À propos de la transition d'état du traitement électronique des demandes

Dans e-Gov, l'état est géré en le divisant en un état principal et un sous-état en fonction de la progression du traitement des demandes.

6.1 État principal

Pour chaque procédure, l'état change dans l'ordre de (traitement) → (atteint) → (en cours de révision) → (révision terminée) → (procédure terminée) en fonction de l'avancement.

Chaque état a les significations suivantes:

--e-Gov effectue diverses vérifications sur les données de l'application. Diverses vérifications sont la vérification de la configuration des fichiers, la vérification du schéma XML, la vérification de la cohérence et la vérification du format. S'il n'y a pas de problème, il passera de (en cours) à (atteint). ――Lorsque l'examen du ministère commence, il passera de (atteint) à (en cours d'examen). ――Lorsque l'examen du ministère est terminé, il passera de (en cours d'examen) à (fin de l'examen).

• Après avoir acquis le document officiel avec le service logiciel, si vous informez e-Gov de l'achèvement de l'acquisition du document officiel, il passera de (examen terminé) à (procédure terminée).

6.2 Sous-état

(1) Ramasser

Lorsque le logiciel demande à e-Gov de retirer la procédure en (atteint) ou (en cours de révision), le sous-état passe de (aucun) à (en cours de révision), et enfin l'état principal (procédure terminée) + sous-état. (Retiré).

(2) Correction

Si une instruction de modification est émise aux données de la demande par le ministère ayant compétence sur la procédure pendant (en cours d'examen), le (sous-état) passera de (aucun) à (en attente du traitement de la modification). En fonction du contenu de l'instruction de correction, le service logiciel doit isoler la séquence suivante comme suit:

Si le type de modification est "resoumettre" et que le service logiciel demande un amendement (nouvelle soumission), il s'agira de l'état principal (procédure terminée) + sous-état (resoumis). Lorsque le type de correction est «correction partielle», lorsque le service logiciel demande une correction (correction partielle), il devient un sous-état (aucun).

Ce qui précède est exprimé dans le diagramme de transition d'état.