Shibbolethユーザー属性の暗号化
Shibbolethは、サードパーティがIdPとSPの間で交換されるSAML 2.0アサーションに含まれるユーザー属性にアクセスできないことをどのように保証しますか？
IdPからSPに転送されるときにすべてのユーザー属性が暗号化されることは正しいですか？ユーザー属性は、アサーションにも含まれているがSPの公開鍵で暗号化されている対称鍵で暗号化されていますか？
私が掘ることができる最高のものはここにありました：
セキュリティが提供されているようです：
IdPは、SPが送信される方法に基づいて、それに与えるものを制限します
はい、SAML 2.0アサーションの場合、IdPはSPへの応答を暗号化します
これが書かれている方法では、暗号化はすべてではなく、SAML 2.0アサーションでのみ提供されているようです。そして、SAML 2.0をサポートしているように見えるShibboleth 2.0のドキュメントを具体的に読んでいます。
Shibbolethをしばらく使っていなかったので、以下が常に当てはまるかどうかはわかりませんが、過去にShibbolethを使用したことがあるのはここです。
SPは、（署名された）SAMLリクエストをIdPに送信します。これは、ユーザーのブラウザによって2つの間で伝播されます。IdPは、識別子を使用して、必ずしも暗号化されていない、署名されたSAMLレスポンスを提供します。受信、SPはIdPに直接属性要求を行います。
このバックエンド接続は通常HTTPSを介して行われるため、接続は暗号化されます。ユーザーのブラウザからはまったくアクセスできませんが、SPはIdPへの直接のクライアントになります。ここでは、SSL/TLSに加えてメッセージレベルの暗号化を使用しても、それほど追加されません。 SPが適切に認証されている場合はもちろん、これはクライアント証明書認証を使用して実行できます（SP CredentialResolver IIRCを使用して構成されています） 。
これは この図 （英国連邦）のステップ6と7で表されます。
Shibboleth 1.xとShibboleth 2.x の間で、属性サービスの構成（通常はIdPで実行され、SPによってクエリされる）にわずかな違いがある場合があります。これらの属性サービスは、SPに提供されるフェデレーションメタデータの一部として、他のIdP設定とともに構成されます。
私の知る限り、このメカニズムは、他のSAMLベースのシステムと比較して、Shibbolethの特徴の1つです。