Il ruolo principale di IdP è quello di "autenticare" l'identità rivendicata dall'utente e assicurare all'SP che l'identità dell'utente sia stata verificata.
Per questo, (più comunemente), la password deve essere verificata dall'IdP e quindi viene archiviata con l'IdP.
In un sistema correttamente implementato, l'SP non dovrebbe mai essere in grado di "accedere" alla password e / o a qualsiasi altro meccanismo utilizzato per verificare l'identità dell'utente. Quindi non viene mai memorizzato con SP.
Come funziona:
Tipicamente, l'IdP fornisce all'utente un token verificabile che indica a un SP che è stata eseguita correttamente un'autenticazione. L'utente lo trasferisce all'SP come "prova di autenticazione riuscita". Inutile dire che l'SP non prende la parola dell'utente per questo. Pertanto, l'SP verifica questo token con l'IdP e solo dopo aver verificato che il token è valido, procede al passaggio successivo (di solito il passaggio di autorizzazione).
In caso di compromissione dell'IdP:
Sì, un compromesso dal lato IdP ha un impatto maggiore. Tuttavia, l'IdP non ha bisogno di conoscere tutte le credenziali necessarie per accedere all'applicazione SP. Quindi un'applicazione SP attentamente progettata utilizzerebbe almeno un attributo dell'utente; e non usare solo il token per aprire l'accesso. L'IdP non sarebbe a conoscenza di tale attributo e quindi non sarebbe in grado di accedere all'app SP, mascherandosi da utente. Si spera che questo non sia troppo ingegnerizzato a livello di autenticazione.
Tuttavia, devo confessare che non l'ho visto in pratica. La maggior parte delle SP è grata solo per far funzionare l'integrazione con l'IdP abbastanza bene e lasciare che sia così. :)
suggerisce che la password sia memorizzata sull'IdP (talentlms).