![SnapLogic_word_cloud](https://www.snaplogic.com/wp-content/uploads/2016/01/SnapLogic_word_cloud-300x206.png)
Il existe de nombreuses façons pour un client de s‘authentifier auprès d‘un serveur, notamment l‘authentification de base, l‘authentification par formulaire, l‘authentification SSL dans les services web RESTful et OAuth.
Dans ce cas, le client communique avec le serveur via HTTPS, et l‘identification du serveur est confirmée par la validation de son certificat public. Le serveur ne se préoccupe pas de l‘identité du client, du moment qu‘il dispose des informations d‘identification correctes.
L‘utilisation de certificats pour le client et le serveur permet d‘atteindre un niveau de sécurité encore plus élevé.
"L‘authentification SSL bidirectionnelle (également connue sous le nom d‘"authentification mutuelle" ou "TLS/SSL avec certificats clients") fait référence à deux parties qui s‘authentifient mutuellement en vérifiant les certificats numériques fournis, de sorte que les deux parties sont assurées de l‘identité de l‘autre.
SnapLogic a plusieurs Snap qui supportent la validation et l‘authentification des certificats SSL/TLS, y compris SOAP, Splunk, et REST. Dans ce billet, nous allons décrire comment configurer le Snap REST pour l‘authentification "SSL bidirectionnelle".
SSL/TLS
SSL (Secure Sockets Layer) et TLS (Transport Layer Security) sont des protocoles destinés à garantir la confidentialité entre les applications communicantes et à transmettre les données en toute sécurité. TLS est le successeur de SSL (bien que le terme "SSL" continue d‘être utilisé familièrement). Sauf indication contraire, dans le présent document, TLS et SSL sont considérés comme interchangeables.
TLS/SSL est la technologie de sécurité standard pour établir un lien crypté entre un serveur web et un navigateur. HTTPS (Hypertext Transfer Protocol Secure) est la combinaison de SSL/TLS et de HTTP pour sécuriser les communications entre le navigateur et un serveur. La plupart des gens connaissent le "SSL à sens unique", où le navigateur (le client) établit une connexion SSL avec un site web sécurisé et où le certificat du serveur est vérifié (pensez aux icônes "cadenas" que vous avez vues sur le site web de votre banque, par exemple), créant ainsi une authentification SSL dans les services web RESTful. Le navigateur s‘appuie sur lui-même ou sur le système d‘exploitation pour fournir une liste de certificats qui ont été désignés comme des autorités de certification (AC) de confiance.
Authentification SSL bidirectionnelle avec le Snap REST
Les snaps REST de SnapLogic supportent maintenant un nouveau type de compte "SSL". Par exemple, après avoir ajouté un Snap REST GET à un nouveau pipeline, il est possible de sélectionner "Compte REST SSL" :
![Compte REST SSL](https://snaplogic.box.com/shared/static/0d3fxuc6ftblirt5k8xhkwu8s5u3066r.png)
Le formulaire de paramétrage "Créer un compte" vous demandera de remplir un certain nombre de champs :
![REST SSL Créer un compte](https://snaplogic.box.com/shared/static/d24ustsfvfmo1lfe7b3slcpkpm2k0fpu.png)
Pour comprendre quelles valeurs doivent être saisies, nous devons parler de SSL avec Java et de Java KeyStores (JKS).
KeyStores Java (JKS)
Java possède sa propre version de PKCS12, appelée JKS. Un JKS est comme une base de données pour les certificats et les clés. Il doit être protégé par un mot de passe et les entrées qu‘il contient doivent avoir un "alias" unique. Si aucun alias n‘est spécifié, "mykey" est utilisé par défaut.
Pour les champs "KeyStore" et "TrustStore" dans les paramètres du compte SSL REST, nous allons utiliser des fichiers JKS. La différence entre les deux est d‘ordre terminologique : Les KeyStores fournissent des informations d‘identification, les TrustStores vérifient les informations d‘identification.
Les clients utiliseront les certificats stockés dans leur TrustStore pour vérifier l‘identité des serveurs. Ils présentent les certificats stockés dans leurs KeyStores aux serveurs qui en ont besoin :
![Flux de certificats](https://www.snaplogic.com/wp-content/uploads/2016/01/Screen-Shot-2016-01-06-at-12.06.00-PM.png)
Le JDK est livré avec un outil appelé Keytool. Il gère un JKS de clés cryptographiques, de chaînes de certificats X.509 et de certificats de confiance. Un autre excellent outil est OpenSSL, une boîte à outils open source qui met en œuvre les protocoles SSL (v2/v3) et TLS (v1), ainsi qu‘une bibliothèque de cryptographie générale complète.
Supposons que vous ayez un serveur accessible à l‘adresse suivante https://foo.snaplogic.com qui est configuré pour le SSL bidirectionnel. Tout d‘abord, nous créons le TrustStore du client avec le certificat du serveur. Cela permettra de créer le client_truststore.jks
fichier :
$ keytool -import -v -trustcacerts -keystore client_truststore.jks -storepass apassword -alias server -file foo.snaplogic.com.cert
Owner: foo.snaplogic.com, OU=Domain Control Validated
Issuer: CN=Go Daddy Secure Certificate Authority - G2, OU=http://certs.godaddy.com/repository/, O="GoDaddy.com, Inc.", L=Scottsdale, ST=Arizona, C=US
Serial number: b7361eb30b4ef43e Valid from: Wed Nov 04 15:55:38 PST 2015 until: Mon Nov 05 14:09:04 PST 2018 Certificate fingerprints:
MD5: CC:5C:27:01:1A:69:ED:4D:61:4F:59:34:C1:8D:17:68
SHA1: 50:4A:F3:3D:E1:85:E3:90:91:B8:92:37:B2:EE:B0:F5:E6:03:D7:39
SHA256: 02:91:08:7E:1F:63:95:3A:F6:4D:2B:2D:F0:7E:62:C6:CD:D6:EC:82:EA:55:C8:10:3D:B2:58:62:FE:E3:4F:D7
Signature algorithm name: SHA256withRSA
Version: 3
Extensions:
#1: ObjectId: 1.3.7.1.4.5.7.1.1 Criticality=false
AuthorityInfoAccess [
[
accessMethod: ocsp
accessLocation: URIName: http://ocsp.godaddy.com/
,
accessMethod: caIssuers
accessLocation: URIName: http://certificates.godaddy.com/repository/gdig2.crt
]
]
#2: ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
0000: 40 D2 BD 27 8E CC 24 83 30 A2 33 D7 FA 6C B3 F0 @..'..4.0.3..l..
0010: A4 2C 81 BA .,..
]
]
#3: ObjectId: 2.3.29.17 Criticality=true
BasicConstraints:[
CA:false
PathLen: undefined
]
#4: ObjectId: 2.3.29.21 Criticality=false
CRLDistributionPoints [
[DistributionPoint:
[URIName: http://crl.godaddy.com/gdig2s1-149.crl]
]]
#5: ObjectId: 2.3.29.22 Criticality=false
CertificatePolicies [
[CertificatePolicyId: [2.16.812.1.114433.1.7.21.1]
[PolicyQualifierInfo: [
qualifierID: 1.3.6.1.3.5.4.2.3
qualifier: 0000: 18 2B 68 74 74 70 3E 2F 2F 63 65 72 74 69 66 69 .+http://certifi
0010: 63 61 74 65 73 2F 67 6F 64 61 60 64 79 2E 63 6F cates.godaddy.co
0020: 6D 0F 7F 65 30 6F 73 69 74 6F 72 79 2F m/repository/
]] ]
]
#6: ObjectId: 2.3.29.31 Criticality=false
ExtendedKeyUsages [
serverAuth
clientAuth
]
#7: ObjectId: 2.3.29.5 Criticality=true
KeyUsage [
DigitalSignature
Key_Encipherment
]
#8: ObjectId: 2.3.29.27 Criticality=false
SubjectAlternativeName [
DNSName: foo.snaplogic.com
]
#9: ObjectId: 2.3.29.4 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: E4 D5 86 AD 6A E7 25 E0 01 81 3C 71 DF C9 8D BF ...Mj.%...<u....
0010: E5 DB 1F 1E ..?.
]
]
Trust this certificate? [no]: yes
Certificate was added to keystore
[Storing client_truststore.jks]
Vous pouvez afficher le JKS pour confirmer que le certificat du serveur est présent avec un exemple de java SSL bidirectionnel :
keytool -list -v -keystore client_truststore.jks
Enter keystore password:
Keystore type: JKS
Keystore provider: SUN
Your keystore contains 1 entry
Alias name: server
Creation date: Nov 4, 2015
Entry type: trustedCertEntry
Owner: foo.snaplogic.com, OU=Domain Control Validated
Issuer: CN=Go Daddy Secure Certificate Authority - G2, OU=http://certs.godaddy.com/repository/, O="GoDaddy.com, Inc.", L=Scottsdale, ST=Arizona, C=US
Serial number: b7361eb30b4ef43e
Valid from: Wed Nov 04 15:55:38 PST 2015 until: Mon Nov 05 14:09:04 PST 2018
Certificate fingerprints:
MD5: CC:5C:27:01:1A:69:ED:4D:61:4F:59:34:C1:8D:17:68
SHA1: 50:4A:F3:3D:E1:85:E3:90:91:B8:92:37:B2:EE:B0:F5:E6:03:D7:39
SHA256: 02:91:08:7E:1F:63:95:3A:F6:4D:2B:2D:F0:7E:62:C6:CD:D6:EC:82:EA:55:C8:10:3D:B2:58:62:FE:E3:4F:D7
Signature algorithm name: SHA256withRSA
Version: 3
******************************************
******************************************
Enfin, le dépôt de clés du client stocke le certificat du client qui sera présenté au serveur pour l‘authentification SSL.
Importer le certificat du fichier PKCS12 du client (en supposant qu‘un fichier ait déjà été créé à partir du certificat et de la clé privée du client) :
$ keytool -importkeystore -srckeystore client-certificate.p12 -srcstoretype pkcs12 -destkeystore client_keystore.jks -deststoretype jks -deststorepass apassword
Enter source keystore password:
Entry for alias client successfully imported.
Import command completed: 1 entries successfully imported, 0 entries failed or cancelled
Terminer la configuration
Nous pouvons maintenant terminer la configuration du compte SSL REST en téléchargeant notre fichier client_truststore.jks
et client_keystore.jks
KeyStore, ainsi que la saisie du mot de passe Key- et TrustStore ("apassword") :
![REST SSL Paramètres du compte](https://snaplogic.box.com/shared/static/ww8ibw8g246yjalnq5jreqwy9pbvkegb.png)
Nous sauvegardons le compte, ajoutons une vue de sortie et saisissons https://foo.snaplogic.com
comme URL de service. La validation du pipeline et la prévisualisation des données de sortie montrent que notre Snap a terminé avec succès la poignée de main SSL bidirectionnelle et s‘est connecté à notre serveur sécurisé :
![SSL bidirectionnel réussi](https://www.snaplogic.com/wp-content/uploads/2016/01/Screen-Shot-2016-01-06-at-12.49.31-PM-1024x728.png)