No he usado Shibboleth por un tiempo, así que no estoy seguro de que siempre sea así, pero aquí es cómo he usado Shibboleth en el pasado.
El SP realiza una solicitud SAML (firmada) al IdP, que se propaga entre los dos por el navegador del usuario. El IdP da una respuesta SAML firmada, no necesariamente encriptada, con un identificador. Tras la recepción, el SP realiza una solicitud de atributo directamente al IdP.
Esta conexión de back-end generalmente se realiza a través de HTTPS y, por lo tanto, la conexión está encriptada. No funciona en absoluto a través del navegador del usuario, pero el SP se convierte en un cliente directo para el IdP. El uso de cifrado a nivel de mensaje sobre SSL / TLS aquí no agregaría mucho, si el SP se autentica correctamente, por supuesto, esto se puede hacer usando la autenticación de certificado de cliente (configurada en el SP usando CredentialResolver
IIRC).
Esto se representa en los pasos 6 y 7 en este diagrama (Federación del Reino Unido).
Puede haber pequeñas diferencias en la configuración del Servicio de Atributos (generalmente se ejecuta en el IdP y se consulta por el SP) entre Shibboleth 1.xy Shibboleth 2.x . Estos servicios de atributos se configuran junto con las otras configuraciones de IdP como parte de los metadatos de federación dados a los SP.
Que yo sepa, este mecanismo es una de las especificidades de Shibboleth, en comparación con otros sistemas basados en SAML.