SSO avviato SP e IdP

In questo articolo vengono illustrati i concetti di SP e SSO avviato da IdP tra due distribuzioni della federazione e le differenze tra questi due flussi.

Questo articolo spiega inoltre il concetto di stato utente o URL di restituzione condiviso tra IdP e SP durante l'SSO federativo, che viene chiamato:

• RelayState per SAML 2.0 TARGET per SAML 1.1 wctx per WS-Fed 1.1

• openid.return_to per OpenID 2.0 (la restituzione di SSO

• L'URL può contenere un parametro di query che rappresenta lo stato dell'utente nel punto di fornitura)

In questo articolo vengono mostrati esempi che utilizzano il protocollo SAML 2.0, sebbene lo stesso sia valido per gli altri protocolli.

Flussi SSO Federation

Topologia

Una distribuzione tipica di Federation è costituita dalle entità riportate di seguito.

• Un dominio di sicurezza per il server IdP, in cui l'utente dispone di un account e in cui viene eseguita l'autenticazione

• Un dominio di sicurezza per il server SP con

  • Un server di federazione SP

  • Un server SSO (a volte il server SSO e il server SP Federation sono la stessa entità)

  • Agenti Web SSO integrati con il server SSO, che proteggono le risorse e garantiscono che l'utente sia autenticato e autorizzato ad accedere a una risorsa. Se non si esegue questa operazione, potrebbe verificarsi un flusso di autenticazione o un errore di autorizzazione

  • Risorse o applicazioni Web

  

  Descrizione dell'immagine Federation_deployment_Screen.jpg

SSO avviato da SP

Un flusso SSO avviato da SP è un'operazione SSO Federation avviata dal dominio di sicurezza SP, dal server SP Federation che crea una richiesta di autenticazione Federation e reindirizza l'utente a IdP con il messaggio e una breve stringa che rappresenta lo stato dell'operazione:

• La richiesta di autenticazione della federazione varia a seconda del protocollo utilizzato:

  • SAML 2.0: AuthnRequest

  • SAML 1.1: URL con un parametro che rappresenta l'SP

  • WS-Fed: URL con un parametro wtrealm che rappresenta il processore di servizio e altri parametri facoltativi

  • OpenID 2.0: OpenID 2.0 Richiesta

• Lo stato dell'operazione (operazione eseguita dall'utente prima dell'avvio dell'operazione SSO Federation) viene trasmesso nel messaggio inviato all'utente IdP, non come stato intero, ma come puntatore allo stato nella memoria runtime del server SP. Queste informazioni vengono trasmesse in modo diverso a seconda del protocollo:

  • SAML 2.0: parametro RelayState

  • SAML 1.1: parametro TARGET

  • WS-Fed: parametro wctx

  • OpenID 2.0: parametro openid.return_to che è un URL SP in cui l'utente viene reindirizzato dopo l'autenticazione in IdP, generato in fase di esecuzione dal processore di servizio, e può contenere un parametro di query che fa riferimento a uno stato operativo

Nota sullo stato operativo: in genere, lo stato condiviso nel messaggio non deve essere troppo lungo, poiché potrebbe interrompere i flussi di reindirizzamento con la lunghezza dell'URL di reindirizzamento superiore alla lunghezza massima che i browser possono gestire per gli URL. Pertanto, è sempre preferibile che durante SSO avviato da SP disponga dell'SP

• Memorizzare lo stato operativo in memoria/storage DB nel processore di servizio

• Inviare come RelayState/TARGET/wctx un puntatore allo stato operativo

Esistono due modi per attivare un flusso SSO avviato da SP:

• L'utente richiede l'accesso a una risorsa, che avvia un flusso SSO Federation. Una volta eseguita l'operazione SSO Federation, l'utente verrà reindirizzato alla risorsa richiesta in primo luogo.

• In alternativa, l'utente accede direttamente a un servizio nel server SP per avviare in modo specifico un flusso SSO Federation con un IdP remoto. In questo caso, in genere l'utente fornisce l'URL al quale deve essere reindirizzato dopo l'esecuzione dell'operazione SSO Federation

Accesso a una risorsa

Si tratta del flusso più comune per le operazioni SSO Federation, in cui l'utente tenta di accedere a una risorsa protetta e il sistema SSO in fase di esecuzione determina che l'utente deve essere autenticato tramite SSO Federation.

I casi d'uso in cui viene utilizzato questo flusso possono essere:

• L'utente fa clic su un collegamento in qualsiasi pagina che fa riferimento alla risorsa protetta

• L'utente fa clic su un collegamento in una pagina del portale che fa riferimento alla risorsa protetta

• L'utente dispone di un segnalibro per la risorsa protetta

Il flusso prevede i passi riportati di seguito.

1. Il browser dell'utente richiede l'accesso a una risorsa protetta

