Diese Dokumentation wurde archiviert und wird nicht länger gepflegt.

ACS-Wiederholungsrichtlinien

Veröffentlicht: Januar 2013

Letzte Aktualisierung: Juli 2015

Betrifft: Azure

Zugriffssteuerung für Microsoft Azure Active Directory (auch Zugriffssteuerungsdienst oder ACS) unterstützt eine Reihe verschiedener Endpunkte zur Ausstellung und Verwaltung von Token, an die Clients Tokenanforderungen senden können. Dieses Thema definiert Leitlinien zum Implementieren von Wiederholungslogik für den Fall von Fehlern bei Tokenanforderungen.

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 automatische Anforderungen an ACS ausführt. 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:

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

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

  • HTTP-Fehler 500 – Interner Serverfehler

  • HTTP-Fehler 502 – Ungültiges 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.

Wiederholungslogik sollte von HTTP-Fehlercodes, wie etwa HTTP 504 (Timeout eines externen Servers), aufgerufen werden, nicht von ACS-Fehlercodes, wie etwa ACS90005. ACS-Fehlercodes dienen nur zu Informationszwecken und unterliegen Änderungen.

Normalerweise wird Wiederholungslogik für zurückgegebene Fehlercodes der HTTP-Serie 400 nicht empfohlen. Ein HTTP-Fehler der Serie 400 von ACS bedeutet, dass die Anforderung ungültig ist und revidiert 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-Diensteinschränkungen.

Wenn ein Client einen Fehler der HTTP-Serie 500 empfängt, sollte der Client einen angegebenen Zeitraum abwarten, bevor er die Anforderung wiederholt. Zum Erzielen optimaler Ergebnisse empfiehlt es sich, diesen Zeitraum mit jeder folgenden Wiederholung zu verlängern. Dieser Ansatz ermöglicht eine schnelle Behebung vorübergehender Fehler, während die Anforderungsrate bei vorübergehenden Netzwerk- oder Serverproblemen, deren Behebung längere Zeit dauert, optimiert wird.

Verwenden Sie beispielsweise einen exponentiellen Wartezeit-Zeitgeber, bei dem sich die Verzögerung vor der Wiederholung für jede Instanz exponentiell erhöht, wie etwa Wiederholung 1: 1 Sekunde, Wiederholung 2: 2 Sekunden, Wiederholung 3: 4 Sekunden usw.

Passen Sie die Anzahl der Wiederholungen und die Zeit zwischen den Wiederholungsversuchen auf der Grundlage der Anforderungen an das Bedienverhalten an. Wir empfehlen jedoch bis zu fünf Wiederholungsversuche über einen Zeitraum von fünf Minuten. Die Behebung von durch eine Zeitüberschreitung verursachten Fehlern kann länger dauern.

Beim Durchführen von Erstellungs- oder Löschvorgängen mit dem ACS-Verwaltungsdienst, wie etwa beim Erstellen einer neuen Anwendung für die vertrauende Seite oder beim Löschen einer Regel, sollte die Wiederholungslogik abfragen, ob das Element vorhanden ist, bevor sie den Vorgang ausführt. Unter bestimmten Umständen, etwa bei einem vorübergehenden Netzwerkausfall, er während der Übermittlung der Serverantwort auftritt, kann ein Erstellungs- oder Löschvorgang auch dann 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.

Siehe auch

Anzeigen: