DataSealer dependencies

[Andrew Morgan]

On Wed, 9 Mar 2016, Cantor, Scott wrote:

> On 3/9/16, 5:06 PM, "users on behalf of Andrew Morgan" <users-bounces at shibboleth.net on behalf of morgan at orst.edu> wrote:
>
>> I hope I'm not hijacking this thread too much... Is data stored in the IDP
>> server-side session (specifially, shibboleth.MemcachedStorageService)
>> encrypted?
>
> Not in general, but there are exceptions.
>
>> 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?
>
> If you store data that shouldn't be exposed in long term storage, like 
> passwords, it's encrypted. Otherwise it's not, but that includes PII 
> (like user identities) and more importantly includes the sessions that 
> allow for SSO.
>
>> Should we be concerned about the cleartext connection from the IDP to 
>> memcache?
>
> I would certainly think so. If it's really that broken, I guess you 
> could tunnel it.
>
>> Does anyone have recommendations to deploy the IDP around the world?
>
> Avoid distributed server side state like the plague?

I've been trying to!

> I don't know if CAS has limitations on ticket size, but I would say that 
> continuing to use it long term implies that it be re-implemented using 
> encrypted tickets to recover the state rather than as references. If we 
> had to keep supporting SAML artifacts widely, I would be defining a new 
> artifact type to allow for that.

The CAS Protocol 3.0 spec says:

Services MUST be able to accept service tickets of up to 32 characters in 
length. It is RECOMMENDED that services support service tickets of up to 
256 characters in length.


I don't think that is enough space to track everything needed for a CAS 
session.  :(

 	Andy