Authorization per Sitemap via Reverse Proxy and Custom Router

Hello everyone,

I’d like to share my open-source solution to authorization per sitemap for multiple users in openHAB2.

My concept was developed with the sidecar pattern in mind and assuming that the traffic towards openHAB2 is controlled by a layer 4 proxy, e.g. nginx or envoy proxy. The openhab-auth-router inspects a header, set by the proxy in front of openHAB, containing the authenticated user and applies its configured rules on the traffic. The router itself does not do authentication, only authorization.

Typical use case description:
You run openHAB2 behind nginx with HTTP basic authentication enabled. Now you want to decide, which of the created users can access the sitemaps in openHAB. So you have nginx covering authentication and can now use openhab-auth-router as an authorization sidecar to your openHAB2 instance. It intercepts the traffic and applies a given set of rules.
This can be achieved simply by telling nginx to route all requests to the auth-router instead of openHAB directly.

The router comes as pre-compiled binary for multiple architectures and as docker image.

I created guides on how to deploy using vanilla binary, vanilla binary managed by systemd, docker, docker managed by systemd and Kubernetes. All of these can be found in the project

The readme also comes with a guide on how to integrate the router into a running setup. First as pure passthrough, then with an applied ruleset.

Furthermore, you can try the router outside of a running setup entirely, by using the docker based examples, which are also handy if you’d like to contribute to the golang source.

I have been running the v0.0.1-alpha in production for a couple of weeks now and haven’t had any incidents yet. My setup runs on Kubernetes.


nice setup (and documentation)!

Check also:

Thank you, I am also looking forward to the native implementation.

I’ve always said this was theoretically possible but never had time to figure it out on my own. Thanks for posting! Great writeup!


do you have apache configuration?

I do not provide an example Apache config; contributions are most welcome though.

This Apache config worked for me:

<VirtualHost *:80>
	ProxyPass / http://ip_of_your_device:9090/
	ProxyPassReverse / http://ip_of_your_device:9090/
	<Location />
		AuthType Basic
		AuthName "OpenHab2 Restricted"	
		AuthUserFile /etc/apache2/.htpasswd
		Require valid-user
		RequestHeader set X-Forwarded-Username expr=%{REMOTE_USER}
	ErrorLog ${APACHE_LOG_DIR}/error.log
	CustomLog ${APACHE_LOG_DIR}/access.log combined

Thanks, I will add it to the project on GitHub as well.

Sadly, the router does not work anymore for me since openHAB 2.5 (every user can access everything).

Can anyone verify? Do you have plans to update the program?

Hey, thanks for reaching out. I did not update to 2.5 myself yet, but I will work on the tool to support it.

I filed an issue for myself

Feel free to add any additional information you might have.

That’s nice to hear. Thanks a lot for your work!

Unfortunately, I cannot give more details than that users with restricted access get redirected to the standard " Welcome to openHAB 2" screen after login (where they can access anything).

Unfortunately, I was not able to reproduce any issues with openHAB 2.5 and openhab-auth-router:0.0.1-alpha.

The current tip of the master branch has updated examples to play with on your end.

There is going to be a maintenance release anyway, updating to golang 1.13.8.

To further investigate your problem now:

  • turn it off and on again > re-check
  • ensure that passthrough in the config is set to false
  • ensure that your proxy (nginx?) is passing the traffic through the openhab-auth-router and not directly to openHAB
  • please post your command used to start openhab-auth-router
  • please post your full config for openhab-auth-router

I realize that it currently is rather useless to enable debug logging, so I reckon I’ll add some more useful logs. Then we can update your setup and get more insight on what might be wrong.

Working on the said maintenance release, I started covering the application with test cases and found a bug which might explain what you described, @svensven.

When a known user comes in and the request URI is set to "" (empty string) instead of "/", it passed right through the proxy.

Will release the fix soon.

Took me a little while longer, but here is the promised release:

You can now use -log-level debug to get structured and helpful log output in order to narrow down issues.

Please note: I detected that the app has a memory leak which may cause issues. The issue is tracked in

1 Like

Thank you for the update! Sorry, I saw your answer from February just now. I will download the new version and test again.