Linee guida sulla ripetizione dei tentativi per ACS

  • Articolo

Aggiornamento: 6 luglio 2015

Si applica a: Azure

Microsoft Azure Active Directory Controllo di accesso (noto anche come servizio Controllo di accesso o ACS) supporta diversi endpoint di rilascio e gestione dei token a cui i client possono inviare richieste di token. Questo argomento definisce le linee guida per l'implementazione della logica di retry in caso di esito negativo delle richieste di token.

Scenari di gestione degli errori

Gli errori di richiesta di token che restituiscono codici di errore della serie HTTP 500 si risolvono in genere con la ripetizione dei tentativi. In alcuni scenari, il client è un'applicazione o un servizio che effettua richieste automatizzate a ACS. In altri scenari, ad esempio una federazione basata sul Web che usa il protocollo WS-Federation, il client è un Web browser e l'utente finale deve eseguire nuovamente l'operazione manualmente. Questo argomento descrive gli scenari di gestione degli errori in cui il client è un'applicazione o un servizio.

Tali scenari includono:

Linee guida sulla ripetizione dei tentativi

Le seguenti linee guida spiegano come implementare la logica di ripetizione dei tentativi negli scenari di gestione degli errori.

Linee guida 1: Implementare la logica di ripetizione dei tentativi in base alle risposte di errore della serie HTTP 500

La logica di ripetizione dei tentativi è fortemente consigliata quando ACS restituisce errori della serie HTTP 500. Il seguente elenco include esempi di errori della serie HTTP 500 tipici.

  • Errore HTTP 500 - Errore interno del server

  • Errore HTTP 502 - Gateway non valido

  • Errore HTTP 503 - Servizio non disponibile

  • Errore HTTP 504 - Timeout del gateway

Anche se nella logica di retry è possibile enumerare singolo codici HTTP, è sufficiente richiamare tale logica se viene restituito qualsiasi errore della serie HTTP 500.

La logica di ripetizione dei tentativi deve essere attivata da codici di errore HTTP, ad esempio HTTP 504 (timeout del server esterno) e non da codici di errore ACS, ad esempio ACS90005. I codici errore ACS sono informativi e soggetti a modifiche.

In genere, non è consigliabile usare la logica di ripetizione dei tentativi quando vengono restituiti errori della serie HTTP 400. Un codice di risposta di errore HTTP della serie 400 restituito da ACS indica che la richiesta non è valida e deve essere modificata. Un'eccezione è rappresentata dal codice di errore 429 ("Numero eccessivo di richieste"), che indica che lo spazio dei nomi ha superato il limite di frequenza della richiesta di token per un periodo prolungato. Per gli errori 429, i tentativi con un timer di backoff possono risolvere il backlog della richiesta di token immediata finché l'amministratore non avrà la possibilità di verificare e modificare la distribuzione del carico di lavoro dello spazio dei nomi. Per altre informazioni, vedere Limitazioni del servizio ACS.

Linea guida n. 2: I tentativi devono usare un timer di back-off per un controllo del flusso ottimale

Quando un client riceve un errore della serie HTTP 500, deve attendere un periodo di tempo determinato prima di eseguire un nuovo tentativo della richiesta. Per ottenere risultati ottimali, è consigliabile che questo intervallo di tempo aumenti per ogni tentativo successivo. Questo approccio consente di risolvere rapidamente gli errori temporanei ottimizzando al tempo stesso la frequenza delle richieste per gli errori di rete o del server temporanei con tempi di risoluzione più lunghi.

Usare ad esempio un timer di backoff esponenziale in cui il ritardo che precede il tentativo aumenta in modo esponenziale con ogni istanza, ad esempio 1 secondo per il tentativo 1, 2 secondi per il tentativo 2, 4 secondi per il tentativo 3 e così via.

Regolare il numero di tentativi e l'intervallo di tempo tra i singoli tentativi in base ai requisiti dell'esperienza utente. È tuttavia consigliabile eseguire fino a cinque tentativi in un periodo di cinque minuti. Gli errori causati da un timeout presentano tempi di risoluzione più lunghi.

Linea guida 3: Verificare che l'elemento non esista prima di tentare di crearlo o eliminarlo

Quando si eseguono operazioni di creazione o eliminazione con il servizio di gestione ACS, ad esempio la creazione di una nuova applicazione relying party o l'eliminazione di una regola, la logica di ripetizione dei tentativi deve eseguire una query se l'elemento esiste prima di eseguire l'operazione. In alcuni casi, ad esempio un errore di rete temporaneo che si verifica durante il recapito della risposta del server, un'operazione di creazione o eliminazione può avere esito positivo anche quando il client riceve una risposta di errore.

Se si esegue un nuovo tentativo di un'operazione di creazione senza verificare l'esistenza dell'elemento, è possibile che vengano creati elementi duplicati. È inoltre possibile che il sistema restituisca un errore HTTP 400 se l'elemento deve essere univoco.

Se si esegue un nuovo tentativo di un'operazione di eliminazione senza verificare l'esistenza dell'elemento, è possibile che il sistema restituisca un errore HTTP 400 se non riesce a trovare l'elemento.

Vedere anche

Concetti

Codici di errore di ACS
Limitazioni del servizio ACS
Servizio di gestione ACS
Procedura: Richiedere un token da ACS tramite il protocollo OAuth WRAP
Esempio di codice: Autenticazione del certificato OAuth 2.0
Indice delle linee guida di ACS