2. L'agente Web SSO intercetta la chiamata, determina che l'utente deve essere autenticato ed esegue un reindirizzamento al browser dell'utente.

3. Il browser dell'utente accede al server SSO, che viene reindirizzato dall'agente Web SSO

4. Il server SSO determina che l'utente deve essere autenticato mediante SSO Federation, seleziona un IdP, crea un messaggio AuthnRequest SAML 2.0, salva lo stato operativo nell'area di memorizzazione del server SSO e reindirizza il browser dell'utente al IdP con il messaggio SAML e una stringa che fa riferimento allo stato operativo nel provider di servizi.

5. Il browser dell'utente accede al servizio SAML 2.0 IdP con il messaggio AuthnRequest.

Descrizione dell'immagine Accessing_Resources_Screen.jpg

Quando IdP riceve il messaggio AuthnRequest di SAML 2.0, il server determina se è necessario eseguire la richiesta di verifica dell'utente (non ancora autenticata, timeout della sessione...). Dopo la possibile identificazione dell'utente, viene ripreso il flusso SSO Federation.

1. IdP crea una risposta SSO con un'asserzione SAML 2.0 contenente le informazioni utente e i dati di autenticazione e reindirizza il browser dell'utente all'SP con il messaggio e il parametro RelayState

2. Il browser dell'utente presenta la risposta SSO al server SP

3. L'SP convalida l'asserzione SAML 2.0 e crea una sessione SSO per l'utente. Il server SSO reindirizza quindi il browser dell'utente alla risorsa richiesta in origine

4. Il browser dell'utente richiede l'accesso alla risorsa. Questa volta l'agente Web SSO concede l'accesso alla risorsa

5. L'applicazione Web restituisce una risposta al browser dell'utente

Descrizione dell'immagine Accessing_Resources_Response_Screen.jpg

Come accennato in precedenza, questo flusso è il più comunemente utilizzato, poiché Federation SSO viene attivato solo dal server SSO in fase di esecuzione, senza che altri componenti nel dominio di sicurezza SP debbano essere a conoscenza di Federation.

Richiamo di un servizio SP di federazione

Questo flusso non è ampiamente utilizzato, in quanto implica che Federation SSO verrà avviato presso l'SP accedendo a un servizio presso il server SP e ignorando qualsiasi sessione valida esistente che l'utente potrebbe già avere. Ciò dovrebbe essere evitato in quanto incide sulle prestazioni:

• I server come SSO Federation sono costosi (XML per alcuni protocolli, firme digitali per proteggere i messaggi, comunicazioni tra i server)

• L'esperienza dell'utente come browser verrà reindirizzata tra domini diversi con conseguente ritardo prima che l'utente possa accedere alla risorsa protetta di destinazione.

I casi d'uso in cui viene utilizzato questo flusso possono essere:

• L'utente fa clic su un collegamento in qualsiasi pagina che fa riferimento alla risorsa protetta (inusuale)

• L'utente fa clic su un collegamento in una pagina del portale che fa riferimento alla risorsa protetta

I casi d'uso in cui viene utilizzato questo flusso prevedono i passi riportati di seguito.

1. Il browser dell'utente accede all'SP per avviare un flusso SSO Federation specificando facoltativamente

   1. URL in cui il browser dell'utente deve essere reindirizzato dopo il completamento di SSO Federation

   2. Il IdP da utilizzare

2. Il server SSO seleziona un IdP se non fornito e seleziona l'URL di restituzione predefinito se non fornito, crea un messaggio AuthnRequest SAML 2.0, salva lo stato operativo nell'area di memorizzazione del server SSO e reindirizza il browser dell'utente a IdP con il messaggio SAML e una stringa che fa riferimento allo stato operativo nell'SP

3. Il browser dell'utente accede al servizio SAML 2.0 IdP con il messaggio AuthnRequest.

Descrizione dell'immagine IdP_Service_with_AuthnRequest_Screen.jpg

Quando IdP riceve il messaggio AuthnRequest di SAML 2.0, il server determina se è necessario eseguire la richiesta di verifica dell'utente (non ancora autenticata, timeout della sessione...). Dopo la possibile identificazione dell'utente, il flusso SSO Federation riprende:

1. IdP crea una risposta SSO con un'asserzione SAML 2.0 contenente le informazioni utente e i dati di autenticazione e reindirizza il browser dell'utente all'SP con il messaggio e il parametro RelayState

2. Il browser dell'utente presenta la risposta SSO al server SP

3. L'SP convalida l'asserzione SAML 2.0 e crea una sessione SSO per l'utente. Il server SSO reindirizza quindi il browser dell'utente alla risorsa richiesta in origine

4. Il browser dell'utente richiede l'accesso alla risorsa. Questa volta l'agente Web SSO concede l'accesso alla risorsa

5. L'applicazione Web restituisce una risposta al browser dell'utente

Descrizione dell'immagine IdP_Service_with_Response_Screen.jpg

