Specifica il risultato dell'accesso, non solo una casella di controllo SSO
Il requisito secondo cui una piattaforma di autenticazione supporta il Single Sign-On SAML è incompleto a meno che non spieghi chi dovrebbe entrare in quale tenant, con quali autorizzazioni e cosa succede quando il loro ruolo o impiego cambia. L'autenticazione riuscita stabilisce un'asserzione di identità nell'ambito di una relazione federativa concordata. Non autorizza automaticamente ogni dominio, cliente, report o azione amministrativa nell'applicazione. Le revisioni degli appalti e dell'implementazione dovrebbero quindi testare il risultato dell'accesso piuttosto che accettare un accesso riuscito come requisito completo.
Questo articolo è un quadro di requisiti proposto. Non afferma che EmailAuth implementi SAML, provisioning just-in-time, ruoli particolari o qualsiasi funzionalità di controllo della sessione. Non è stato configurato alcun provider di identità, non è stata inviata alcuna asserzione o non è stato concesso l'accesso. Documentazione del protocollo SAML di Microsoft fornisce una descrizione ufficiale concreta di uno scambio supportato da Entra, mentre i criteri di accettazione proposti richiedono ancora la conferma rispetto alla piattaforma e al fornitore di identità effettivi.
Associare la federazione all'applicazione e al tenant previsti
Documentare il provider di identità, il fornitore di servizi, il tenant previsto, l'amministratore della federazione approvato e il proprietario della configurazione. Registra l'identificatore dell'applicazione e l'endpoint del consumatore di asserzione dalle prove di configurazione approvate, senza copiare le credenziali o completare asserzioni sensibili in un foglio di lavoro generale. La documentazione Entra descrive l'emittente, il pubblico, la correlazione della risposta e gli elementi di conferma del soggetto. Queste non sono etichette intercambiabili: un'asserzione destinata ad un'applicazione non dovrebbe diventare autorità per un'applicazione diversa semplicemente perché ha una firma valida.
Richiedere l'effettiva implementazione per convalidare gli elementi del protocollo appropriati al flusso supportato, inclusa la fiducia nell'emittente e nel materiale di firma, il pubblico e il destinatario previsti, le condizioni di validità e la correlazione delle richieste ove applicabile. Non inventare una singola ricetta di convalida che copra ogni flusso o libreria avviata. Chiedi al fornitore di documentare i flussi supportati e i controlli di sicurezza, quindi verificali in un ambiente isolato autorizzato. Una risposta XML di esempio nella documentazione non costituisce la prova che la piattaforma di destinazione applichi tali controlli.
Mantieni separate l'autenticazione e l'autorizzazione
Linee guida sull'identità multi-tenant di Azure distingue l'autorizzazione basata sui ruoli e quella basata sulle risorse e mette in guardia contro configurazioni errate della federazione che concedono l'accesso a tenant non desiderati. Utilizzare questa distinzione quando si scrivono i requisiti. Un utente autenticato dal provider di identità di un cliente necessita comunque di una relazione autorizzata con il tenant e le risorse dell'applicazione corretti. Il solo suffisso dell'indirizzo e-mail non deve essere trattato come una decisione completa sulla locazione o sul ruolo senza una mappatura approvata e documentata.
Specificare i ruoli consentiti e l'ambito delle risorse indipendentemente dal metodo di accesso. Un visualizzatore di report può leggere i domini selezionati ma non esportare tutti i clienti; un amministratore tenant può gestire i membri senza modificare le impostazioni di un altro tenant. Definire chi può stabilire o modificare tali mappature e come vengono esaminate le modifiche. Se vengono utilizzati attributi di gruppo o di ruolo, documentarne l'origine, i valori accettati e il comportamento quando gli attributi sono assenti o imprevisti. Si tratta di controlli proposti, non di affermazioni sul modello di ruolo di un particolare prodotto.
Definire il comportamento di unione e cambio di ruolo
Per un nuovo utente, indicare se è necessario effettuare il provisioning dell'account in anticipo o se è consentito il comportamento just-in-time supportato. Documentare come viene selezionato il tenant previsto e se è necessaria l'approvazione prima che la prima sessione possa accedere ai dati. Non dedurre il provisioning automatico dalla disponibilità dell'autenticazione SAML. Il fornitore deve identificare il comportamento effettivo del ciclo di vita supportato ed eventuali differenze tra accesso amministrativo, interattivo e API.
Per le modifiche ai ruoli, specificare quando le nuove autorizzazioni dovrebbero avere effetto e come vengono gestite le sessioni esistenti. Un requisito dovrebbe distinguere la rimozione di un ruolo dalla disabilitazione di un account. Dovrebbe inoltre indicare se le decisioni di autorizzazione memorizzate nella cache vengono aggiornate e come verrà controllato il risultato osservato. Evitare di dare per scontato che una nuova asserzione al successivo accesso aggiorni ogni sessione già attiva. Conservare la prova effettiva delle azioni consentite e negate dopo una modifica quando viene infine eseguito il test autorizzato.
Rendere esplicita la disabilitazione e la gestione della sessione
L'account del fornitore di identità di un dipendente può essere disabilitato mentre la sessione del fornitore di servizi rimane attiva in base al comportamento dell'applicazione. I requisiti devono chiedere come vengono trattate le sessioni esistenti, i dispositivi ricordati, gli account di fallback locali e le credenziali non interattive. La disponibilità SSO non costituisce di per sé una garanzia universale di disconnessione o di revoca. Richiedere al fornitore di descrivere i meccanismi di revoca supportati, le limitazioni previste e le prove necessarie per verificarli.
Separare l'offboarding di routine dal contenimento di emergenza. Le modifiche di routine possono seguire la sincronizzazione pianificata del ciclo di vita; un incidente può richiedere a un amministratore autorizzato di revocare tempestivamente l'accesso attraverso un diverso percorso supportato. Questo articolo non esegue né approva tali modifiche alla sicurezza. Propone che la loro proprietà e i criteri di verifica siano documentati prima dell'adozione, piuttosto che scoperti durante un incidente quando il team presume che sia sufficiente disabilitare l'account del fornitore di identità.
Un foglio di lavoro per l'accettazione dell'SSO
Crea un foglio di lavoro con il riferimento alla configurazione del fornitore di identità, il tenant del fornitore di servizi, l'identità del test utente, il ruolo previsto, l'ambito delle risorse, il flusso supportato e il risultato previsto. Aggiungi righe per l'adesione, l'aumento del ruolo, la riduzione del ruolo, la disabilitazione, il comportamento della sessione attiva e qualsiasi percorso di ripristino locale approvato. Registra chi autorizza ogni prova e quale ambiente contiene le apparecchiature. Non includere password reali, cookie di sessione, chiavi di firma private o asserzioni di produzione complete nel foglio di lavoro.
Includere casi negativi che dimostrino i limiti: un'identità destinata a un altro tenant non deve ottenere l'accesso, un visualizzatore non deve ricevere privilegi amministrativi e un ruolo rimosso non deve rimanere silenziosamente efficace oltre il comportamento documentato. Formulateli come criteri di accettazione finché non esistono risultati effettivi. Un test fallito dovrebbe registrare l'azione e la risposta osservata senza dare per scontato che l'errore sia stato applicato in modo sicuro semplicemente perché l'interfaccia nascondeva un pulsante. L'autorizzazione lato server necessita di prove proprie.
Diagnosi fittizia: l'accesso riesce ma l'ambito è sbagliato
Un'organizzazione fittizia valuta una piattaforma per due team di clienti. Entrambi utilizzano lo stesso provider di identità aziendale, ma i tenant delle applicazioni devono rimanere separati. Una dimostrazione iniziale mostra l'SSO riuscito e un dashboard di report. Il revisore nota che la dimostrazione non ha mai stabilito a quale tenant fosse vincolato l'utente di prova o se una sessione esistente manterrebbe un ruolo dopo la rimozione.
Il follow-up proposto è un test autorizzato basato su dispositivi che controlla separatamente il vincolo del tenant, la riduzione del ruolo e la disabilitazione. Un accesso riuscito conterebbe solo per la parte di autenticazione del requisito. Nessun test di questo tipo è stato eseguito qui e la piattaforma fittizia non è un'accusa su EmailAuth o un altro servizio denominato. L'esempio spiega perché una dimostrazione SSO apparentemente completa può lasciare senza risposta le domande sull'accesso al materiale.
Richiedere prove prima di accettare la capacità
Una risposta utile del fornitore identifica i flussi di protocollo supportati, le integrazioni del ciclo di vita, la mappatura dei ruoli, il comportamento della sessione, l'accesso fallback e le prove di audit. Inoltre indica chiaramente le limitazioni. Non convertire una dichiarazione della roadmap o uno screenshot in una prova di implementazione. Preservare la versione del prodotto e il contesto di configurazione in modo che il risultato dell'accettazione rimanga interpretabile dopo una modifica del fornitore.
Il catalogo richiede il test dell'unione, del cambio di ruolo, della disabilitazione e della gestione della sessione attiva con il supporto della piattaforma attuale. Quella prova originale rimane aperta. Questa bozza fornisce i requisiti proposti e un esercizio fittizio, non i risultati dei test. Sono aperte anche la revisione specialistica umana, l'applicabilità della fonte, i percorsi di produzione, l'accessibilità e il rilascio del proprietario. La pubblicazione e qualsiasi dichiarazione di capacità richiedono osservazioni autorizzate della piattaforma effettiva anziché deduzioni dalla sola documentazione SAML.