Shibboleth Developers

[Chad La Joie <>]

Whether encryption is used is unrelated.  If you provide an encryption
key it will, be default, encrypt; if you don't, it won't.

I personally feel that the concerns about front-channel, unencrypted,
attribute push are spurious.  All the information is being encrypted in
transit (since it's over SSL/TLS).  The idea that the user seeing their
attributes being a problem seems silly to me.

The only semi-valid concern I've heard voiced is that the browser might
cache the information and someone else might come along and see it.  The
code does what it can to prevent this (by using all the "do not cache"
headers it can) but really, if you don't trust your browser...  why are
you putting your credentials into it initially?  Or, if you trust that
it handles the credentials properly but caching improperly, why aren't
you concerned that it's caching the data being accessed? It is likely
more sensitive than the attributes themselves.

Ian Young wrote:
> Chad La Joie wrote:
> 
>> By default, the Shibboleth 2.0 IdP pushes attributes.  It can be
>> configured to not do this on a per relying party (or relying party
>> group) basis.
> 
> Tangential question: do you actually mean what you say here, or do you
> mean that the Shibboleth 2.0 IdP pushes attributes *if the SP can be
> sent attributes in an encrypted form* ?
> 
> I'd be a little concerned by a default configuration that sent
> unencrypted attributes through the front channel.
> 
>       -- Ian

-- 
Chad La Joie             2052-C Harris Bldg
OIS-Middleware           202.687.0124