Shibboleth Developers

[Ian Young <>]

On 26 Aug 2010, at 06:10, Nate Klingenstein wrote:

> Jim,
> 
> They're encrypted for both legs of the transaction, but because there is no 
> encryption of the response or assertion themselves, the attributes pass 
> through the browser and the client in cleartext.  Some have concerns about 
> malware, privacy on shared computers, or the sharing of attributes that 
> were not meant to be revealed to the principal.  I find such concerns 
> understandable, myself.

These are one group of relevant concerns, certainly.  I think the one that 
concerns me most these days, though, is the observation that in this case 
security moves away from being established by specific security software like 
Shibboleth mediated by trusted metadata, and instead becomes dependent on the 
browser's implementation of TLS and PKIX.  In particular, you move away from 
only delivering attribute values through a SAML transaction in which the SP's 
credential has to match trusted metadata over to a situation where any of the 
*browser's* trust roots can be targeted.  And that's before you take into 
account unpatched browser bugs and attackers just relying on the user to 
click "it's fine, continue" to security warnings.

Even without an assumption that the user's browser can be compromised, 
therefore, attributes passed through the front channel using point-to-point 
encryption are *not* as secure as attributes passed across the back channel.  
Obviously in SAML 2, you can and should use end-to-end encryption to secure 
the front channel.

        -- Ian

Attachment: smime.p7s
Description: S/MIME cryptographic signature