Quick reply as always @Kai 
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.
2 Likes
@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
We could take some ideas from the Milton WebDAV framework on how to implement authentication (which is based on servlet filters)
When and where? 
@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 org.ops4j.pax.web/pax-web-jaas at master Ā· ops4j/org.ops4j.pax.web Ā· GitHub 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 Add support for conditional access based on user role Ā· Issue #579 Ā· eclipse-archived/smarthome Ā· GitHub.
Iād definitely recommend these instructions instead:
http://docs.openhab.org/configuration/nginx.html
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 https://github.com/eclipse/smarthome/issues/579 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 https://gist.github.com/jpmens/8029383, 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)