Show Menu
THEMEN×

Digital signierte HTTP Anforderungen

Audience Manager erfordert, dass die HTTP Server-zu-Server-Anforderungen für ihre Gültigkeit digital signiert werden. In diesem Dokument wird beschrieben, wie Sie HTTP Anforderungen mit privaten Schlüsseln signieren können.

Überblick

Mithilfe eines privaten Schlüssels, der von Ihnen bereitgestellt und für Audience ManagerSie freigegeben wurde, können wir die HTTP Anforderungen, die zwischen IRIS und Ihrem HTTP-Server gesendet werden, digital signieren. Dadurch wird sichergestellt:
  • Authentizität : nur der Absender mit dem privaten Schlüssel (IRIS) kann gültige HTTP(S) Nachrichten an den Partner senden.
  • Nachrichtenintegrität : mit diesem Ansatz, sogar auf HTTP werden Sie vor einem Mann im mittleren Angriff geschützt, wo die Nachrichten verzerrt werden.
IRIS hat integrierte Unterstützung zum Drehen der Schlüssel mit null Ausfallzeiten, wie im Abschnitt zum Drehen des privaten Schlüssels unten gezeigt.

Informationen, die Sie bereitstellen müssen

Wenden Sie sich an Ihren HTTP Berater, um ein Audience Manager Echtzeit-Server-zu-Server-Ziel zu erhalten, und geben Sie Folgendes an:
  • Der zum Signieren der Anforderung verwendete Schlüssel.
  • Der Name der HTTP Kopfzeile, die die generierte Signatur enthält (X-Signatur in der Beispielüberschrift unten).
  • Optional: der Hash-Typ, der für die Signatur verwendet wird (md5, sha1, sha256).
* Connected to partner.website.com (127.0.0.1) port 80 (#0)
> POST /webpage HTTP/1.1
> Host: partner.host.com
> Accept: */*
> Content-Type: application/json
> Content-Length: 20
> X-Signature: +wFdR/afZNoVqtGl8/e1KJ4ykPU=
POST message content

How it works

  1. IRIS erstellt die HTTP Nachricht, die an den Partner gesendet werden soll.
  2. IRIS erstellt eine Signatur, die auf der HTTP Nachricht und dem vom Partner mitgeteilten privaten Schlüssel basiert.
  3. IRIS sendet die HTTP(S) Anfrage an den Partner. Diese Meldung enthält die Unterschrift und die tatsächliche Meldung, wie im Beispiel oben dargestellt.
  4. Der Partnerserver erhält die HTTP(S) Anforderung. Er liest den Nachrichtentext und die Signatur, die von IRISihm empfangen wurde.
  5. Basierend auf dem Nachrichtentext und dem privaten Schlüssel berechnet der Partnerserver die Signatur neu. Weitere Informationen dazu finden Sie im Abschnitt Wie man die Signatur berechnet.
  6. Vergleichen Sie die auf dem Partnerserver (Empfänger) erstellte Signatur mit der Signatur, die Sie von IRIS (Absender) erhalten haben.
  7. Wenn die Unterschriften übereinstimmen, wurden die Authentizität und die Nachrichtenintegrität validiert. Nur der Absender, der über den privaten Schlüssel verfügt, kann eine gültige Signatur (Authentizität) senden. Darüber hinaus kann ein Mann in der Mitte die Nachricht nicht ändern und eine neue gültige Signatur generieren, da er nicht über den privaten Schlüssel (Nachrichtintegrität) verfügt.

Berechnung der Unterschrift

HMAC (Hash-basierter Authentifizierungscode) ist die Methode, die IRIS zum Signieren von Nachrichten verwendet wird. Implementierungen und Bibliotheken stehen grundsätzlich in jeder Programmiersprache zur Verfügung. HMAC hat keine bekannten Erweiterungsangriffe. Ein Beispiel Java unten:
// Message to be signed.
// For GET type HTTP destinations, the message used for signing will be the REQUEST_PATH + QUERY_STRING
// For POST type HTTP destinations, the message used for signing will be the REQUEST_BODY.
// String getData = "/from-aam-s2s?sids=1,2,3";
String postData = "POST message content";
// Algorithm used. Currently supported: HmacSHA1, HmacSHA256, HmacMD5.
String algorithm = "HmacSHA1";
// Private key shared between the partner and Adobe Audience Manager.
String key = "sample_partner_private_key";
  
// Perform signing.
SecretKeySpec signingKey = new SecretKeySpec(key.getBytes(), algorithm);
Mac mac = Mac.getInstance(algorithm);
mac.init(signingKey);
byte[] result = mac.doFinal(postData.getBytes());
  
String signature = Base64.encodeBase64String(result).trim(); 
// signature = +wFdR/afZNoVqtGl8/e1KJ4ykPU=

Die RFC für die HMAC Hash-Implementierung lautet https://www.ietf.org/rfc/rfc2104.txt . Eine Testsite: https://asecuritysite.com/encryption/hmac (Beachten Sie, dass Sie die Hex-Kodierung in base64 konvertieren müssen).

Drehen des privaten Schlüssels

Aus Sicherheitsgründen wird empfohlen, den privaten Schlüssel regelmäßig zu drehen. Es liegt an Ihnen, den privaten Schlüssel und den Drehungszeitraum zu bestimmen. Um die Schlüsseldrehung bei null Ausfallzeiten zu erzielen, IRIS unterstützt das Hinzufügen mehrerer Unterschriften-Kopfzeilen. Eine Kopfzeile enthält die Signatur, die mit dem alten Schlüssel generiert wurde, eine andere Kopfzeile enthält die Signatur, die mit dem neuen privaten Schlüssel generiert wurde. Siehe die Schritte im Detail:
  1. Der Partner kommuniziert den neuen privaten Schlüssel mit Adobe Audience Manager.
  2. IRIS beginnt, zwei Unterschriften-Header zu senden (einer mit dem alten Schlüssel, der andere mit dem neuen Schlüssel).
  3. Sobald Sie beide Header empfangen haben, können Sie den alten Schlüssel verwerfen und nur die neue Signatur betrachten.
  4. Der alte Schlüssel wird entfernt Audience Manager und sendet IRIS nur den neuen Unterschriften-Header. Die Schlüssel wurden gedreht.

Zum Unterschreiben verwendete Daten

Bei GET Musterzielen wird die Signaturmeldung REQUEST_PATH + QUERY STRING (z. B. /from-aam-s2s?sids=1,2,3 ). IRIS berücksichtigt nicht den Hostnamen oder die HTTP Header - diese können geändert/falsch konfiguriert werden oder falsch gemeldet werden.
Bei POST Ziel-Typen ist die zum Signieren verwendete Meldung der ANFORDERUNGSKÖRPER . Auch hier werden Kopfzeilen oder andere Anforderungsparameter ignoriert.