<div dir="ltr"><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_quote">On Thu, Nov 17, 2016 at 5:08 PM, Cantor, Scott <span dir="ltr"><<a href="mailto:cantor.2@osu.edu" target="_blank">cantor.2@osu.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":3et" class="a3s aXjCH m15874fa9e7602290">I feel like I need a shower after reading this email.<br></div></blockquote><div><br></div><div>You can imagine how I feel, then, having gotten to the point where I felt like I needed to write it.  :)  Right now, I feel like I'm in damage control mode.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":3et" class="a3s aXjCH m15874fa9e7602290"><span class="">> Is there some clever way<br>
> that I'm overlooking to turn off IP address consistency checking by SP<br>
> entityID or client IP address?<br>
<br>
</span>No, it's a session manager setting, and the session manager doesn't have access to the per-request state that would allow that setting to be turned into some kind of strategy function. It would take a significant change to get that decision pulled out into the "IdP proper" where that sort of dynamic behavior would be possible.<br>
<br>
Also I think it might lead to weird results based on order of access. That's usually what happens when you start messing around with per-SP behavior connected to SSO outcomes. Haven't thought it through admittedly.<br></div></blockquote><div><br></div><div>That was my impression.  Thanks.  I don't want to do anything that makes my primary IdP unstable.  I'd rather have my parallel operation like I currently have (which is just a second Docker container of my production IdP with a few tweaks.)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":3et" class="a3s aXjCH m15874fa9e7602290">
<br>
> 2. LocalStorage.  I assume there's no way to switch this based on SP entityID?<br>
<br>
No, also global. It may be more amenable to becoming more dynamic because of how it works but again, not something I've thought about the implications of so I'm probably overlooking all kinds of issues with that.<br>
<br>
There's a lot of Javascript ultimately involved in that determination. It's possible one could hack something up in that layer somehow maybe.<br>
<span class=""><br>
> And that leaves me wondering if anyone else has dealt with this application<br>
> and found a better way.  Maybe I just haven't been asking Capriza the right<br>
> questions or getting them to do the right things.<br>
<br>
</span>Well, turning off local storage outright presumably solves that one problem. That should force cookies regardless, at the cost of logout. I guess you could look at server side storage, maybe the hazelcast plugin Unicon has that a lot of people like.<br></div></blockquote><div><br></div><div>This is definitely not worth going to server-side storage.  The server-side stuff is sexy and all from an engineering standpoint, but it would make my infrastructure far more complex than it deserves to be.  (I run my IdP's in an active/standby behind my load balancer, as I have since dropping Terracotta way back when.)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":3et" class="a3s aXjCH m15874fa9e7602290">
<br>
I've never heard of this misbegotten Dunwich Horror of software, no.</div></blockquote></div><br>It seems way more complex than it needs to be.  For instance, surely the phone itself has more than enough horsepower to do all of the scraping that the remote, headless Firefox browsers are doing... </div><div class="gmail_extra"><br></div><div class="gmail_extra">After sitting on this for the day, I've got some ways to identify the original, authenticating browser at the load balancer level.  So, being able to do that, I think I can pull this off with my parallel IdP and routing at the load balancer.  </div><div class="gmail_extra"><br></div><div class="gmail_extra">Thanks.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Greg</div></div>