DataSealer dependencies

[Andrew Morgan]

On Tue, 8 Mar 2016, Paul B. Henson wrote:

>> From: Cantor, Scott
>> Sent: Monday, March 07, 2016 12:27 PM
>>
>> - client-side storage (*)
>> - crypto strategy for transient IDs (*)
>> - serialization of passwords saved into authentication results
>> - a logout dependency that I think is baked in but not actually being used
>
> I'm using server-side storage for sessions, and the StoredTransientIdGenerator, which takes care of the first two deps. I'm not sure about the third use case? How does that use the data sealer key exactly? For now, I guess I need to keep it around just so the idp will run :). But do I need to rotate it for security purposes? Do I need to replicate it between cluster members?
>
>> I would suggest filing a bug and we can maybe figure out how to get
>> everything to start up safely if none of the features are being used.
>
> IDP-942, thanks much.

I hope I'm not hijacking this thread too much... Is data stored in the IDP 
server-side session (specifially, shibboleth.MemcachedStorageService) 
encrypted?

We intend to start using memcache soon to support the CAS protocol in 
Shibboleth.  We are also looking to distribute our IDP nodes on various 
networks, including out in the cloud.  Is there any sensitive information 
stored in the IDP session?  Should we be concerned about the cleartext 
connection from the IDP to memcache?

Does anyone have recommendations to deploy the IDP around the world?

Thanks,
 	Andy