Sécurisation des services web
|
> Sécurité - WS-Security X.509 Certificate Token Profile |
Les services Web de la plateforme SOA sont sécurisés à deux niveaux. Au niveau du transport, le service consumer doit obligatoirement établir une connexion via le protocole SSL/TLS. Au niveau du message, l'authentification du service consumer s'effectue sur base des certificats X.509.
Les standards WS-Security utilisés sont décrits dans les spécifications suivantes :
Erreur
Lorsque la plateforme SOA n'accepte pas une requête en raison d'une erreur de sécurité, une erreur SOAP avec le code d'erreur suivant est renvoyée : SOA-01001 – Service call not authenticated.
|
1
2
3
4
5
6
7
8
9
10
11
12
|
<soapenv:Fault> |
Sécurité - WS-Security X.509 Certificate Token Profile
Cette politique de sécurité décrit comment un message SOAP doit être signé avec un certificat X.509 lorsqu'une authentification directe est utilisée entre le service consumer et le service provider.
Le header wsse:Security contient les parties suivantes :
- wsse:BinarySecurityToken avec le certificat consumer X.509v3 en notation base64 ;
- wsu:Timestamp d'une validité maximale de 5 minutes ;
- ds:Signature avec signature numérique sur BST, TMS et soapenv:Body. Chaque bloc est canonisé (Exclusive) et hashé (SHA256) (<DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>).
La signature même est du type RSA-SHA256 (pour un certificat avec chiffrement RSA - <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>) ou ECDSA-SHA256 (pour un certificat ECC - <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha256"/>)
Exemple avec PlatformIntegrationConsumerTest (simplifié)
L'opération checkAccessControl de PlatformIntegrationConsumerTest nécessite un certificat X.509 et une signature. Ce test permet de tester la validité de votre certificat et signature.
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
|
|
Sécurité - WS-Security SAML Token Profile / Holder-of-Key
Un grand nombre de services doivent être appelés avec un token SAML reçu par un service central d’authentification : API Portal (indiquez le terme 'IAM-STS-SecurityTokenService' dans le moteur de recherche) en suivant le standard de OASIS WS-Trust.
Le processus d’authentification se passe comme ceci :
- Le service client s’authentifie une fois à STS avec un certificat X.509.
- Il obtient de STS un token signé SAML qui reste valide pendant une durée limitée.
- Avec ce token, le client peut appeler différents webservices pendant la durée de validité du token.
Pour information: le mécanisme de STS doit être implémenté avant de pouvoir appeler un service business.
Étape par étape
Étape 1
Le service consumer envoie un RequestSecurityToken (RST) au STS avec la demande d'obtenir un token SAML 1.1. Le service consumer signe la SOAP request suivant la x.509 _SHA256 security policy.
Exemple RST
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
<wst:RequestSecurityToken Context="RC-7150fca4-1999-45b8-8284-a3944409a345" |
Étape 2
Après authentification, le STS répondra par une RequestSecurityTokenResponse (RSTR) qui contient le token SAML demandé. La SAML assertion peut être filtrée avec xpath (//soapenv:Body/wst:RequestSecurityTokenResponse/wst:RequestedSecurityToken/*).
Exemple RSTR
|
1
2
3
4
5
6
7
8
9
10
11
12
13
|
<wst:RequestSecurityTokenResponse Context = "RC-938ae2a2-6839-41ee-9c0e-7eab62a5a748" xmlns:wst = "http://docs.oasis-open.org/ws-sx/ws-trust/200512" > |
Les attributs du token sont évalués durant le contrôle d'accès du service business (autorisation). La structure XML est signée numériquement par le STS pour garantir l'authenticité. Le bloc Conditions indique dans quelle période le token SAML peut être réutilisé par le service consumer.
Étape 3
Avec un token SAML reçu du STS, le consumer peut invoquer plusieurs services business pendant la durée de validité du token.
Le header wsse:Security contient les parties suivantes :
- saml:Assertion est le token SAML signé par le STS. Les données xml ne peuvent pas être modifiées (pas de formatage, pas de modifications à l'espace de noms), sans quoi la signature numérique sera cassée.
- wsu:Timestamp d'une validité maximale de 5 minutes.
- ds:Signature avec signature numérique sur TMS et soapenv:Body. Chaque bloc est canonisé (Exclusive) et haché (SHA-256).
La signature même est du type :
RSA-SHA256 (pour un certificat avec chiffrement RSA - <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>)
ou
ECDSA-SHA256 (pour un certificat ECC - <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha256"/>).
Le ds:KeyInfo réfère au saml:Assertion sur la base du AssertionID.
Exemple de service business (simplifié)
L'opération checkBrokeredAccess de PlatformIntegrationConsumerTest nécéssite un token SAML de STS. Le but de l'opération est de copier le token SAML précédemment récupéré de l'étape 2 dans la requête vers le webservice business.
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
|
<soapenv:Envelope xmlns:soapenv = "http://schemas.xmlsoap.org/soap/envelope/" xmlns:urn="urn:be:fgov:ehealth:platformintegrationconsumertest:v1" wsu:Id="STRFC77E2C72083DA8E0F16711781375072915" xmlns:wsse11 = "http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd" > |
Sécurité - TLS Protocol
Au niveau du transport, le service consumer doit obligatoirement établir une connexion via le protocole TLS. De cette manière, il est certain de l'identité du service provider (plateforme SOA) et les données en transit sont protégées par voie de cryptage.
Les certificats du serveur de la plateforme SOA sont validés par la Sectigo et doivent être acceptés par le service consumer.
Chaining
|
1
2
3
|
Sectigo (AAA) |_ USERTRUST RSA CERTIFICATION AUTHORITY |_GEANT OV RSA CA 4 |
ou
Chaining
|
1
2
|
USERtrust RSA Certification Authority (avec le nom amical «SECTIGO») |_ |_GEANT OV RSA CA 4 |
Attention : les certificats du serveur sont renouvelés régulièrement. Cela vaut également pour la CA qui délivre les certificats.
Pour information : l'environnement d’acceptation est dédié à l'exécution de tests avant d'utiliser l'environnement de production.
Vous pouvez télécharger les certificats à l'aide d'un navigateur ou via l’openssl-commando:
|
1
|
>> openssl s_client -showcerts -connect services.ehealth.fgov.be:443 |
Exemple avec PlatformIntegrationConsumerTest
Toute la communication passe par une connexion SSL/TLS. L'opération de base du PlatformIntegrationConsumerTest n'a pas de bloc wsse:Security dans le SOAP header.
|
1
2
3
4
5
6
7
8
|
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:urn="urn:be:fgov:ehealth:platformintegrationconsumertest:v1" |