Drosselmechanismus throttling-mechanism

Kunden mit der Passauthentifizierung müssen für jeden ihrer Benutzer gemäß den Anweisungen und ihrem Business Case auf die Passauthentifizierungs-API zugreifen können.

Die Passauthentifizierung führt einen Drosselungsmechanismus ein, um eine gerechte Verteilung der Ressourcen unter den Benutzern unserer Kunden sicherzustellen.

Dieser Mechanismus ist aus mehreren Gründen wichtig:

Mechanism - Übersicht mechanism-overview

Client-Implementierungen

Die Passauthentifizierung stellt Richtlinien und SDK für die Interaktion mit der API bereit, steuert jedoch nicht, wie der Kunde sie verwendet. Einige Implementierungen haben möglicherweise eine rudimentäre Implementierung und könnten den Service mit unnötigen API-Anfragen überfluten, ob versehentlich oder nicht, was dazu führen könnte, dass andere Benutzer Verzögerungen oder Kapazitätsprobleme erleben.

Der Dienst selbst sollte in der Lage sein, jede angemessene Kapazität zu verarbeiten. Doch egal wie skalierbar oder leistungsstark ein Service ist, es gibt immer Grenzen. Daher müssen für den Service Limits für die Anzahl der akzeptierten Aufrufe innerhalb eines bestimmten Zeitintervalls konfiguriert sein.

Einführung in Einschränkungen

Die Passauthentifizierung basiert auf einer Benutzeridentifizierung und einem Token-Bucket-Limitationsalgorithmus mit vordefinierten Werten, um den Gerätezugriff jedes Benutzers auf unsere API zu steuern.

Mechanismus zur Geräteerkennung

Der vorgeschlagene Drosselungsmechanismus verwendet die identifizierten Geräte einzeln mithilfe des Headers „X-Forwarded-For“. Die Grenzwerte werden für jedes Gerät auf die gleiche Weise angewendet.

Erforderliche Aktualisierungen

Server-zu-Server-Implementierungen müssen die IP-Adressen ihrer Clients unter Verwendung des Header-Mechanismus „X-Forwarded-For“ weiterleiten.

Weitere Informationen zum Übergeben der Kopfzeile „X-Forwarded-For“ finden hier.

Tatsächliche Grenzwerte und Endpunkte throttling-mechanism-limits

Derzeit ermöglicht das standardmäßige Limit maximal 1 Anfrage pro Sekunde mit einem anfänglichen Burst von 10 Anfragen (einmalige Vergütung für die erste Interaktion des identifizierten Clients, die es ermöglichen sollte, dass die Initialisierung erfolgreich abgeschlossen wird). Dies sollte keinen regulären Business Case für alle unsere Kunden betreffen.

Der Drosselungsmechanismus wird für die folgenden Endpunkte aktiviert:

SDK-Implementierungsverzweigung

Da Clients, die die bereitgestellten Adobe Pass-Authentifizierungs-SDKs verwenden, nicht explizit mit Endpunkten interagieren, werden in diesem Abschnitt die bekannten Funktionen, ihr Verhalten bei einer Drosselungsantwort und die zu ergreifenden Maßnahmen beschrieben.

setRequestor

Beim Erreichen des Drosselungslimits mithilfe setRequestor Funktion aus dem SDK gibt der SDK über errorHandler Callback einen CFG429-Fehlercode zurück.

getAuthorization

Beim Erreichen des Drosselungslimits mithilfe getAuthorization Funktion aus dem SDK gibt der SDK über errorHandler Callback einen Z100-Fehlercode zurück.

checkPreauthorizedResources

Beim Erreichen des Drosselungslimits mithilfe checkPreauthorizedResources Funktion aus dem SDK gibt der SDK über errorHandler Callback einen P100-Fehlercode zurück.

getMetadata

Beim Erreichen des Drosselungslimits mithilfe getMetadata Funktion aus der SDK gibt die SDK über setMetadataStatus Callback eine leere Antwort zurück.

