TCP socket configuration for SP

[Christopher Bongaarts]

On 7/28/2012 11:13 AM, Cantor, Scott wrote:
> On 7/28/12 12:48 AM, "Christopher Bongaarts" <cab at umn.edu> wrote:
>>
>> Just trying to cover the DR bases since we're introducing a single point
>> of failure.
>
> I get that aspect, but unfortunately the client connection here doesn't
> really support any form of redundancy, because it's meant to be a state
> cache, and if you lose the state, you lose the ability to treat things
> redundantly. If you had something like ODBC or memcache in place, and then
> added a load balanced connection to multiple shibds, I guess that would be
> the closest, but once you remove the state from the process, the general
> idea is you restart shibd any time it would fail (which is rare) and
> minimize most of the problems.

The main idea is that it is more important to be able to continue 
authenticating new users than it is to preserve existing sessions.  And 
in our case, the main risk is that the one server with the active shibd 
would become unavailable (say, not as hypothetically as I would like, 
due to a data center power outage).

>> The problem that led to this is a stateless application using DNS round
>> robin A records for load distribution.  In our old SSO system, clients
>> could bounce between servers with impunity.  Now that we have the Shib
>> SP in the picture, there is suddenly state involved.
>
> Is the application actually using the SSO session?

It is using the REMOTE_USER set by mod_shib (formerly our SSO's Apache 
module).  There is a bit of authorization by AuthnContext at the Apache 
config level; the rest is handled in the app itself.

> I would warn you that we've seen issues with that in one case here at OSU
> because of a network issue between the systems. I'm not sure yet what the
> cause is, and I have no reports of it anywhere else. It also is
> *definitely* slower, much slower. When you have content that includes a
> lot of internal protected page content, you get a lot of overhead.

I cut it over last night and seems to be doing OK.  The peak load for 
this app is about one session per 15 seconds or so - not a very high by 
our usual standards.

Thanks as always for helping vet our ideas.  We're now treating the 
shibd strategy as a temporary workaround until we can add auth state 
preservation to the app itself.

-- 
%%  Christopher A. Bongaarts   %%  cab at umn.edu          %%
%%  OIT - Identity Management  %%  http://umn.edu/~cab  %%
%%  University of Minnesota    %%  +1 (612) 625-1809    %%