Non ho usato Shibboleth per un po ', quindi non sono sicuro che il caso sia sempre il seguente, ma ecco come ho usato Shibboleth in passato.
L'SP effettua una richiesta SAML (firmata) all'IdP, che viene propagato tra i due dal browser dell'utente. L'IdP fornisce una risposta SAML firmata, non necessariamente crittografata, con un identificatore. Alla ricezione, l'SP inoltra direttamente una richiesta di attributo all'IdP.
Questa connessione back-end viene solitamente eseguita tramite HTTPS e la connessione viene pertanto crittografata. Non va affatto attraverso il browser dell'utente, ma l'SP diventa un cliente diretto all'IdP. L'uso della crittografia a livello di messaggio su SSL / TLS qui non aggiungerebbe molto, se l'SP è autenticato correttamente, naturalmente, questo può essere fatto usando l'autenticazione del certificato client (configurato nel SP usando CredentialResolver
IIRC).
Questo è rappresentato nei passaggi 6 e 7 in questo diagramma (Federazione del Regno Unito).
Potrebbero esserci leggere differenze nella configurazione del servizio attributo (solitamente eseguito sull'IdP e interrogato dall'SP) tra Shibboleth 1.xe Shibboleth 2.x . Questi servizi di attributo sono configurati insieme alle altre impostazioni IdP come parte dei metadati della federazione forniti agli SP.
Per quanto ne so, questo meccanismo è una delle specificità di Shibboleth, rispetto ad altri sistemi basati su SAML.