Es gibt viele Möglichkeiten für einen Client, sich gegenüber einem Server zu authentifizieren, darunter Basisauthentifizierung, formularbasierte Authentifizierung, SSL-Authentifizierung in RESTful-Webdiensten und OAuth.
In diesen Fällen kommuniziert der Client mit dem Server über HTTPS, und die Identität des Servers wird durch Validierung seines öffentlichen Zertifikats bestätigt. Dem Server ist es egal, wer der Client ist, solange er nur die richtigen Anmeldedaten hat.
Ein noch höheres Maß an Sicherheit kann durch die Verwendung von Zertifikaten sowohl für den Client als auch für den Server erreicht werden.
Bei der "Zwei-Wege-SSL"-Authentifizierung (auch bekannt als "gegenseitige Authentifizierung" oder "TLS/SSL mit Client-Zertifikaten") authentifizieren sich zwei Parteien gegenseitig durch die Überprüfung bereitgestellter digitaler Zertifikate, so dass sich beide Parteien der Identität der anderen sicher sind.
SnapLogic hat mehrere Snaps, die die Validierung und Authentifizierung von SSL/TLS-Zertifikaten unterstützen, darunter SOAP, Splunk und REST. In diesem Beitrag beschreiben wir, wie Sie den REST-Snap für die "Zwei-Wege-SSL"-Authentifizierung konfigurieren.
SSL/TLS
SSL (Secure Sockets Layer) und TLS (Transport Layer Security) sind Protokolle, die die Vertraulichkeit zwischen kommunizierenden Anwendungen gewährleisten und Daten sicher übertragen sollen. TLS ist der Nachfolger von SSL (obwohl "SSL" weiterhin umgangssprachlich verwendet wird). Sofern nicht anders angegeben, werden in diesem Dokument TLS und SSL als austauschbar betrachtet.
TLS/SSL ist die Standardsicherheitstechnologie zur Herstellung einer verschlüsselten Verbindung zwischen einem Webserver und einem Browser. HTTPS (Hypertext Transfer Protocol Secure) ist die Kombination von SSL/TLS und HTTP zur Sicherung der Kommunikation zwischen dem Browser und einem Server. Die meisten Menschen sind mit "Einweg-SSL" vertraut, bei dem der Browser (der Client) eine SSL-Verbindung zu einer sicheren Website herstellt und das Zertifikat des Servers überprüft wird (denken Sie an die "Vorhängeschloss"-Symbole, die Sie z. B. auf der Website Ihrer Bank gesehen haben), wodurch eine SSL-Authentifizierung in RESTful-Webdiensten entsteht. Der Browser verlässt sich entweder auf sich selbst oder auf das Betriebssystem, das eine Liste von Zertifikaten bereitstellt, die als vertrauenswürdige Zertifizierungsstellen (CA) bezeichnet wurden.
Zwei-Wege-SSL-Authentifizierung mit dem REST-Snap
Die REST-Snaps von SnapLogic unterstützen jetzt einen neuen "SSL"-Kontotyp. Nach dem Hinzufügen eines REST-GET-Snaps zu einer neuen Pipeline kann zum Beispiel "REST SSL Account" ausgewählt werden:
Im Einstellungsformular "Konto erstellen" werden Sie aufgefordert, eine Reihe von Feldern auszufüllen:
Um zu verstehen, welche Werte eingegeben werden müssen, müssen wir über SSL mit Java und Java KeyStores (JKS) sprechen.
Java KeyStores (JKS)
Java hat seine eigene Version von PKCS12 namens JKS. Ein JKS ist wie eine Datenbank für Zertifizierungen und Schlüssel. Es muss passwortgeschützt sein und die Einträge müssen einen "Alias" haben, der eindeutig ist. Wenn kein Alias angegeben wird, wird standardmäßig "mykey" verwendet.
Für die Felder "KeyStore" und "TrustStore" in den REST-SSL-Kontoeinstellungen werden wir JKS-Dateien verwenden. Der Unterschied zwischen ihnen ist terminologischer Natur: KeyStores stellen Anmeldeinformationen bereit, TrustStores überprüfen die Anmeldeinformationen.
Clients verwenden die in ihren TrustStores gespeicherten Zertifikate, um die Identität von Servern zu überprüfen. Sie legen die in ihren KeyStores gespeicherten Zertifikate den Servern vor, die sie benötigen:
Das JDK wird mit einem Werkzeug namens Keytool ausgeliefert. Es verwaltet ein JKS mit kryptografischen Schlüsseln, X.509-Zertifikatsketten und vertrauenswürdigen Zertifikaten. Ein weiteres hervorragendes Tool ist OpenSSL, ein Open-Source-Toolkit, das die Protokolle SSL (v2/v3) und TLS (v1) implementiert, sowie eine umfassende Kryptographie-Bibliothek für allgemeine Zwecke.
Nehmen wir an, Sie haben einen Server, der unter https://foo.snaplogic.com der für bidirektionales SSL konfiguriert ist. Zunächst erstellen wir den TrustStore des Clients mit dem Zertifikat des Servers. Dadurch wird die client_truststore.jks Datei:
$ 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=falseCertificatePolicies [ [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]
Sie können das JKS anzeigen, um zu bestätigen, dass das Serverzertifikat vorhanden ist, z. B. bei einem Zwei-Wege-SSL-Java:
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************************************************************************************
Schließlich speichert der Client Keystore das Client-Zertifikat, das dem Server zur SSL-Authentifizierung vorgelegt wird.
Importieren Sie das Zertifikat aus der PKCS12-Datei des Kunden (vorausgesetzt, es wurde bereits eine Datei mit dem Zertifikat und dem privaten Schlüssel des Kunden erstellt):
$ 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
Vervollständigung der Konfiguration
Wir können nun die Konfiguration des REST SSL-Kontos abschließen, indem wir unser client_truststore.jks und client_keystore.jks KeyStore-Dateien, sowie die Eingabe des Key- und TrustStore-Passworts ("apassword"):
Wir speichern das Konto, fügen eine Ausgabeansicht hinzu und geben ein https://foo.snaplogic.com als Dienst-URL. Die Validierung der Pipeline und die Vorschau der Ausgabedaten zeigen, dass unser Snap den zweiseitigen SSL-Handshake erfolgreich abgeschlossen und eine Verbindung mit unserem sicheren Server hergestellt hat:
