Cadre d`interopérabilité technique des services AMC

Cadre
d’interopérabilité
technique
des services AMC
Version
Date
Référence
1.2
13/12/2016
CI_SEL_AMC
GIE SESAM-VITALE, maître d’œuvre et expert technique du système
5, boulevard Alexandre Oyon – 72 019 LE MANS Cedex 2
www.sesam-vitale.fr
Cadre d’interopérabilité technique des services AMC
Ce document a été élaboré par le GIE SESAM-Vitale.
Conformément à l’article L.122-4 du Code de la Propriété Intellectuelle,
toute représentation ou reproduction (intégrale ou partielle) du présent
ouvrage, quel que soit le support utilisé, doit être soumise à l’accord préalable écrit de son auteur.
Il en est de même pour sa traduction, sa transformation, son adaptation ou
son arrangement, quel que soit le procédé utilisé.
Tout manquement à ces obligations constituerait un délit de contrefaçon,
au sens des articles L 335-2 et suivants du code de la propriété intellectuelle, susceptible d’entraîner des sanctions pour l’auteur du délit.
13/12/2016
GIE SESAM-Vitale
2 / 40
Ce document à diffusion restreinte ne peut être diffusé sans l'autorisation d'une personne habilitée
au GIE SESAM-Vitale
Cadre d’interopérabilité technique des services AMC
Historique des versions
Date
Version
30 sept. 2016 1.0
Évolution du document
Première version du document
15 nov. 16
1.1
Mise à jour de la norme 1779 de représentation du DN (X509) par la norme 2253.
(https://2rfc.net/2253)
13 dec. 16
1.2
Ajout de la structure XML <Erreur2>. Cette
structure est l’évolution de la structure XML
<Erreur> portée par l’erreur SOAP. Elle est
enrichie d'un contact AMC.
13/12/2016
GIE SESAM-Vitale
3 / 40
Ce document à diffusion restreinte ne peut être diffusé sans l'autorisation d'une personne habilitée
au GIE SESAM-Vitale
Cadre d’interopérabilité technique des services AMC
Tables des matières
Historique des versions ........................................................................... 3
Tables des matières ................................................................................. 4
Glossaire ................................................................................................. 5
Chapitre 1
Introduction....................................................................... 6
1.1
Objet du document ....................................................................6
1.2
Contenu du document ................................................................6
1.3
Périmètre de l’interopérabilité ...................................................7
Chapitre 2
Spécifications .................................................................... 9
2.1
Référentiels externes .................................................................9
2.2
Principales normes utilisées ......................................................9
2.3
Quelques concepts communs ..................................................11
Chapitre 3
Sécurité d’accès .............................................................. 14
3.1
Principe général .......................................................................14
3.2
Authentification directe d’une personne physique ..................16
3.3
Authentification par délégation d’une personne physique ......17
3.4
Authentification directe d’une personne morale .....................18
3.5
Assertion SAML......................................................................19
Chapitre 4
4.1
Les échanges ................................................................... 25
Les requêtes SOAP ..................................................................27
4.1.1 Header SOAP ......................................................................28
4.1.2 Body SOAP.........................................................................31
4.2
Les réponses SOAP .................................................................31
4.3
Les erreurs SOAP ....................................................................32
Chapitre 5
Le document métier ........................................................ 36
5.1
Structure ..................................................................................36
5.2
La signature des documents métier .........................................37
13/12/2016
GIE SESAM-Vitale
4 / 40
Ce document à diffusion restreinte ne peut être diffusé sans l'autorisation d'une personne habilitée
au GIE SESAM-Vitale
Cadre d’interopérabilité technique des services AMC
Glossaire
AMC
AMO
CNDA
CPx
ES
LPS
OTP
PS
RGI
RGS
SAAS
SAML
SIH
SI-PS
SOA
SOAP
TLS
URN
UTC
UUID
WSDL
Assurance Maladie Complémentaire
Assurance Maladie Obligatoire
Centre National d’Agrément
Carte du Professionnel de Santé de l’ASIP Santé
Établissement de santé
Progiciel du Professionnel de Santé
Opérateur de Tiers Payant
Professionnel de Santé
Référentiel Général d’Interopérabilité
Référentiel Général de Sécurité
Software as a Service
Security assertion markup language
Système d’information Hospitalier
Système d’information du PS
Service Oriented Architecture
Simple Object Access Protocol
Transport Layer Security
Uniform Resource Name
Coordinated Universal Time
Universally Unique IDentifier
Web Services Description Language
13/12/2016
GIE SESAM-Vitale
5 / 40
Ce document à diffusion restreinte ne peut être diffusé sans l'autorisation d'une personne habilitée
au GIE SESAM-Vitale
Cadre d’interopérabilité technique des services AMC
Chapitre 1
Introduction
1.1 Objet du document
Ce document décrit les aspects techniques et sécuritaires à mettre en
œuvre lors de l’interrogation des web-services offerts par les Assurances Maladies Complémentaires (AMC).
1.2 Contenu du document
Le cadre d’interopérabilité technique fixe les questions relatives aux
protocoles d’échanges de données et à la sécurité des appels.
Outre cette introduction, le document comporte les chapitres suivants :
−
−
−
−
Le chapitre 2 présente les normes utilisées.
Le chapitre 3 décrit les schémas de sécurité.
Le chapitre 4 spécifie les échanges.
Le chapitre 5 décrit les éléments techniques des documents métier.
13/12/2016
GIE SESAM-Vitale
6 / 40
Ce document à diffusion restreinte ne peut être diffusé sans l'autorisation d'une personne habilitée
au GIE SESAM-Vitale
Cadre d’interopérabilité technique des services AMC
1.3 Périmètre de l’interopérabilité
Ce document traite des questions d’interopérabilité dans les différents
cas illustrés dans la figure 1 ci-dessous.
Le terme système d’information du PS (SI-PS) définit le moyen technique utilisé par le Professionnel de Santé (PS) pour se connecter. Cela
peut être un Logiciel du Professionnel de Santé (LPS), un Système
d’Information Hospitalier (SIH), ou un système d’information opéré
par un éditeur.
Le terme système cible définit une organisation AMC au sens large.
Cela peut être une AMC, un Opérateur de Tiers Payant (OTP), ou un
frontal regroupant plusieurs AMC.
Figure 1 – Périmètre du cadre d’interopérabilité
13/12/2016
GIE SESAM-Vitale
7 / 40
Ce document à diffusion restreinte ne peut être diffusé sans l'autorisation d'une personne habilitée
au GIE SESAM-Vitale
Cadre d’interopérabilité technique des services AMC
Trois principaux cas d’usage sont donc identifiés.
(a) Le cadre d’interopérabilité technique s’applique aux échanges
entre un LPS d’un PS et un système cible. Le PS utilise sa Carte
du Professionnel de Santé de l’ASIP Santé (CPx) pour
s’authentifier directement auprès du système cible. Le poste de
travail dispose d’un dispositif de lecture de CPx.
(b) Le cadre d’interopérabilité technique s’applique aux échanges
entre un système d’information d’un éditeur (en mode Saas) et
un système cible. Le PS utilise un LPS pris en charge par un système d’information d’un éditeur qui s’authentifie auprès du système cible au moyen d’un certificat logiciel d’authentification
pour personne morale. Cependant, l’accès au système cible nécessite que chaque PS soit identifié nominativement ; il est donc
indispensable que le système d’information de l’éditeur mette en
œuvre par délégation une politique d’authentification cohérente
avec celle du système cible et qu’il soit en mesure de fournir
l’identifiant du PS à l’origine des transactions.
(c) Le cadre d’interopérabilité technique s’applique aux échanges
entre une personne morale (un établissement hospitalier, une
structure de soins, un centre de santé…) et un système cible.
L’utilisateur (agents, PS...) sous la responsabilité de la personne
morale, sollicite un service en utilisant le système d’information
de la structure. C’est cette structure qui s’authentifie auprès du
système cible au moyen d’un certificat logiciel
d’authentification pour personne morale. Les autorisations
d’accès sont liées uniquement aux caractéristiques de la structure.
13/12/2016
GIE SESAM-Vitale
8 / 40
Ce document à diffusion restreinte ne peut être diffusé sans l'autorisation d'une personne habilitée
au GIE SESAM-Vitale
Cadre d’interopérabilité technique des services AMC
Chapitre 2
Spécifications
2.1 Référentiels externes
Les technologies utilisées ici sont compatibles avec ceux du cadre
d’interopérabilité des SIS de l’ASIP Santé 1 et ceux des télé-services de
l’Assurance Maladie Obligatoire (AMO).
Le cadre d’interopérabilité technique des AMC est également cohérent
avec le Référentiel Général d’Interopérabilité (RGI) 2.0 (Profil P2)
promu par l’État français 2.
2.2 Principales normes utilisées
Le choix de la pile de protocoles du cadre d’interopérabilité technique
est basé sur les spécifications du Basic Profile Version 2.0 3.
TLS 1.x est un protocole de sécurisation des échanges sur Internet.
Le protocole Transport Layer Security (TLS) permet de satisfaire aux objectifs de sécurité suivants :
–
–
–
–
l’authentification du serveur ;
la confidentialité des données échangées (ou session
chiffrée) ;
l’intégrité des données échangées ;
de manière optionnelle, l’authentification du client.
La version 1.2 ou ultérieure doit être retenue pour ce standard.
(conforme au Référentiel Général de Sécurité (RGS)).
https://fr.wikipedia.org/wiki/Transport_Layer_Security
1
http://esante.gouv.fr/services/referentiels/ci-sis
http://references.modernisation.gouv.fr/sites/default/files/
3
http://ws-i.org/profiles/BasicProfile-2.0-2010-11-09.html
2
13/12/2016
GIE SESAM-Vitale
9 / 40
Ce document à diffusion restreinte ne peut être diffusé sans l'autorisation d'une personne habilitée
au GIE SESAM-Vitale
Cadre d’interopérabilité technique des services AMC
HTTP 1.1 est un protocole de communication client-serveur développé pour le web. La version 1.1 actualisée en 2014 est recommandée. La version sécurisée HTTPS doit être utilisée.
https://fr.wikipedia.org/wiki/Hypertext_Transfer_Protocol
XML ou « langage de balisage extensible » est un langage informatique de balisage générique. Cette syntaxe est dite « extensible », car elle permet de définir différents espaces de noms,
c’est-à-dire des langages avec chacun leur vocabulaire et leur
grammaire, comme XHTML, XSLT, RSS, SVG... Elle est reconnaissable par son usage des chevrons (< >) encadrant les balises XML. L’objectif initial est de faciliter l’échange automatisé
de contenus complexes (arbres, texte riche...) entre systèmes informatiques hétérogènes (interopérabilité).
http://www.w3.org/TR/REC-xml
SOAP 1.2 Simple Object Access Protocol (SOAP) spécifie le format des messages ainsi que les informations sur le message luimême permettant son acheminement et son traitement.
http://www.w3.org/standards/techs/soap
SAML 2.0 est un protocole pour échanger des informations
d’authentification et d’autorisation entre des parties, en particulier entre un fournisseur d’identité et un fournisseur de service.
Basé sur le langage XML. SAML propose l’authentification
unique (en anglais single sign-on ou SSO) sur le web. De cette
manière, un utilisateur peut naviguer sur plusieurs sites différents en ne s’authentifiant qu’une seule fois.
https://fr.wikipedia.org/wiki/Security_assertion_markup_language
XML Signature (aussi nommé XMLDsig, XML-DSig, XML-Sig)
est une recommandation du W3C destinée à permettre
l’utilisation de signatures numériques dans les documents XML.
Tout comme les techniques générales de cryptographie à clef
publique qu’elle met en œuvre, elle permet d’assurer
l’authentification, l’intégrité et par voie de conséquence la nonrépudiation des données signées, mais en tirant profit de la souplesse offerte par le langage XML.
http://www.w3.org/TR/2008/REC-xmldsig-core-20080610
13/12/2016
GIE SESAM-Vitale
10 / 40
Ce document à diffusion restreinte ne peut être diffusé sans l'autorisation d'une personne habilitée
au GIE SESAM-Vitale
Cadre d’interopérabilité technique des services AMC
XSD ou XML Schema est un langage de description de format de
document XML permettant de définir la structure et le type de
contenu d’un document XML. Cette définition permet notamment de vérifier la validité de ce document.
http://www.w3.org/XML/Schema
WSDL est une grammaire XML permettant une interface d’accès à
un web-service. Cette description est fondée sur le XML qui indique « comment communiquer pour utiliser le service ».
http://www.w3.org/TR/wsdl20/
http://schemas.xmlsoap.org/wsdl/soap12/WSDL11SOAP12.pdf
2.3 Quelques concepts communs
UUID L’algorithme Universally Unique IDentifier (UUID) permet
à des systèmes distribués d’attribuer de façon unique un identifiant à des informations sans coordination centrale. On parle
d’identifiants « différents avec une haute probabilité ». Un
UUID se présente habituellement sous sa forme canonique,
c’est-à-dire composée de groupes de caractères hexadécimaux
en minuscules séparés par des tirets.
Par exemple : 110e8400-e29b-11d4-a716-446655440000
C’est-à-dire 8-4-4-4-12 pour un total de 36 caractères (32 alpha
numériques caractères et 4 « - »).
https://en.wikipedia.org/wiki/Universally_unique_identifier
13/12/2016
GIE SESAM-Vitale
11 / 40
Ce document à diffusion restreinte ne peut être diffusé sans l'autorisation d'une personne habilitée
au GIE SESAM-Vitale
Cadre d’interopérabilité technique des services AMC
URN Le terme Uniform Resource Name (URN) traduit littéralement de l’anglais par « nom uniforme de ressource » permet de
désigner une ressource de manière unique. Les URN ont la syntaxe suivante : urn:NID:NSS
–
–
–
urn est la méthode d’URI des URN.
NID (Namespace Identifier) est un identificateur
d’espace de noms.
NSS (Namespace specific String) est la partie spécifique
à l’espace de noms identifié par le NID. L’interprétation
syntaxique de cette partie dépend de l’espace de noms.
Par exemple : urn:isbn:0451450523
https://en.wikipedia.org/wiki/Uniform_Resource_Name
http://www.yoyodesign.org/doc/w3c/uri-clarification/
https://tools.ietf.org/html/rfc2141
Date et heure Le format date et heure choisi est celui défini par
XML (xs:dateTime). Elle est de type YYYY-MM-DDThh:mm:ss+/-hh:mm
avec +hh:mm/-hh:mm est le décalage par rapport à l’heure UTC. En
l’absence de consigne spécifique, l’heure est exprimée en heure
locale avec décalage horaire UTC.
Par exemple : 2016-06-12T10:15:30+04:00
Dans certains cas, l’heure peut être demandée en UTC. Son
format est du type YYYY-MM-DDThh:mm:ssZ. On inscrit littéralement
un Z final lorsqu’il s’agit de l’heure UTC.
Par exemple : 2016-06-22T06:00:00Z
Quel que soit le cas, le LPS doit synchroniser son heure pour des
problématiques d’horodatage des données, de traçabilité et de
sécurité. Le LPS peut par exemple utiliser le pool de serveurs de
temps français fr.pool.ntp.org.
http://www.w3.org/TR/xmlschema-2/#dateTime
13/12/2016
GIE SESAM-Vitale
12 / 40
Ce document à diffusion restreinte ne peut être diffusé sans l'autorisation d'une personne habilitée
au GIE SESAM-Vitale
Cadre d’interopérabilité technique des services AMC
Date Le format de date choisi est celui défini par XML (xs:date)
sans décalage horaire.
Par exemple : 2016-06-22
http://www.w3.org/TR/xmlschema-2/#date
ID Dans le langage XML les identifiants ID (unique identifiers)
sont des xs:NCName ayant pour contraint d’être unique dans le document XML. La valeur doit se composer exclusivement de
lettres, de chiffres, de traits d’union et de points. Les chiffres, le
trait d’union et le point ne peuvent être utilisés en premier.
Espace de nommage Tous les services d’un domaine sont regroupés sous un même espace de nommage (namespace).
Par exemple : xmlns="urn:amc:med".
Tous les éléments XML inter domaine, tel que les en-têtes XML
du cadre d’interopérabilité (chap. 4.1) sont dans l’espace de
nommage xmlns="urn:amc:ci".
Version de service Un élément XML n’est jamais modifié. En cas
d’évolution, un nouvel élément XML est créé. Par exemple, si la
définition fonctionnelle d’une adresse postale doit être modifiée,
la structure XML initiale <adresse> est conservée et une nouvelle structure XML <adresse2> est créée. Les deux structures
cohabitent dans le nouveau schéma XSD sans modification de
l’espace de nommage.
De la même manière, en cas d’évolution fonctionnelle, le service
initial est conservé et un nouveau service est systématiquement
créé garantissant la compatibilité des schémas XSD.
13/12/2016
GIE SESAM-Vitale
13 / 40
Ce document à diffusion restreinte ne peut être diffusé sans l'autorisation d'une personne habilitée
au GIE SESAM-Vitale
Cadre d’interopérabilité technique des services AMC
Chapitre 3
Sécurité d’accès
3.1 Principe général
Figure 2 – Sécurité
(a) La sécurisation des échanges repose sur l’établissement d’une liaison réseau TLS 1.2 avec authentification du système cible. Le protocole TLS assure la confidentialité et l’intégrité des données échangées.
− La cipher suite
utilisée.
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA256
doit être
(b) Chaque système cible possède un certificat serveur X.509 issue
d’une autorité de certification du GIE SESAM-Vitale. Le SI-PS doit le
valider pour s’assurer de communiquer avec un système cible AMC.
− Le SI-PS doit vérifier la signature du certificat du service cible,
sa parenté (l’autorité) et les dates de début et de fin de validité.
− Il est recommandé que le SI-PS effectue un contrôle de révocation du certificat du système cible.
− Les certificats du système cible et de l’autorité de certification
(AC) ont une durée de vie limitée. Il faut donc prévoir leurs renouvellements. Pour faciliter cette opération, le SI-PS doit savoir gérer (par configuration) au moins deux certificats
d’autorités du certificat serveur du système cible : une autorité
en fin de vie et la nouvelle.
13/12/2016
GIE SESAM-Vitale
14 / 40
Ce document à diffusion restreinte ne peut être diffusé sans l'autorisation d'une personne habilitée
au GIE SESAM-Vitale
Cadre d’interopérabilité technique des services AMC
(c) Le client SI-PS (LPS, SI, Éditeur) génère et transmet une assertion
SAML 2.0. C’est un document XML signé par le certificat X.509 de
l’ASIP Santé.
− Le système cible doit vérifier la signature de l’assertion SAML
ce qui lui apporte la preuve de la possession d’un moyen
d’authentification fourni par l’ASIP Santé (ou une autorité de
certification autorisée par les AMC), et identifie de manière certaine le client.
− Le système cible doit valider le certificat présenté par le client :
vérification de sa parenté (l’autorité) et des dates de début et de
fin de validité.
− Le système cible doit effectuer un contrôle de révocation du certificat du client.
Lorsque le système cible et le client se sont authentifiés mutuellement,
les contrôles d’autorisation sont réalisés.
13/12/2016
GIE SESAM-Vitale
15 / 40
Ce document à diffusion restreinte ne peut être diffusé sans l'autorisation d'une personne habilitée
au GIE SESAM-Vitale
Cadre d’interopérabilité technique des services AMC
3.2 Authentification directe
d’une personne physique
Un PS (personne physique) sollicite directement le système cible sous
sa propre responsabilité en utilisant son LPS et sa carte CPx.
Le LPS génère l’assertion SAML, puis la signe à l’aide de la CPx et
enfin l’ajoute dans toutes ses requêtes vers le système cible.
Pour signer avec la CPx, le logiciel peut utiliser la cryptolib de l’ASIP
Santé (http://integrateurs-cps.asipsante.fr/).
L’assertion SAML est valable 1 heure pour tous les web-services. Tant
que sa durée de vie n’est pas dépassée, l’assertion peut être réutilisée.
Elle peut donc être générée et signée avant de solliciter les webservices. La CPx n’est pas non plus sollicitée systématiquement lors de
chaque accès aux web-services.
Figure 3 – Authentification directe
13/12/2016
GIE SESAM-Vitale
16 / 40
Ce document à diffusion restreinte ne peut être diffusé sans l'autorisation d'une personne habilitée
au GIE SESAM-Vitale
Cadre d’interopérabilité technique des services AMC
3.3 Authentification par délégation
d’une personne physique
Un PS accède au système cible au travers d’un système d’information
opéré par une personne morale. Celui-ci met en œuvre des dispositifs
d’authentification des PS cohérents avec ceux exigés pour une authentification directe. Le système d’information s’authentifie auprès du système cible sous sa propre responsabilité et propage vers le système
cible l’identité du PS qu’il a authentifié.
Ce cas correspond, par exemple, aux éditeurs offrant un service mode
SaaS à valeur ajoutée dont l’une des composantes est l’authentification
directe du PS sur ses propres machines et la prise en charge de
l’authentification sur le système cible.
Dans ce cas, une nouvelle assertion est générée systématiquement par
l’éditeur pour chaque échange. Elle est signée par le certificat logiciel
de l’éditeur. Le système cible vérifie que l’assertion SAML et attribue
les autorisations sur la base de l’identité du PS.
Figure 4 – Authentification par délégation
13/12/2016
GIE SESAM-Vitale
17 / 40
Ce document à diffusion restreinte ne peut être diffusé sans l'autorisation d'une personne habilitée
au GIE SESAM-Vitale
Cadre d’interopérabilité technique des services AMC
3.4 Authentification directe
d’une personne morale
Une personne morale (ES ou assimilé) sollicite le système cible sous sa
propre responsabilité. Elle est pleinement responsable des actions de
ses agents. Elle définit et elle assure elle-même les modalités
d’authentification et de contrôle d’accès de ses agents en vers le système cible.
La personne morale est elle-même authentifiée de manière appropriée
auprès du système cible.
Dans ce cas, une assertion SAML est générée par le SIH de l’ES pour
chaque échange. Elle est signée par le certificat logiciel de l’ES et contient l’identité de l’ES. Le système cible vérifie que l’assertion SAML
et attribue les autorisations sur la base de l’identité de l’ES.
Figure 5 – Authentification directe d’une personne morale
13/12/2016
GIE SESAM-Vitale
18 / 40
Ce document à diffusion restreinte ne peut être diffusé sans l'autorisation d'une personne habilitée
au GIE SESAM-Vitale
Cadre d’interopérabilité technique des services AMC
3.5 Assertion SAML
L’utilisation de l’assertion respecte la standardisation WS-I Basic Security Profile 1.1, notamment les recommandations WS-Security SAML
Token Profile 1.1 pour ce qui concerne le contenu de l’assertion et son
utilisation avec l’en-tête WS-Security. L’assertion SAML ne contient
pas d’élément fonctionnel. Elle est exploitée pour autoriser l’exécution
du service et peut être conservée comme preuve d’accès.
Voici la déclinaison de l’assertion pour le cadre d’interopérabilité des
web-services AMC.
Son espace de nommage des assertions SAML est
urn:oasis:names:tc:SAML:2.0:assertion.
Son espace de nommage de la signature XMLDsig est
http://www.w3.org/2000/09/xmldsig#.
Les alias d’espaces de nommage (ici
suivant les environnements.
saml :
et
ds :)
peuvent varier
<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
version="2.0" [1]
ID="ID" [1]
IssueInstant="...[1]">
<saml:Issuer Format="... [1]">... </saml:Issuer> [1]
<ds:Signature>... </ds:Signature> [1]
<saml:Subject>
<saml:NameID NameQualifier="..." [1]>... </saml:NameID> [1]
</saml:Subject> [1]
<saml:AttributeStatement> [1]
<saml:Attribute Name="..."> [1..N]
<saml:AttributeValue>... </saml:AttributeValue> [1]
</saml:Attribute>
</saml:AttributeStatement>
</saml:Assertion>
Les éléments suivants de l’assertion doivent être renseignés :
Version (obligatoire)
Cet attribut XML contient la version du standard SAML. Il
prend la valeur "2.0".
13/12/2016
GIE SESAM-Vitale
19 / 40
Ce document à diffusion restreinte ne peut être diffusé sans l'autorisation d'une personne habilitée
au GIE SESAM-Vitale
Cadre d’interopérabilité technique des services AMC
ID (obligatoire)
Cet attribut XML (xs:NCNAME) est l’identifiant de l’assertion. Il
est composé du caractère "_" suivi d’un UUID.
C’est-à-dire ID
::="_"<UUID>
Par exemple : _f81d4fae-7dec-11d0-a765-00a0c91e6bf6
IssueInstant (obligatoire)
Cet attribut XML (xs:dateTime) contient l’horodatage de
l’assertion au format UTC (au format AAAA-MM-JJThh:mm:ss.sZ).
Par exemple : 2016-06-02T15:38:58Z
<Issuer> (obligatoire)
Cette balise XML contient l’identité de l’émetteur de l’assertion.
C’est le DN présent dans le certificat X.509 de signature. La représentation textuelle du DN doit être conforme à la RFC 2253
« UTF-8 String Representation of Distinguished Names » de décembre 1997.
Format (obligatoire)
Cet attribut XML contient le format du DN de certificat. La valeur est fixée à : Format="urn:oasis:names:tc:SAML:1.1:nameid-
format:X509SubjectName".
<Signature> (obligatoire)
Cette balise XML contient la signature XMLDsig (voir cidessus).
<Subject><NameID> (obligatoire)
Cette balise XML contient l’identifiant de portée nationale de la
personne physique (PS) ou morale (ES) responsable du traitement 4.
4
http://esante.gouv.fr/sites/default/files/pgssi_referentiel_d_identification_v1.0.pdf
13/12/2016
GIE SESAM-Vitale
20 / 40
Ce document à diffusion restreinte ne peut être diffusé sans l'autorisation d'une personne habilitée
au GIE SESAM-Vitale
Cadre d’interopérabilité technique des services AMC
Dans le cas de l’utilisation d’un certificat de l’ASIP Santé, cette
balise XML contient la valeur du champ CN du DN du certificat de
l’ASIP Santé. Ce numéro intègre un préfixe 5 attribué par
l’ASIP Santé.
<Subject><NameID@NameQualifier> (obligatoire)
Cet attribut XML porte l’autorité d’affectation de l’identifiant de
la personne physique (PS) ou morale (ES).
Dans le cas de l’utilisation d’un certificat de l’ASIP Santé,
l’autorité d’affectation de l’identifiant est l’ASIP Santé et non
l’autorité qui a attribué l’identifiant national.
L’attribut XML est alors valorisé avec le contenu du champ gipCardType de la CPx. C’est-à-dire :
– "CPS" ;
– "CPF" ;
– "CDE-CPE" ;
– "CPA".
Dans le cas d’utilisation de moyen d’authentification différent de
ceux de l’ASIP Santé, l’attribut XML porte l’autorité
d’attribution de l’identifiant national. C’est à dire :
–
–
Pour une personne physique (PS) :
o
o
o
"RPPS" ;
"ADELI" ;
"Local" -
o
o
"SIREN" ;
"SIRET".
pour un identifiant de portée locale via
une identification indirecte.
Pour les personnes morales (ES) :
o "FINESSEJ" (FINESS juridique) ;
o "FINESSET" (FINESS établissement) ;
<AttributeStatement> (obligatoire)
Si une assertion comporte des attributs <Attribute> autres que
celui défini ci-dessous, le système cible devra les accepter.
5
http://www.esante.gouv.fr/sites/default/files/CI-SIS_ANX_SOURCES-DONNEESPERSONNES-STRUCTURES_V1.3.1.pdf
13/12/2016
GIE SESAM-Vitale
21 / 40
Ce document à diffusion restreinte ne peut être diffusé sans l'autorisation d'une personne habilitée
au GIE SESAM-Vitale
Cadre d’interopérabilité technique des services AMC
<Attribute@Name> (obligatoire)
Cet
attribut
XML
est
Name="identifiantFacturation".
une
constante
égale
à
<AttributeValue> (obligatoire)
Cette balise XML contient l’identifiant du "responsable" du traitement. C’est sur cet identifiant que seront réalisés les contrôles
d’accès.
Chaque service spécifiera l’origine de cette information.
Dans une grande majorité des cas :
–
–
–
Pour une authentification directe d’une personne physique, ce numéro est le numéro de facturation du PS.
Pour une authentification par délégation, ce numéro est
également le numéro de facturation du PS.
pour une authentification directe d’une personne morale,
ce numéro prend la forme suivante : <FINESS
JUR>"/"<FINESS ET>
13/12/2016
GIE SESAM-Vitale
22 / 40
Ce document à diffusion restreinte ne peut être diffusé sans l'autorisation d'une personne habilitée
au GIE SESAM-Vitale
Cadre d’interopérabilité technique des services AMC
La signature XMLDesig est composée comme suit :
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="..."/> [1]
<ds:SignatureMethod Algorithm="..."/> [1]
<ds:Reference URI="..."> [1]
<ds:Transforms>[1]
<ds:Transform Algorithm="..."/>[1]
<ds:Transform Algorithm="..."/>[1]
</ds:Transforms>
<ds:DigestMethod Algorithm="..."/>[1]
<ds:DigestValue> ... </ds:DigestValue>[1]
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue> ... </ds:SignatureValue> [1]
<ds:KeyInfo> [1]
<ds:X509Data> [1]
<ds:X509Certificate> ... </ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
Les éléments suivants de la signature doivent être renseignés :
CanonicalizationMethod@Algorithm (obligatoire)
Cet attribut XML définit l’algorithme de canonisation de la balise XML <Reference>. L’algorithme utilisé est :
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#".
SignatureMethod@Algorithm (obligatoire)
Cet attribut définit l’algorithme de signature de la balise XML
<Reference>, c’est-à-dire :
Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256".
Reference@URI (obligatoire)
Cet attribut XML porte URI (au format "#"+ID) de l’identifiant
de l’assertion SAML (<Assertion ID="...">).
Transform@Algorithm (obligatoire)
On utilise ici une signature enveloppée. C’est-à-dire que la balise XML <signature> est incluse dans l’assertion SAML. Cet attribut XML est donc valorisé à :
Algorithm="http://www.w3.org/2000/09/xmldsig#envelopedsignature".
13/12/2016
GIE SESAM-Vitale
23 / 40
Ce document à diffusion restreinte ne peut être diffusé sans l'autorisation d'une personne habilitée
au GIE SESAM-Vitale
Cadre d’interopérabilité technique des services AMC
Transform@Algorithm (obligatoire)
On décrit l’algorithme de canonisation C14N utilisé sur la balise
XML de l’assertion SAML. Cet attribut XML est donc valorisé
à:
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#".
DigestMethod@Algorithm (obligatoire)
On utilise une méthode de prétraitement SHA-256 pour calculer
le digest de l’assertion SAML. Cet attribut XML est donc valorisé à :
Algorithm="http://www.w3.org/2001/04/xmlenc#sha256".
<DigestValue> (obligatoire)
Cette balise XML contient le résultat du digest de l’assertion
SAML référencée par l’attribut XML Reference@URI.
<SignatureValue> (obligatoire)
Cette balise XML contient le résultat de la signature.
<X509Certificate> (obligatoire)
Cette balise XML contient le certificat X.509 de signature.
13/12/2016
GIE SESAM-Vitale
24 / 40
Ce document à diffusion restreinte ne peut être diffusé sans l'autorisation d'une personne habilitée
au GIE SESAM-Vitale
Cadre d’interopérabilité technique des services AMC
Chapitre 4
Les échanges
Figure 6 – Échange SOAP
Ces échanges respectent les principes décrits dans le document SOAP
HTTP Binding 1. Les requêtes et les réponses sont des messages
SOAP 1.2 transmis sur le protocole HTTP 1.1.
Les requêtes doivent être encodées en UTF-8.
L’en-tête HTTP Content-Type doit être positionné à :
Content-Type=application/soap+xml; charset="utf-8"
Le codage littéral doit être utilisé ; l’élément
présent dans le message SOAP 6.
encodingStyle
n’est pas
POST/nomService HTTP/1.1
Host:server.example.fr
Content-Type:application/soap+xml; charset="utf-8"
Content-Length:nnnn
6
http://www.w3.org/TR/2003/REC-soap12-part2-20030624
13/12/2016
GIE SESAM-Vitale
25 / 40
Ce document à diffusion restreinte ne peut être diffusé sans l'autorisation d'une personne habilitée
au GIE SESAM-Vitale
Cadre d’interopérabilité technique des services AMC
L’en-tête SOAPAction n’est pas positionné ici, car c’est une spécificité
SOAP 1.1. Néanmoins certains environnements d’exécution la positionnent automatiquement cet en-tête. Dans ce cas, cet en-tête est décrit
dans le WSDL, et elle peut prendre la forme suivante :
"SOAPAction=""<NS_Service>":"<VersNorme>"""
avec :
<NS_Service>
<VersNorme>
Ce l’espace de nom du service.
C’est la version de la norme du web-service
invoqué.
Par exemple : soapAction="urn:amc:med:clc"
Les réponses peuvent prendre l’une des deux formes suivantes : réponses positives ou erreur SOAP.
HTTP/1.1 200 OK
Content-Type:application/soap+xml; charset="utf-8"
Content-Length:nnnn
Une réponse positive possède un code de statut HTTP égal à 200 et
contient toujours un message SOAP.
Si une erreur se produit, plusieurs cas sont à envisager :
− Si une erreur intervient au niveau du protocole HTTP, les codes
de statut HTTP sont utilisés. Cette réponse ne contient pas de
message SOAP.
− Si le corps du message contient une erreur SOAP, le code de
statut HTTP est soit 400 pour une erreur imputée au client soit
500 pour une erreur imputable au serveur.
Type de réponse
Code HTTP
Description
Erreur HTTP
4xx, 5xx
Tous types d’erreurs HTTP.
La réponse ne contient pas de message
ni d’erreur SOAP.
Erreur SOAP
400, 500
Tous types d’erreurs SOAP.
La réponse contient une erreur SOAP.
Aucune erreur
13/12/2016
200
La réponse contient un message SOAP.
GIE SESAM-Vitale
26 / 40
Ce document à diffusion restreinte ne peut être diffusé sans l'autorisation d'une personne habilitée
au GIE SESAM-Vitale
Cadre d’interopérabilité technique des services AMC
4.1 Les requêtes SOAP
Figure 7 – Requête SOAP
Une requête SOAP est composée d’un en-tête (<Header>) et d’un corps
de message (<Body>). L’en-tête permet de véhiculer toutes les informations nécessaires au contrôle d’accès, à la traçabilité et au routage de la
requête vers le service fonctionnel final. Le corps de message véhicule
un document métier propre au service.
<soap:Envelope>
<soap:Header> ... </soap:Header> [1]
<soap:Body> ... </soap:Body> [1]
</soap:Envelope>
Attention, l’alias d’espace de nommage (ici
les environnements.
13/12/2016
soap :)
GIE SESAM-Vitale
peut varier suivant
27 / 40
Ce document à diffusion restreinte ne peut être diffusé sans l'autorisation d'une personne habilitée
au GIE SESAM-Vitale
Cadre d’interopérabilité technique des services AMC
4.1.1 Header SOAP
Un message SOAP possède 3 en-têtes obligatoires.
− L’en-tête Message ;
− L’en-tête LPS ;
− L’en-tête WS-Security.
<soap:Header>
<ci:Message> ... </ci:Message>
<ci:LPS> ... </ci:LPS>
<wsse:Security> ... </wsse:Security>
</soap:Header>
L’en-tête Message
Cet en-tête contient toutes les informations nécessaires à la gestion, à la
traçabilité et au routage des échanges.
Son espace de nommage est urn:amc:ci. L’alias de l’espace de nommage (ici ci :) peut varier suivant les environnements.
<ci:Message xmlns:ci="urn:amc:ci">
<ci:Id> ... </ci:Id> [1]
<ci:Horodatage> ... </ci:Horodatage> [1]
<ci:Adressage> ... </ci:Adressage> [1]
<ci:Type> ... </ci:Type> [0..1]
</ci:Message>
Avec :
<Id> (obligatoire)
Cette balise XML contient l’identifiant unique de la requête. Ce
numéro prend la forme d’un UUID sous sa forme canonique et
doit être régénéré à chaque nouvelle requête.
Par exemple : 06c6bece-28d6-11e6-86d7-e6618c2586e4
<Horodatage> (obligatoire)
Cette balise XML contient la date et l’heure de création de la requête sous la forme xs:dateTime localisée.
Par exemple : 2016-11-17T14:15:30+02:00
13/12/2016
GIE SESAM-Vitale
28 / 40
Ce document à diffusion restreinte ne peut être diffusé sans l'autorisation d'une personne habilitée
au GIE SESAM-Vitale
Cadre d’interopérabilité technique des services AMC
<Adressage> (obligatoire)
Cette balise XML contient l’adresse du web-service cible. Elle
prend la forme d’une URN. Le CI offre un mécanisme flexible
pour étendre les capacités de routage sans connaître au préalable
les règles à appliquer. L’URN composée comme suit (décrit
dans le format BNF 7) :
URN::="urn:amc :"<NumAMC>" :"<TypeConv>" :"<CSR>" :"<DomConv>"
:"<Norme>" :"<VersNorme>" :"<Srv>
avec
:
amc
<NumAMC>
<TypeConv>
<CSR>
<DomConv>
<Norme>
<VersNorme>
<Srv>
Cette constante définit le contenu qui suit et donne
un nom à l’algorithme de routage. Le cadre
d’interopérabilité peut être étendu sur ce point en
fournissant d’autres critères de routage qui dans ce
cas aurait un autre identifiant.
Numéro d’AMC.
Code Type Convention.
Critère secondaire.
Ce code représente le domaine sur lequel porte la
convention signée entre le Prestataire de Soins et
l’AMC (ou son représentant) Exemple : Radiologie, Biologie, Optique, Séjour hospitalier, soins
externes.
C’est l’identifiant de la norme du web-service
invoqué.
C’est la version de la norme du web-service invoqué.
C’est l’identifiant du service invoqué.
<Type> (optionnel)
Cette balise XML contient une valeur caractérisant le flux. Elle
peut prendre la valeur EDITEUR, SONDE... Si cette balise XML n’est
pas présente, la requête est considérée comme provenant d’un
éditeur (ce qui est le cas par défaut).
7
https://en.wikipedia.org/wiki/Backus%E2%80%93Naur_Form
13/12/2016
GIE SESAM-Vitale
29 / 40
Ce document à diffusion restreinte ne peut être diffusé sans l'autorisation d'une personne habilitée
au GIE SESAM-Vitale
Cadre d’interopérabilité technique des services AMC
L’en-tête LPS
Cet en-tête contient toutes les informations d’identification du SI-PS.
Son espace de nommage est urn:amc:ci. L’alias de l’espace de nommage (ici ci) peut varier suivant les environnements.
<ci:LPS xmlns:ci="urn:amc:ci">
<ci:Id> ... </ci:Id> [1]
<ci:Nom> ... </ci:Nom> [1]
<ci:Version> ... </ci:Version> [1]
<ci:Editeur> ... </ci:Editeur> [1]
<ci:Instance> ... </ci:Instance> [1]
</ci:LPS>
Avec :
<Id> (obligatoire)
Le SI-PS reçoit un numéro d’autorisation attribué par le Centre
National de Dépôt et d’Agrément (CNDA). Ce numéro est contrôlé par le système cible. Cette balise XML prend la forme
d’une URN composée du préfixe urn:cnda : puis du numéro attribué par le CNDA.
Par exemple : urn:cnda:1223457
L’éditeur s’engage à garder secret ce numéro et à se prémunir de
la mise en œuvre de ce numéro dans d’autres logiciels que ceux
référencés.
<Nom> (obligatoire)
Cette balise XML contient le nom du logiciel.
<Version> (obligatoire)
Cette balise XML contient la version du logiciel attribuée par
l’éditeur.
<Editeur> (obligatoire)
Cette balise XML contient le nom de l’éditeur.
13/12/2016
GIE SESAM-Vitale
30 / 40
Ce document à diffusion restreinte ne peut être diffusé sans l'autorisation d'une personne habilitée
au GIE SESAM-Vitale
Cadre d’interopérabilité technique des services AMC
<Instance> (obligatoire)
Cette balise XML contient l’identifiant d’installation du logiciel.
Cet identifiant est généré lors de l’installation du LPS. Cet identifiant prend la forme d’un UUID sous sa forme canonique. Il doit
être pérenne pour une installation d’un logiciel. Ce numéro est
une aide au support, car il permet de regrouper les requêtes d’un
même logiciel et permet de compter le nombre de logiciels accédant au web-service.
L’en-tête WS-Security
Selon les spécifications d’OASIS Web Services Security (WSS) TC,
l’en-tête <wsse:Security> fournit un mécanisme pour attacher des assertions. Les alias d’espaces de nommage (ici saml : et wsse :) peuvent
varier suivant les environnements.
<wsse:Security xmlns:wsse="...">
<saml:Assertion xmlns:saml="...">
...
</saml:Assertion>
</wsse:Security>
4.1.2 Body SOAP
Le body SOAP d’une requête contient un document métier.
4.2 Les réponses SOAP
Une réponse SOAP est composée uniquement d’un corps de message
(<Body>) qui véhicule un document métier propre au service.
Aucun en-tête n’est retourné par le web-service.
<soap:Envelope>
<soap:Body> ... </soap:Body> [1]
</soap:Envelope>
L’alias d’espace de nommage (ici
vices et les AMC.
soap :)
peut varier suivant les ser-
Le body SOAP d’une réponse contient un document métier.
13/12/2016
GIE SESAM-Vitale
31 / 40
Ce document à diffusion restreinte ne peut être diffusé sans l'autorisation d'une personne habilitée
au GIE SESAM-Vitale
Cadre d’interopérabilité technique des services AMC
4.3 Les erreurs SOAP
Après la réussite d’un accès au niveau de la couche du protocole HTTP,
la requête SOAP est traitée par le web-service. Cette opération ne génère plus de réponse d’erreur au niveau de HTTP. Les seules erreurs
qui peuvent être générées sont des erreurs SOAP. Lorsque des erreurs
SOAP sont générées, elles ont un code de statut HTTP 400 ou 500.
Chaque service spécifiera les erreurs qui lui sont propres.
Hors, consigne particulière décrite dans les spécifications,
− le SI-PS doit afficher le libellé de l’erreur (la balise XML
<soap:Reason><soap:Text>).
− Il est également recommandé d’afficher le code erreur la (balise
XML <soap:Subcode><soap:Value>) pour faciliter les échanges du
PS avec son support éditeur.
Il est recommandé au SI-PS de conserver la totalité de l’erreur SOAP
afin de faciliter le diagnostic de l’erreur.
Les alias d’espaces de nommage (dans l’exemple ci-dessous
peuvent varier suivant les services et les AMC.
soap :
et
ci :)
Les erreurs SOAP sont structurées sous forme standard de FAULT
SOAP 8.
<soap:Fault>
<soap:Code> [1]
<soap:Value> ... </soap:Value> [1]
<soap:Subcode>
<soap:Value> ... </soap:Value> [1]
</soap:Subcode>
</soap:Code>
<soap:Reason>
<soap:Text> ... </soap:Text> [1]
</soap:Reason>
<soap:Detail> ... </soap:Detail> [1]
</soap:Fault>
8
https://www.w3.org/TR/soap12-part1/#soapfault
13/12/2016
GIE SESAM-Vitale
32 / 40
Ce document à diffusion restreinte ne peut être diffusé sans l'autorisation d'une personne habilitée
au GIE SESAM-Vitale
Cadre d’interopérabilité technique des services AMC
Avec :
<Code><Value> (obligatoire)
Cette balise XML contient la classe de l’erreur xs:QName. Les
codes d’erreurs SOAP utilisent le préfixe de l’espace de nommage http://www.w3.org/2003/05/soap-envelope comme préfixe.
Celui-ci peut prendre les valeurs suivantes :
–
soap:Sender
pour les erreurs imputables au client. Cela
indique une erreur liée à l’émetteur du flux (erreur imputable au contenu du message) et correspond souvent aux
erreurs applicatives, protocolaires ou liées à la sécurité
(exemple : l’utilisateur n’a pas les droits d’accès) ou erreurs techniques du client (exemple : le message est mal
formaté).
– soap:Receiver pour les erreurs imputables au webservice. Cela indique une erreur liée au récepteur du flux
et correspond aux erreurs techniques (ex SGBD inaccessible, indisponibilité, problème du parseur XML...).
– D’autres classes d’erreur existent telles que
soap:VersionMismatch, soap:MustUnderstand,
soap:DataEncodingUnknown.
– Chaque code est associé à un code de statut HTTP 9.
9
Classe d’erreur
Code HTTP
soap:VersionMismatch
500
soap:MustUnderstand
500
soap:Sender
400
soap:Receiver
500
soap:VersionMismatch
500
http://www.w3.org/TR/2003/REC-soap12-part2-20030624
13/12/2016
GIE SESAM-Vitale
33 / 40
Ce document à diffusion restreinte ne peut être diffusé sans l'autorisation d'une personne habilitée
au GIE SESAM-Vitale
Cadre d’interopérabilité technique des services AMC
<Subcode><Value> (obligatoire)
C’est le code d’erreur propre au web-service. Chaque code
d’erreur est associé à un message dans la balise XML <Reason> et
à une description dans la balise XML <Detail>. Un code d’erreur
est un xs:QName 10. C’est à dire un nom qualifié du type <prefixe>:<texte> de forme NCName:NCName. Les codes d’erreurs communs utilisent l’espace de nommage est urn:amc:ci dont le préfixe est "amc". Les codes d’erreur ne peuvent commencer par un
chiffre.
<Reason><Text> (obligatoire)
Cette balise XML porte la description textuelle de l’erreur qui
est exploitée par le LPS comme message d’erreur pour le PS.
<Detail> (obligatoire)
Cette balise XML contient des indications supplémentaires.
L’élément <detail> inclut une structure XML définie par les
AMC hors des spécifications SOAP 1.2. Celle-ci fournit des informations détaillées de l’erreur.
La première version de cette structure XML <Erreur> comporte
les éléments nécessaires à l’analyse d’un problème.
Une évolution de cette structure XML <Erreur2> ajoute en complément des éléments de contact AMC.
L’espace de nommage de ces structures est urn:amc:ci.
Structure XML <Erreur>
<ci:Erreur xmlns:ci="urn:amc:ci">
<ci:MessageId> ... </ci:MessageId> [1]
<ci:Horodatage> ... </ci:Horodatage> [1]
<ci:Adressage> ... </ci:Adressage> [0..1]
<ci:Message> ... </ci:Message> [0..1]
</ci:Erreur>
<MessageId> (obligatoire)
C’est la valeur de l’identifiant
d’origine.
10
<Message><Id>
du message
https://en.wikipedia.org/wiki/QName
13/12/2016
GIE SESAM-Vitale
34 / 40
Ce document à diffusion restreinte ne peut être diffusé sans l'autorisation d'une personne habilitée
au GIE SESAM-Vitale
Cadre d’interopérabilité technique des services AMC
<Horodatage> (obligatoire)
C’est l’horodatage de l’erreur en heure local.
<Adressage> (optionnel)
C’est l’identifiant du régime sur lequel l’erreur s’est produite.
Cet identifiant est identique à la balise XML <Message><Adressage> du message d’origine.
<Message> (optionnel)
Texte d’aide pour l’éditeur précisant les raisons de l’erreur. Ce
message n’est pas affiché au PS.
Structure XML <Erreur2>
<ci:Erreur2 xmlns:ci="urn:amc:ci">
<ci:MessageId> ... </ci:MessageId> [1]
<ci:Horodatage> ... </ci:Horodatage> [1]
<ci:Adressage> ... </ci:Adressage> [0..1]
<ci:Message> ... </ci:Message> [0..1]
<ci:ContactAmc> [0..1]
<ci:Nom> ... </ci:Nom> [1]
<ci:Email> ... </ci:Email> [0..1]
<ci:Telephone> ... </ci:Telephone> [0..1]
</ ci:ContactAmc>
</ci:Erreur2>
Les premières balises XML sont les mêmes que celles de la structure
XML <Erreur>.
<ContactAmc> (optionnel)
Cette balise XML contient les trois éléments de contact décrit
ci-dessous.
<Nom> (obligatoire)
C’est le nom du contact AMC.
<Email> (optionnel)
C’est l’email du contact.
<Telephone> (optionnel)
C’est le numéro de téléphone du contact.
13/12/2016
GIE SESAM-Vitale
35 / 40
Ce document à diffusion restreinte ne peut être diffusé sans l'autorisation d'une personne habilitée
au GIE SESAM-Vitale
Cadre d’interopérabilité technique des services AMC
Chapitre 5
Le document métier
5.1 Structure
Les enjeux fonctionnels fixent la définition du document métier. Le
cadre d’interopérabilité fixe des attributs communs.
<DocumentMetier xmlns="urn:amc:med"
version="..."
Id="..."
horodatage="...">
...
</DocumentMetier>
avec
xmlns
Espace de nommage identifiant la norme utilisée.
version
Cet attribut XML porte la version de la norme complète du
schéma du document XML
Id
Cet attribut XML porte l’identifiant unique du document XML
de type xs:ID. Cet identifiant est un UUDI préfixé par « _ ».
Par exemple :
_3f7b3dcf-1674-4ecd-92c8-1544f346baf8
horodatage
Date et heure de création du document en heure local.
Par exemple : 2016-12-17T09:30:47+02:00
13/12/2016
GIE SESAM-Vitale
36 / 40
Ce document à diffusion restreinte ne peut être diffusé sans l'autorisation d'une personne habilitée
au GIE SESAM-Vitale
Cadre d’interopérabilité technique des services AMC
5.2 La signature des documents métier
Si nécessaire, un document métier peut être signé par son émetteur.
Dans ce cas, des certificats X.509 issus d’une autorité de certification
du GIE SESAM-Vitale sont utilisés.
À l’image de ce qui est demandé pour la sécurité d’accès, le SI-PS doit
savoir gérer au moins deux certificats d’autorités du certificat de signature : une autorité en fin de vie et la nouvelle.
Le besoin de signature est spécifié pour chaque service. La signature
est compatible XaDes. Elle porte sur deux éléments :
− le document métier ;
− le certificat X.509 permettant de vérifier la signature.
Les algorithmes sélectionnés sont les suivants :
− l’algorithme de signature RSA basé sur l’algorithme de hachage
(digest) SHA-256 sur les informations signées ;
− l’algorithme de hachage (digest) SHA-256 ;
− l’algorithme de canonisation « Exclusive XML canonicalization ».
Cet algorithme est appliqué avant le hachage du XML (digest).
Utiliser la canonisation permet aux applications d’utiliser le traitement
XML et de parser les données XML sans « casser » la signature.
13/12/2016
GIE SESAM-Vitale
37 / 40
Ce document à diffusion restreinte ne peut être diffusé sans l'autorisation d'une personne habilitée
au GIE SESAM-Vitale
Cadre d’interopérabilité technique des services AMC
La signature XMLDsig est composée comme suit :
<ds:Signature xmlns:ds=" http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="..."/> [1]
<ds:SignatureMethod Algorithm="..."/> [1]
<!-- Reference portant sur de document metier -->
<ds:Reference URI="..."> [1]
<ds:Transforms>[1]
<ds:Transform Algorithm="..."/>[1]
<ds:Transform Algorithm="..."/>[1]
</ds:Transforms>
<ds:DigestMethod Algorithm="..."/>[1]
<ds:DigestValue> ... </ds:DigestValue>[1]
</ds:Reference>
<!-- Reference portant sur le KeyInfo -->
<ds:Reference URI="..."> [1]
<ds:Transforms>[1]
<ds:Transform Algorithm="..."/>[1]
</ds:Transforms>
<ds:DigestMethod Algorithm="..."/>[1]
<ds:DigestValue> ... </ds:DigestValue>[1]
</ds:Reference>
</SignedInfo>
<ds:SignatureValue> ... </ds:SignatureValue> [1]
<ds:KeyInfo Id="..."> [1]
<ds:X509Data> [1]
<ds:X509Certificate> ... </ds:X509Certificate> [1]
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
Les éléments suivants de la signature doivent être renseignés :
CanonicalizationMethod@Algorithm (obligatoire)
Cet attribut XML définit l’algorithme de canonisation des deux
balises XML <Reference> :
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#".
SignatureMethod@Algorithm (obligatoire)
Cet attribut XML définit l’algorithme de signature des deux balises XML <Reference> :
Algorithm=""http://www.w3.org/2001/04/xmldsig-more#rsa-sha256".
<SignatureValue> (obligatoire)
Cette balise XML contient la valeur de la signature.
13/12/2016
GIE SESAM-Vitale
38 / 40
Ce document à diffusion restreinte ne peut être diffusé sans l'autorisation d'une personne habilitée
au GIE SESAM-Vitale
Cadre d’interopérabilité technique des services AMC
KeyInfo@Id (obligatoire)
La balise XML <KeyInfo> contient le certificat X.509 avec la
clef publique de vérification. C’est également un des éléments
signés. Elle doit avoir un attribut Id de type xs:ID. Cet attribut
doit contenir une valeur unique dans le flux XML.
<X509Certificate> (obligatoire)
Cette balise XML contient le certificat X.509 de signature. La
balise XML <SignedInfo> intègre deux objets <Reference> désignant les deux parties à signer (Le document métier, le certificat).
Concernant la référence au document métier :
Reference@URI (obligatoire)
Cet attribut XML porte URI de l’identifiant (ID) du document
métier à signé (de la forme "#"+ID).
Transform@Algorithm (obligatoire)
On utilise une signature enveloppée ; le bloc de signature est inclus dans le document métier :
Algorithm="http://www.w3.org/2000/09/xmldsig#envelopedsignature".
Transform@Algorithm (obligatoire)
On utilise un algorithme de canonisation C14N :
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#".
DigestMethod@Algorithm (obligatoire)
On utilise une méthode de prétraitement SHA-256 pour créer le
digest du document métier.
Algorithm="http://www.w3.org/2001/04/xmlenc#sha256".
<DigestValue> (obligatoire)
Cette balise XML contient la valeur du digest du document métier.
13/12/2016
GIE SESAM-Vitale
39 / 40
Ce document à diffusion restreinte ne peut être diffusé sans l'autorisation d'une personne habilitée
au GIE SESAM-Vitale
Cadre d’interopérabilité technique des services AMC
Concernant la référence à <KeyInfo> :
Reference@URI (obligatoire)
Cet attribut XML porte URI de l’identifiant (ID) de <KeyInfo> à
signer (de la forme "#"+ID).
Transform@Algorithm (obligatoire)
On utilise un algorithme de canonisation C14N :
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#".
DigestMethod@Algorithm (obligatoire)
On utilise une méthode de prétraitement SHA-256
digest de la balise XML <keyInfo>.
pour
calculer le
Algorithm="http://www.w3.org/2001/04/xmlenc#sha256".
<DigestValue> (obligatoire)
Cette balise XML contient la valeur du digest de la balise XML
<keyInfo>.
13/12/2016
GIE SESAM-Vitale
40 / 40
Ce document à diffusion restreinte ne peut être diffusé sans l'autorisation d'une personne habilitée
au GIE SESAM-Vitale