Authentication in OH2

Quick reply as always @Kai :slightly_smiling:

I’ve read that thread as well but didn’t really get a clear understanding if someone was looking into it, working on it. I’ll keep monitoring both threads. Thanks!

@Kai I took a look on authentication and the way it was done before. Configuration of jetty is a bit different than default but we may secure it with HTTP basic authentication at jetty connector level (easiest way). I will post PR with example configuration.


@splatch sounds promising as I’m securing all traffic with reverseproxy and https when going outside of the local network, adding un/pw would be just enough for my needs at least :slightly_smiling:

We could take some ideas from the Milton WebDAV framework on how to implement authentication (which is based on servlet filters)

When and where? :slight_smile:

@Kai I’ve tried to bring that up, but it turned out to be harder than expected. Jetty jaas support can not be easily plugged in, and even if, it will just cover handlers enlisted in jetty xml and will not secure backend services. I was checking up reset services and way they are published does not allow to control authentication too. For now I’m stuck.

@tobo In your case you may add basic authentication on proxy server.

Hm, this does not sound good. I had hoped that this is something already solved for Karaf solutions…
I was actually thinking that pax-web covers such features (without requiring us to directly go down to Jetty itself) - do you know what is about and if it might help?

@Kai I’ve spoken with @bcanhome about module you pointed out - it’s inherited from undertow integration and it’s not yet supported in Jetty. It is possible to couple jaas when using WAR archives and web.xml descriptors, however there is no easy way doing that externally.

Sadly the way how services are published doesn’t allow to inject custom http context with implemented security mechanism (at least I can’t find possible way). I think we need to consult that with authors of bundle providing this functionality to confirm how to do that.

Last thing which comes to my mind is usage of custom http filter registered at same path as rest resources, but this most likely would require usage of pre-existing http context created by eclipsesource jaxrs publisher.

Is authentication considered a prerequisite to the OH2 release version? There hasn’t been any activity on this thread for a few months, so has there been any progress on how this might be addressed?

You might not have been looking at the right place, the discussion and progress is done on this issue.

1 Like

Much of the discussion in the issue above is beyond my level of understanding. @Kai also suggested “to use a reverse proxy like NGINX or Apache for securing access.” I previously looked into reverse proxy, but read that issues can arise in relative paths with the app if the configuration isn’t correct.

Can someone with experience post a step by step reverse proxy server configuration example here? I think that would make myself and others more confident in testing OH2.

sorry for the late post - but until it’s all sorted within OH2 - why wouldn’t that be our best option? Oh2 has great Web responsiveness - so if we’re just “watching and actioning” our sitemap - why not?

ssl + basic auth and you’re perfect if you’re not paranoid. basic auth with encryption is used in many enterprise apps.

I’m doing nginx revers proxy currently and it works a treat.

I’m happy to see the reverse proxy instructions in the User Manual.

The instructions were great and helped me a lot! Thanks for that!
I have now a secure Internet facing setup with encrypted channels and authentication in place.

1 Like

Is OH2 really going to come out of beta without any authentication and require a reverse proxy???

I doubt it, its something that being looked into I think. I’ve put up the instructions for nginx because its a great way to get authentication running now. When/if authentication does come out directly, I still feel a reverse proxy and its alternative solution to auth/security will still be useful.

No, this is why I try to keep pushing

I’d definitely recommend these instructions instead:

There are a couple of typos/settings in the website you suggested that will prevent openHAB from working properly. X-Forwarded-Scheme isn’t a valid setting, proxy_buffering is still on etc…

I am just wondering how the discussion and proposed PR in will impact the usage of the iOS openHAB app

As far as I understand things, opting for a nginx+certbot+basic http authentication effectively means that only the Basic, Classic or other web-based GUI can be used, right?

Also, for me the only reason to use nginx is to facilitate the automatic certbot-driven certificate renewals, which is not that friendly/easy when directly integrating certbot generated certificates in the jetty config of openHAB (Securing Openhab with free ssl Let’s Encrypt Certificates and, and SSL with OpenHAB2). Since certbot is a good initiative that we/anyone should support, we should maybe introduce a new servlet in openHAB to accommodate the automatic renewals. This sounds a lot like the OH1 “webapps” stuff which we not use anymore in OH2 (well, static html can be put in conf/html but is not served through the hidden url / well-known)