Qualcuno può spiegarmi quali sono le principali differenze tra SSO avviato da SP e SSO avviato da IDP , inclusa quale sarebbe la soluzione migliore per l'implementazione del Single Sign-On in combinazione con ADFS + OpenAM Federation?
Qualcuno può spiegarmi quali sono le principali differenze tra SSO avviato da SP e SSO avviato da IDP , inclusa quale sarebbe la soluzione migliore per l'implementazione del Single Sign-On in combinazione con ADFS + OpenAM Federation?
Risposte:
In IDP Init SSO (Unsolicited Web SSO) il processo di federazione viene avviato dall'IDP che invia una risposta SAML non richiesta all'SP. In SP-Init, l'SP genera un AuthnRequest che viene inviato all'IDP come primo passaggio nel processo di federazione e l'IDP risponde quindi con una risposta SAML. Il supporto IMHO ADFSv2 per SAML2.0 Web SSO SP-Init è più forte del suo supporto IDP-Init re: integrazione con prodotti Fed di terze parti (principalmente ruotano attorno al supporto per RelayState) quindi se hai una scelta ti consigliamo di utilizzare SP- Iniziare perché probabilmente renderà la vita più facile con ADFSv2.
Ecco alcune semplici descrizioni SSO dalla Guida introduttiva di PingFederate 8.0 che puoi sfogliare che potrebbero essere utili: https://documentation.pingidentity.com/pingfederate/pf80/index.shtml#gettingStartedGuide/task/idpInitiatedSsoPOST.html
SSO avviato da IDP
Dalla documentazione di PingFederate: - https://docs.pingidentity.com/bundle/pf_sm_supportedStandards_pf82/page/task/idpInitiatedSsoPOST.html
In questo scenario, un utente è connesso all'IdP e tenta di accedere a una risorsa su un server SP remoto. L'asserzione SAML viene trasportata all'SP tramite HTTP POST.
Fasi di elaborazione:
SSO avviato da SP
Dalla documentazione di PingFederate: - http://documentation.pingidentity.com/display/PF610/SP-Initiated+SSO--POST-POST
In questo scenario un utente tenta di accedere a una risorsa protetta direttamente su un sito Web SP senza essere connesso. L'utente non dispone di un account sul sito SP, ma dispone di un account federato gestito da un IdP di terze parti. L'SP invia una richiesta di autenticazione all'IdP. Sia la richiesta che l'asserzione SAML restituita vengono inviate tramite il browser dell'utente tramite HTTP POST.
Fasi di elaborazione:
Ulteriori informazioni sull'utente possono essere recuperate dall'archivio dati utente per l'inclusione nella risposta SAML. (Questi attributi sono predeterminati come parte dell'accordo di federazione tra IdP e SP)
Il servizio SSO dell'IdP restituisce un modulo HTML al browser con una risposta SAML contenente l'asserzione di autenticazione e qualsiasi attributo aggiuntivo. Il browser invia automaticamente il modulo HTML all'SP. NOTA: le specifiche SAML richiedono che le risposte POST siano firmate digitalmente.
(Non mostrato) Se la firma e l'asserzione sono valide, l'SP stabilisce una sessione per l'utente e reindirizza il browser alla risorsa di destinazione.
Bill l'utente: "Hey Jimmy, mostrami quel rapporto"
Jimmy the SP: "Ehi, non sono ancora sicuro di chi sei. Abbiamo un processo qui, quindi vai prima a farti verificare con Bob l'IdP. Mi fido di lui."
Bob l'IDP: "Vedo che Jimmy ti ha mandato qui. Per favore, dammi le tue credenziali."
Bill l'utente: "Ciao sono Bill. Ecco le mie credenziali."
Bob the IdP: "Ciao Bill. Sembra che tu abbia controllato."
Bob the IdP: "Ehi Jimmy. Questo ragazzo Bill controlla ed ecco alcune informazioni aggiuntive su di lui. Fai quello che vuoi da qui."
Jimmy the SP: "Ok, fantastico. Sembra che Bill sia anche nella nostra lista di ospiti conosciuti. Lascio entrare Bill."
Bill l'utente: "Ehi Bob. Voglio andare a casa di Jimmy. La sicurezza laggiù è stretta."
Bob l'IDP: "Ehi Jimmy. Mi fido di Bill. Controlla ed ecco alcune informazioni aggiuntive su di lui. Fai quello che vuoi da qui."
Jimmy the SP: "Ok, fantastico. Sembra che Bill sia anche nella nostra lista di ospiti conosciuti. Lascio entrare Bill."
Vado più in dettaglio qui, ma mantenendo le cose semplici: https://jorgecolonconsulting.com/saml-sso-in-simple-terms/ .