Questo flusso dovrebbe essere utilizzato raramente poiché SSO Federation viene attivato in modo statico, anche se l'utente dispone già di una sessione SSO valida. Inoltre, implica che alcuni componenti nel dominio di sicurezza SP siano a conoscenza del servizio SP.

IdP SSO avviato

Un flusso SSO avviato da IdP è un'operazione SSO Federation avviata dal dominio di sicurezza IdP dal server Federation IdP che crea una risposta SSO Federation e reindirizza l'utente al provider di servizi con il messaggio di risposta e uno stato operativo facoltativo.

• La risposta SSO Federation varia a seconda del protocollo utilizzato:

  • SAML 2.0: SAMLResponse con asserzione

  • SAML 1.1: Risposta con asserzione

  • WS-Fed: risposta con asserzione

  • OpenID 2.0: OpenID 2.0 Risposta

• Lo stato dell'operazione facoltativo in questo flusso comunica l'URL al quale l'utente deve essere reindirizzato dopo il completamento dell'SSO federazione nel punto di fornitura. Se manca, l'SP deve determinare dove reindirizzare l'utente. Queste informazioni vengono trasmesse in modo diverso a seconda del protocollo:

  • SAML 2.0: parametro RelayState

  • SAML 1.1: parametro TARGET

  • WS-Fed: parametro wctx OpenID 2.0: questo protocollo non supporta il flusso SSO avviato IdP.

Come indicato nella sezione precedente, lo stato condiviso nel messaggio non deve essere troppo lungo, poiché potrebbe interrompere i flussi di reindirizzamento con la lunghezza dell'URL di reindirizzamento superiore alla lunghezza massima che i browser possono gestire per gli URL.

Questo flusso viene in genere utilizzato quando gli utenti IdP devono accedere alle risorse ospitate da un provider di servizi, ma non è l'approccio migliore per SSO Federation, poiché ignora qualsiasi sessione valida esistente nel provider di servizi che l'utente potrebbe già avere. Ciò dovrebbe essere evitato in quanto incide sulle prestazioni:

• I server come SSO Federation sono costosi (XML per alcuni protocolli, firme digitali per proteggere i messaggi, comunicazioni tra i server)

• L'esperienza dell'utente come browser verrà reindirizzata tra domini diversi con conseguente ritardo prima che l'utente possa accedere alla risorsa protetta di destinazione.

I casi d'uso in cui viene utilizzato questo flusso possono essere:

• L'utente fa clic su un collegamento in una pagina del portale IdP che fa riferimento alla risorsa protetta nell'SP.

I casi d'uso in cui viene utilizzato questo flusso prevedono i passi riportati di seguito.

1. Il browser dell'utente accede a IdP per avviare un flusso SSO Federation specificando

   1. SP da utilizzare

   2. Facoltativamente, l'URL in cui il browser dell'utente deve essere reindirizzato dopo il completamento di SSO Federation

2. Dopo aver identificato l'utente, IdP crea una risposta SSO con un'asserzione SAML 2.0 contenente informazioni utente e dati di autenticazione e reindirizza il browser dell'utente all'SP con il messaggio e il parametro RelayState

3. Il browser dell'utente presenta la risposta SSO al server SP

4. L'SP convalida l'asserzione SAML 2.0 e crea una sessione SSO per l'utente. Il server SSO reindirizza quindi il browser dell'utente alla risorsa richiesta in origine

5. Il browser dell'utente richiede l'accesso alla risorsa. Questa volta l'agente Web SSO concede l'accesso alla risorsa

6. L'applicazione Web restituisce una risposta al browser dell'utente

Descrizione dell'immagine SSO_Response_Screen.jpg

Conclusione

Come mostrato nei vari flussi, l'approccio migliore in una distribuzione di Federation è che Federation SSO venga attivato dal server SSO, in fase di esecuzione, quando lo ritiene necessario dal server SSO. Gli altri casi hanno un approccio statico ed esercitano sempre un flusso SSO Federation, anche se non è necessario (se l'utente ha già una sessione valida ad esempio) e l'esecuzione delle operazioni Federation non necessarie influisce:

• Prestazioni dei server (interazioni CPU, LDAP/RDBMS...)

• Il tempo di risposta dell'utente, in base al tempo necessario per eseguire un'operazione SSO Federation con i reindirizzamenti coinvolti.

Altre risorse di apprendimento

Esplora altri laboratori su docs.oracle.com/learn o visita altri contenuti di formazione gratuiti sul canale Oracle Learning YouTube. Inoltre, visitare education.oracle.com/learning-explorer per diventare un Oracle Learning Explorer.

Per la documentazione sul prodotto, visitare Oracle Help Center.

---

Titolo e informazioni sul copyright

SP vs IdP Initiated SSO

F60244-01

September 2022

Copyright © 2022, Oracle and/or its affiliates.