Integration with Capriza?
Greg Haverkamp
gahaverkamp at lbl.gov
Thu Nov 17 21:29:56 EST 2016
On Thu, Nov 17, 2016 at 5:08 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:
> I feel like I need a shower after reading this email.
>
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.
> Is there some clever way
> > that I'm overlooking to turn off IP address consistency checking by SP
> > entityID or client IP address?
>
> 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.
>
> 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.
>
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.)
>
> > 2. LocalStorage. I assume there's no way to switch this based on SP
> entityID?
>
> 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.
>
> There's a lot of Javascript ultimately involved in that determination.
> It's possible one could hack something up in that layer somehow maybe.
>
> > And that leaves me wondering if anyone else has dealt with this
> application
> > and found a better way. Maybe I just haven't been asking Capriza the
> right
> > questions or getting them to do the right things.
>
> 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.
>
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.)
>
> I've never heard of this misbegotten Dunwich Horror of software, no.
>
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...
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.
Thanks.
Greg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20161117/23b4a451/attachment.html>
More information about the users
mailing list