intermittent IDP failure

[Steven Carmody]

On 2/1/13 10:29 AM, Cantor, Scott wrote:
>
> You can set an X-Forwarded-For header from the F5, and configure Jetty and
> the IdP to put it into the logs. I don't know if Jetty can fully present a
> custom header as REMOTE_ADDR, so it may require appending it to an
> additional field in the IdP logs.

thanks for that info -- I'll forward it to the network team.

>
> Another, better option, is to stop proxying HTTP. I do direct TCP load
> balancing to my IdPs and am a lot happier for it. It's a requirement for
> client TLS of SOAP traffic anyway.

sorry for the naive question -- I'm completely removed from the 
operational issues here. "direct TCP load balancing" --  that sounds 
like an option in the F5 ? It would balance, but would just pass the 
headers and other info (eg originating IP address) right thru and not 
rewrite it ?

>
> As far as the original problem, if turning Terracotta off fixed it, then
> it must be a problem replicating login context state. I can't see how
> that's possible unless Terracotta just literally doesn't work at all. I
> didn't think it was that bad.

It works, mostly. But, this problem was pretty easy to replicate. I sat 
with someone for 30 minutes and saw him recreate the problem.

We *think* it seems to require being sent to the other IDP. And having 
an App that sends the user back to the IDP more frequently than you'd 
expect helps to trigger the problem. (This last situation can be created 
by running your App on a cluster that doesn't share the SAML session 
across the cluster.) Think cloud-based apps using their own SAML 
implementation ....

>
> Any options available now other than TC or Infinispan would require
> stickiness at your load balancer through the login, and if you can do
> that, you could put Terracotta back in I suppose, and wouldn't have that
> particular problem.
>

we currently have a 180 second stickiness at the load balancer. That 
gets the use thru the initial login. However, some apps (see above) 
continue to send the user back to the IDP, randomly.

We're looking at going stateless. We'd lose functionality we don't use, 
and get a vastly simpler deploy configuration.

We've started looking at your OSU login handler.