Informationen zu den einzelnen Implementierungsdetails finden Sie in der entsprechenden SDK-Dokumentation.

API-Antwortänderungen und -antwort throttling-mechanism-response

Wenn wir feststellen, dass der Grenzwert überschritten wird, markieren wir diese Anfrage mit einem bestimmten Antwortstatus (HTTP 429: Zu viele Anfragen) und weisen Sie an, dass Sie alle dem Benutzergerät zugewiesenen Token (IP-Adresse) für das Zeitintervall verwendet haben.

Die Drosselung läuft nach einer Sekunde der ersten 429 Antworten ab. Jede Anwendung, die eine 429-Antwort erhält, muss mindestens 1 Sekunde warten, bevor eine neue Anfrage generiert wird.

Alle Kundenanwendungen sollten die Antwort „429 Zu viele Anfragen“ angemessen verarbeiten.

Hier finden Sie eine Beispiel-429-Antwortnachricht:

HTTP/2 429
date: Tue, 20 Feb 2024 11:21:53 GMT
content-type: text/html
content-length: 166
set-cookie: AWSALB=Btl/GzifUpMhUh+TQK63kU4i+gcJOIvAICVLnHTWt5pkrevNsMSQ5DMwM9KlRkNQ0UlXHIDbQoxDua0oVYYFKC8PDwxQjOuuRzxX2fozM+Jcazl2DSfaR7hU2mt2; Expires=Tue, 27 Feb 2024 11:21:53 GMT; Path=/
set-cookie: AWSALBCORS=Btl/GzifUpMhUh+TQK63kU4i+gcJOIvAICVLnHTWt5pkrevNsMSQ5DMwM9KlRkNQ0UlXHIDbQoxDua0oVYYFKC8PDwxQjOuuRzxX2fozM+Jcazl2DSfaR7hU2mt2; Expires=Tue, 27 Feb 2024 11:21:53 GMT; Path=/; SameSite=None; Secure
server: openresty
access-control-allow-credentials: true
access-control-allow-methods: POST,GET,OPTIONS,DELETE
access-control-allow-headers: ap_11,ap_42,ap_z,ap_19,ap_21,ap_23,authorization,content-type,pass_sfp,AP-Session-Identifier,AP-Device-Identifier,AP-SDK-Identifier,X-Device-Info
access-control-expose-headers: pass_sfp,Authzf-Error-Code,Authzf-Sub-Error-Code,Authzf-Error-Details
p3p: CP="NOI DSP COR CURa ADMa DEVa OUR BUS IND UNI COM NAV STA"

<html>
<head><title>429 Too Many Requests</title></head>
<body>
<center><h1>429 Too Many Requests</h1></center>
<hr><center>openresty</center>
</body>
</html>

Auswirkungen und erforderliche Änderungen

Übergeben des Headers „X-Forwarded-For“

Kunden, die eine benutzerdefinierte Implementierung verwenden (einschließlich Server-zu-Server-Implementierungen), um mit der Pass Authentication API zu interagieren, sollten sicherstellen, dass sie ihre Benutzer-IP-Adresse erfassen und korrekt weiterleiten können, indem sie den X-Forwarded-For-Header verwenden, um die Authentifizierungs-API weiter zu übergeben.

Weitere Informationen Siehier).

Reaktion auf neuen Antwort-Code

Kunden, die eine benutzerdefinierte Implementierung (einschließlich Server-zu-Server-Implementierungen) zur Interaktion mit der Passauthentifizierungs-API verwenden, sollten sicherstellen, dass jeder nachfolgende Aufruf, der nach Erhalt einer 429-zu-viele-Anfragen erfolgt, eine Wartezeit von mindestens 1 Sekunde beinhaltet. Diese Wartezeit bietet die Möglichkeit, diesen Mechanismus zu ändern und eine gültige Geschäftsantwort zu erhalten.

Szenario-Beispiel für Einschränkungen