ACS-Wiederholungsrichtlinien

  • Artikel

Aktualisiert: 6. Juli 2015

Gilt für: Azure

Microsoft Azure Active Directory Access Control (auch als Access Control Service oder ACS bezeichnet) unterstützt eine Reihe verschiedener Token-Ausgabe- und Verwaltungsendpunkte, an die Clients Tokenanforderungen senden können. Dieses Thema definiert Leitlinien zum Implementieren von Wiederholungslogik für den Fall von Fehlern bei Tokenanforderungen.

Fehlerbehandlungsszenarien

Fehler bei Tokenanforderungen, die Fehlercodes der HTTP-Serie 500 zurückgeben, stellen normalerweise Antworten auf Wiederholungsversuche dar. In einigen Szenarien ist der Client eine Anwendung oder ein Dienst, der automatisierte Anforderungen an ACS macht. In anderen Szenarien, wie etwa webbasiertem Partnerverbund mit dem WS-Federation-Protokoll, ist der Client ein Webbrowser, und der Endbenutzer muss den Vorgang manuell erneut ausführen. Dieses Thema behandelt Fehlerbehebungsszenarien, bei denen der Client eine Anwendung oder ein Dienst ist.

Zu diesen Szenarien gehören:

Leitlinien für Wiederholungsversuche

Die folgenden Leitlinien erläutern die Implementierung von Wiederholungslogik in den Fehlerbehandlungsszenarien.

Richtlinie #1: Implementieren der Wiederholungslogik basierend auf HTTP 500-Serienfehlerantworten

Die Wiederholungslogik wird dringend empfohlen, wenn ACS HTTP 500-Serienfehler zurückgibt. Die folgende Liste enthält Beispiele für typische Fehler der HTTP-Serie 500.

  • HTTP-Fehler 500 – Interner Serverfehler

  • HTTP-Fehler 502 – Fehlerhaftes Gateway

  • HTTP-Fehler 503 – Dienst nicht verfügbar

  • HTTP-Fehler 504 – Timeout beim Gateway

Obwohl einzelne HTTP-Codes in der Wiederholungslogik aufgezählt werden können, reicht es aus, die Wiederholungslogik aufzurufen, wenn irgendein Fehler der HTTP-Serie 500 zurückgegeben wird.

Die Wiederholungslogik sollte durch HTTP-Fehlercodes ausgelöst werden, z. B. HTTP 504 (Externer Server-Timeout), und nicht durch ACS-Fehlercodes, z. B. ACS90005. ACS-Fehlercodes sind informational und unterliegen änderungen.

Wiederholungslogik ist normalerweise nicht zu empfehlen, wenn Fehlercodes der HTTP 400-Serie zurückgegeben werden. Eine Fehlerantwort der HTTP 400-Serie von ACS bedeutet, dass die Anforderung ungültig ist und überarbeitet werden muss. Eine Ausnahme ist der Fehlercode 429 ("Zu viele Anforderungen"), der anzeigt, dass der Namespace den Grenzwert der Tokenanforderungsrate über einen längeren Zeitraum überschritten hat. Bei 429-Fehlern können Wiederholungsversuche mit einem Wartezeit-Zeitgeber den unmittelbaren Rückstau an Tokenanforderungen auflösen, bis der Administrator Zeit hat, die Arbeitslastverteilung im Namespace zu überprüfen und zu überarbeiten. Weitere Informationen finden Sie unter ACS-Dienstbeschränkungen.

Richtlinie #2: Retries sollten einen Back-Off-Timer für optimale Flusssteuerung verwenden.

Wenn ein Client einen Fehler der HTTP-Serie 500 empfängt, sollte der Client einen angegebenen Zeitraum abwarten, bevor er die Anforderung wiederholt. Die besten Ergebnisse erzielen Sie, wenn Sie diesen Zeitraum für jeden nachfolgenden Wiederholungsversuch verlängern. Bei diesem Ansatz werden vorübergehende Fehler schnell behoben, und die Anforderungsrate für vorübergehende Netzwerk- oder Serverprobleme mit längerer Behebungsdauer wird optimiert.

Verwenden Sie beispielsweise einen exponentiellen Back-Off-Timer, bei dem die Verzögerung vor der Wiederholung mit jeder Instanz exponentielle Erhöhung erfolgt, z. B. "Wiederholen Sie 1: 1 Sekunde", "Wiederholen Sie 2: 2 Sekunden", "Wiederholen" 3: 4 Sekunden usw.

Passen Sie die Anzahl von Wiederholungsversuchen und den Zeitraum zwischen jedem Wiederholungsversuch je nach Ihren Benutzeranforderungen an. Wir empfehlen Ihnen aber bis zu fünf Wiederholungsversuche über einen Zeitraum von fünf Minuten. Die Behebung von Ausfällen, die durch ein Timeout verursacht werden, dauert länger.

Richtlinie #3: Überprüfen Sie, ob das Element nicht vorhanden ist, bevor Sie versuchen, es zu erstellen oder zu löschen.

Wenn Sie Erstellen oder Löschen von Vorgängen mit dem ACS-Verwaltungsdienst durchführen, z. B. das Erstellen einer neuen vertrauenden Parteianwendung oder das Löschen einer Regel, sollte die Wiederholungslogik abfragen, ob das Element vorhanden ist, bevor der Vorgang ausgeführt wird. In einigen Fällen kann ein vorübergehender Netzwerkfehler, der beim Bereitstellen der Serverantwort auftritt, eine Erstellungs- oder Löschungsoperation auch erfolgreich sein, wenn der Client eine Fehlerantwort erhält.

Wenn ein Erstellungsvorgang wiederholt wird, ohne zuvor das Vorhandensein des Elements zu prüfen, können doppelte Elemente erstellt werden. Außerdem gibt das System möglicherweise einen HTTP 400-Fehler zurück, wenn das Element eindeutig sein muss.

Wenn ein Löschvorgang wiederholt wird, ohne das Vorhandensein des Element zu prüfen, gibt das System möglicherweise einen HTTP 400-Fehler zurück, wenn es das Element nicht finden kann.

Weitere Informationen

Konzepte

ACS-Fehlercodes
ACS-Diensteinschränkungen
ACS-Verwaltungsdienst
Vorgehensweise: Anfordern eines Token von ACS über das OAuth WRAP-Protokoll
Codebeispiel: OAuth 2.0-Zertifikatauthentifizierung
ACS-Richtlinienindex