OpenID Connect Authenticator on XWiki behind Reverse Proxy

Help / Discuss
#1

Hi.

Has anyone had the “OpenID Connect Authenticator” working behind a proxy where the public domain is different to the host on which xwiki is running?

In my specific case, the domains are actually the same but the external transport is HTTPS whilst xwiki is behind an RP and is running on HTTP. When the OIDC extension starts the authentication process, it does 2 things. It sets up a callback url and it also stores the original URL of the page the user was trying to access. The first part does consider what the public address is by using xcontext.getURLFactory().getServerURL(xcontext);; however, the second step uses (eventually) XWiki.getRequestURL which as far as I can tell does not take into account x-forwarded-host or the xwiki.home config in xwiki.cfg as it uses getRequestURL on HttpServletRequest.

I’m going to investigate changing OIDC to use the external URL to build up the “original url” that it stores for later rather than using getRequestURL.

I just wanted to make sure that I’m not missing some expected behaviour elsewhere that is not happening due to a misconfiguration or something or, that I’m running into a bug somewhere else within XWiki rather than this just being a functional issue of the OIDC extension.

If it’s agreed that this is an issue with the OIDC extension, I’ll get a Github issue raised and I’ll submit a PR once I have things working.

Thanks in advance,
Alex

#2

Unless I don’t understand what you meant I’m pretty sure that’s the situation in which most people are since most people access XWiki through some proxy so XWiki is generally on 127.0.0.1/localhost in practice.

XWiki#getRequestURL uses HttpServletRequest#getRequestURL() which is supposed to take that into account. Maybe there is a problem with the application server you are using.

XWiki#getRequestURL seems to work as expected on getRequestURL - XWiki for example. myxwiki.org uses Apache HTTP 2 as proxy with ProxyPreserveHost On in front of Tomcat 9.

Since the goal is to go back to where you were, it should not need to take that into account and only rely on standard HTTP proxy forwarding.

#3

Would be interresting if you could try the following in a wiki page:

XWiki#getRequestURL
{{velocity}}
$xwiki.getXWiki().getRequestURL($request)
{{/velocity}}


HttpServletUtils#getSourceURL
{{groovy}}
org.xwiki.container.servlet.HttpServletUtils.getSourceURL(request)
{{/groovy}}

Both are supposed to do the same thing but while the first one (XWiki#getRequestURL) rely on the application server the second (HttpServletUtils#getSourceURL) is XWiki own implementation.

#4

Hi Thomas, Thanks for getting back to me.

Yes, I think we are talking about the same setup (XWiki on an internal domain, fronted by a Reverse Proxy for the public domain) and I too thought that would be a common setup which is why I’m surprised that I’m running into the behaviour I am seeing and wondered whether I had some missing/wrong config.

I’m using the xwiki docker image with the LTS release, deployed into Kubernetes. The docker image uses Tomcat 8 (xwiki-docker/Dockerfile at ab7c84b36ec4fbee53ab412c8a5faeb936c89bf7 · xwiki/xwiki-docker · GitHub)

I think that test page demonstrates the issue. The URL in the browser is HTTPS except the output of getRequestURL is HTTP, not HTTPS. However getSourceURL appears to be correct and has HTTPS as the protocol.

#5

Hmm ok so that might suggest a problem in the docker image configuration or in the version of Tomcat 8 this image is using. Would be great if you could create a Jira issue for that on https://jira.xwiki.org/projects/XDOCKER.

In the meantime I will indeed modify the OIDCAuthServiceImpl to rely on HttpServletUtils which is probably safer and probably create an issue about relying less on the application server for XWiki#getRequestURL implementation itself since we often have problems…

#6

Hi Thomas,

Ok, no problem, I’ll raise that now.

I’ve made that change locally and found that it works so I can push a PR to Github this afternoon if that makes life easier?

Cheers

#7

I have the change locally, but I find it better to credit you for the time you spent debugging this, so I would be happy to take your pull request.

#8

Great, I’ll get that submitted shortly.

Thanks for your help.

#9

If you could just reference https://jira.xwiki.org/browse/OIDC-112 in the commit (something like “OIDC-112: Stop relying on the application server to find the initial request”), that would be great.

#10

“What issue should I reference in the commit message?” was going to be my next question :grinning_face_with_smiling_eyes:

No problem.

#11

I’ve raised: https://jira.xwiki.org/browse/XDOCKER-191

Please feel free to reword as you see fit.

#12

I’ve just opened the PR in Github as well. It’s a tiny change but I do appreciate you giving me the opportunity to contribute.

1 Like
#13

I just added the snippet to highlight the problem, the most important in a BUG issue is trying to give enough information to reproduce it. If you could give more information about how your HTTP proxy is configured that would probably help too.

#14

Ok, thanks. I’ve tried to add a bit more detail on our environment where the issue was first seen.

#15

@tmortagne I’ve been looking into this a bit more here and there and I’m now wondering whether the xwiki docker container is missing the Tomcat RemoteIpValve. I’ll try to do some testing soon but do you have environment on which everything is working as you would expect (so getRequestURL returns the correct value according to the x-forwarded headers) and if so, can you confirm whether that valve is enabled/configured or not please?

I’ll try to do some testing as soon as I can.

Although the valve docs don’t explicitly mention the x-forwarded-host header (RemoteIpValve (Apache Tomcat 8.5.66 API Documentation)) the following link suggests it is supported: 57665 – support x-forwarded-host

#16

xwiki.org seems OK, but it’s a bit special since it’s using AJP protocol (which causes problems of its own in different areas, so I don’t necessarily recommend it) between Apache HTTPd and Tomcat so probably not the best example. I also have access to another setup where it’s fine but based on AJP protocol too.

I don’t remember seeing this valve ever mentioned to me in a setup.

#17

Ok, thanks.

I’ll do some testing and if it turns out that’s the “fix” I’ll raise a pr on the xwiki docker repo.

1 Like