SLO Problems

[Darren Boss]

For anyone deploying under Kubernetes using the nginx ingress controller
you will likely have to set this annotation in your ingress:
nginx.ingress.kubernetes.io/proxy-buffer-size: 8k

The default is 4k. Similar issues would likely be the case if you were
using any nginx reverse proxy configuration in front of your IdP.

After removing the jetty-rewrite.xml file from the Docker image and setting
this annotation in my ingress, I can confirm that it has solved the issue
with SLO for me where the SP is configured correctly.

On Thu, Apr 18, 2019 at 2:53 PM Paul Caskey <pcaskey at internet2.edu> wrote:

> If those 2 items aren’t working, then nobody has reported it.  And, in
> that case, we’d get it fixed.
>
>
>
> And, FWIW, source for the Linux IdP container is here
> <https://github.internet2.edu/docker/shib-idp> (and Windows IdP is here
> <https://github.internet2.edu/docker/ShibbIdP_noVM_Windows>).
>
>
>
>
>
> Thanks - TTYL
>
>
>
> *From:* users <users-bounces at shibboleth.net> *On Behalf Of *Darren Boss
> *Sent:* Thursday, April 18, 2019 1:41 PM
> *To:* Shib Users <users at shibboleth.net>
> *Subject:* Re: SLO Problems
>
>
>
> I sort of agree but I still distrust the majority of the images in docker
> hub and I'd still like to rebuild any of the images I deploy in our
> infrastructure. That being said you are likely going to trust some base
> image that gets pulled from Dockerhub or Quay.
>
>
>
> Are the TEIR images tested working for features like SLO and ECP? That
> might be a compelling reason for me to switch.
>
>
>
> I think I've almost got SLO working for the Unicon image working under
> Kubernetes. I'm seeing this in my nginx ingress controllers logs:
> 2019/04/18 18:24:06 [error] 328#328: *4351387 upstream sent too big header
> while reading response header from upstream, client: xxx.xxx.xxx.xxx,
> server: xxx.xxx.xxx.xxx, request: "GET
> /idp/profile/PropagateLogout?SessionKey=1 HTTP/2.0", upstream: "
> http://xxx.xxx.xxx.xxx:8080/idp/profile/PropagateLogout?SessionKey=1",
> host: "xxx.xxx.xxx.xxx", referrer: "
> https://xxx.xxx.xxx.xxx/idp/profile/Logout?execution=e4s2"
>
>
>
> TLS gets terminated at the ingress controller in case someone was goign to
> point out the http url. Crossing fingers that some minor tweaking of the
> configuration for the nginx reverse proxy will solve the problem.
>
>
>
> On Wed, Apr 17, 2019 at 10:13 AM Paul Caskey <pcaskey at internet2.edu>
> wrote:
>
> Excellent!  I agree the VM images were bulky.  Everything is in docker hub
> nowadays.
>
>
>
> Let us know if we can help or if you have any feedback!
>
>
>
>
>
>
>
> *From:* users <users-bounces at shibboleth.net> *On Behalf Of *Darren Boss
> *Sent:* Wednesday, April 17, 2019 9:11 AM
> *To:* Shib Users <users at shibboleth.net>
> *Subject:* Re: SLO Problems
>
>
>
> Yes, I was aware. It's on my long to do list to try the TIER Shibboleth
> IdP image. At the time we were setting up our IdP I think the TIER images
> were still wrapped up bulky VM images and it wasn't what we were looking
> for but I understand that this is not the case anymore.
>
>
>
> I can't recall if I've already taken a brief look at the TIER Shibboleth
> IdP image and determined that it was more difficult to implement the
> Kubernetes deployment we are doing. We use a alpine based git initContainer
> to do a single branch clone from our git repo for the Shib configuration
> and that gets mounted into various locations in the IdP image (metadata,
> messages, conf, etc). This makes for nicely versioned configuration and
> easy to rollback quickly to a previous configuration if something breaks.
> When I get around to it and if I run into problems I'll probably jump over
> the the Internet2 slack channels to discuss.
>
>
>
> On Wed, Apr 17, 2019 at 9:18 AM Paul Caskey <pcaskey at internet2.edu> wrote:
>
> Hi Darren-
>
>
>
> InCommon also maintains containers for Shibboleth IdP, SP (both Windows
> and Linux) and Grouper and COmanage.
>
>
>
> See here for more info:
> https://spaces.at.internet2.edu/display/ITAP/InCommon+Trusted+Access+Platform+Release
>
>
>
>
>
> TTYL
>
>
>
> *From:* users <users-bounces at shibboleth.net> *On Behalf Of *Darren Boss
> *Sent:* Wednesday, April 17, 2019 8:14 AM
> *To:* Shib Users <users at shibboleth.net>
> *Subject:* Re: SLO Problems
>
>
>
> I was starting to feel bad about hijacking this thread but turns out we
> really were working on the same issue! I'm still having issue even when
> removing the jetty-rewrite.xml completely but now I'm closer to a working
> configuration. I see a status 502 for PropagateLogout
> (PropagateLogout?SessionKey=N) url when I use the developer console in
> chrome. In Firefox the logout now gets to the point where the red x is now
> displayed beside each SP and in both browsers I no longer see the error
> messages I reported before. I also confirmed in the dev console that the
> csp and frameoptions http headers are no longer there.
>
>
>
> I wasn't sure that there were many using the Unicon image but I noticed
> that it was still getting quickly updated when a new release of the IdP
> came out and they recently started using multi-stage builds so it's still
> being supported and even if it wasn't it's pretty simple to tweak the
> Dockerfile to target new versions of Jetty, Shib IdP or Java and rebuild.
>
>
>
>
>
> On Tue, Apr 16, 2019 at 7:41 PM Bob Allison <shib at allisonr.us> wrote:
>
> I am also using that image. I confirmed that removing jetty-rewrite.xml
> completely solved my problems. Only removing the last addRule was not
> enough for me. I guess the question is if there is any reason to have the
> file at all if both rules have been removed.
>
>
>
> On Apr 16, 2019, at 13:07, Darren Boss <darren.boss at computecanada.ca>
> wrote:
>
>
>
> So I think I tracked it down to Jetty configuration. I'm using the Unicon
> shibboleth-idp-dockerized image although I rebuild it and I do make some
> minor tweaks as a layer on top of their image.
>
>
>
>
> https://github.com/Unicon/shibboleth-idp-dockerized/blob/master/opt/shib-jetty-base/etc/jetty-rewrite.xml
>
>
>
> I think that's the culprit and that last addRule can be removed. If it
> works I'll create a PR to their project.
>
>
>
> On Tue, Apr 16, 2019 at 11:19 AM Cantor, Scott <cantor.2 at osu.edu> wrote:
>
> On 4/16/19, 9:43 AM, "users on behalf of Darren Boss" <
> users-bounces at shibboleth.net on behalf of darren.boss at computecanada.ca>
> wrote:
>
> > It does look like my problem might be related to running under
> Kubernetes, specifically that http headers are being set
> > by the nginx proxy.
>
> That doesn't inherently mean the headers are in fact correctly usable out
> of the box, there still might be a mistake in our understanding.
>
> You should NOT need to alter the headers to make logout work, and I have
> never had to do so in any testing scenarios I've attempted. So either my
> testing is artificial and doesn't match a real world issue in some way, or
> people are mistaken somewhere about what Chrome is really saying.
>
> -- Scott
>
>
> --
> For Consortium Member technical support, see
> https://wiki.shibboleth.net/confluence/x/coFAAg
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
>
>
>
> --
>
> *Darren Boss*
>
>
>
>
> *Senior Programmer/Analyst Programmeur-analyste principal
> darren.boss at computecanada.ca <darren.boss at computecanada.ca> (o)
> 416.228.1234 x *230
>
> *(c) 919.525.0083*
>
> --
> For Consortium Member technical support, see
> https://wiki.shibboleth.net/confluence/x/coFAAg
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
>
>
> --
> For Consortium Member technical support, see
> https://wiki.shibboleth.net/confluence/x/coFAAg
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
>
>
>
> --
>
> *Darren Boss*
>
>
>
>
> *Senior Programmer/Analyst Programmeur-analyste principal
> darren.boss at computecanada.ca <darren.boss at computecanada.ca> (o)
> 416.228.1234 x *230
>
> *(c) 919.525.0083*
>
> --
> For Consortium Member technical support, see
> https://wiki.shibboleth.net/confluence/x/coFAAg
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
>
>
>
> --
>
> *Darren Boss*
>
>
>
>
> *Senior Programmer/Analyst Programmeur-analyste principal
> darren.boss at computecanada.ca <darren.boss at computecanada.ca> (o)
> 416.228.1234 x *230
>
> *(c) 919.525.0083*
>
> --
> For Consortium Member technical support, see
> https://wiki.shibboleth.net/confluence/x/coFAAg
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
>
>
>
> --
>
> *Darren Boss*
>
>
>
>
> *Senior Programmer/Analyst Programmeur-analyste principal
> darren.boss at computecanada.ca <darren.boss at computecanada.ca> (o)
> 416.228.1234 x *230
>
> *(c) 919.525.0083*
> --
> For Consortium Member technical support, see
> https://wiki.shibboleth.net/confluence/x/coFAAg
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net



-- 

*Darren Boss*
*Senior Programmer/Analyst*
*Programmeur-analyste principal*
*darren.boss at computecanada.ca <darren.boss at computecanada.ca>*
*(o) 416.228.1234 x *230
*(c) 919.525.0083*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20190418/a0efa200/attachment.html>