maintaining SP shib state in cookie

[Jeremy Shapiro]

On Thu, May 14, 2015 at 9:18 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:

>
> How are you clustering the application itself in the first place? Normally
> the way to deal with an application that has managed to solve a problem
> that complex is to dump the SP session after it starts, just gateway it
> into the app session and forget about it.
>

We're using DNS load-balancing.  All SP's have the same hostname.  As you
saw from my message to the users list, I have little control over the app.
Telling the app developers to change how they do authentication is not
really an option.


> The security concerns are that the data has to be tamper-proof and
> encrypted, same as the IdP's code does, which means secret key management
> also. More to the point the data is arbitrarily large, which is why it
> wasn't done to begin with. It will only be possible when the attribute set
> doesn't exceed a few kilobytes, which is admittedly the norm, but there's
> no apriori way for the SP to know that ahead of time and nothing it can do
> about it if it's not true.
>
>
What attack does having the data be tamper-proof and encrypted protect
against?


> Another option is cross-node lookup of the data to move the state around
> in memory.


Is this different than the shared process mechanism with private subnets
described in the wiki?

  Jeremy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20150514/e4ea50f2/attachment.html>