[midPoint] Reverse proxying midPoint no longer works with 3.9
Steve Hillman
hillman at sfu.ca
Mon Aug 26 22:16:26 CEST 2019
I spent several hours on this a couple of weeks ago trying to get it to work. I finally gave up and configured MidPoint to do its own SSL, then put Apache in front of it as a proxy (because I wanted to listen on port 443, but didn’t want to run MidPoint as root). That works, though it’s a hack. But since MidPoint “knows” that it’s running using SSL, it doesn’t try to rewrite the URLs back to HTTP
In order to get SSL to work, I had to add my own self-signed cert to MidPoint’s keystore, then put the following in the application.yml file:
server.port: 8443
server.ssl.key-store: /midpoint/var/keystore.jceks
server.ssl.key-store-password: xxxxxxxxx
server.ssl.keyStoreType: jceks
server.ssl.keyAlias: tomcat
On Aug 26, 2019, at 5:08 AM, Ramón Cahenzli <ramon.cahenzli at zhdk.ch<mailto:ramon.cahenzli at zhdk.ch>> wrote:
Hi everyone,
It seems I spoke too soon when I said reverse proxying midPoint now
works for us. I've talked about this earlier and Stacy Brock had a
solution for Apache that seemed to work:
RewriteEngine on
RewriteRule ^/$ /midpoint/ [R,L]
RewriteRule ^/midpoint$ /midpoint/ [R,L]
ProxyPreserveHost on
RequestHeader set X-Forwarded-Proto https
RequestHeader set X-Forwarded-Port 443
ProxyPass "/midpoint/" "http://127.0.0.1:8080/midpoint/"
ProxyPassReverse "/midpoint/" "http://127.0.0.1:8080/midpoint/"
# midPoint can be slow to respond, so we set the timeout to 10 minutes
ProxyTimeout 600
But midPoint itself still generates redirects to HTTP on port 80
instead of using the information from X-Forwarded-Proto and
X-Forwarded-Port as instructed.
In application.yml we configure:
server.address: 127.0.0.1
server.port: 8080
server.session.timeout: 60
server.use-forward-headers: true
server.tomcat.internal-proxies: 127.0.0.1
server.tomcat.protocol-header: X-Forwarded-Proto
server.tomcat.protocol-header-https-value: https
server.tomcat.port-header: X-Forwarded-Port
Yet we see midPoint redirecting to http://.../dashboard and
http://.../login on, as on the screenshot. When port 80 is closed,
users can't log in. midPoint seems to ignore
server.tomcat.protocol-header and
server.tomcat.protocol-header-https-value.
The config information is from here:
https://wiki.evolveum.com/display/midPoint/Using+MidPoint+with+embedded+Tomcat
Incidentally, there is an error in that example (the block on line
78-87 should be indented under server.tomcat.accesslog) but I can
create a Jira ticket for that.
Any ideas what we could do to address the issue? We want midPoint to
know that it needs to stay on HTTPS and not generate redirects to :80.
Cheers,
--
—
—
Zürcher Hochschule der Künste
Zurich University of the Arts
—
Ramón Cahenzli, MSc.
IT Architect
—
Pfingstweidstrasse 96, Postfach, 8031 Zürich
Tel. +41 43 446 31 63, Fax +41 43 446 45 21
ramon.cahenzli at zhdk.ch
—
http://www.zhdk.ch
http://itz.zhdk.ch
<reverse_proxy_midpoint.png>_______________________________________________
midPoint mailing list
midPoint at lists.evolveum.com
http://lists.evolveum.com/mailman/listinfo/midpoint
Steve Hillman
IT Architect | IT Services
SH1032 | Simon Fraser University
8888 University Dr., Burnaby, B.C. V5A 1S6
T: 778.782.3960 | M: 604.306.3366 | www.sfu.ca/itservices<http://www.sfu.ca/itservices>
Twitter: @sfu_it
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20190826/69534546/attachment.htm>
More information about the midPoint
mailing list