Just my two cents on this topics:
If someone considers it unsafe that others can control there home when connected to the home-wireless network, who allowed those “others” to connect to this net?
Using/providing a “guest” wireless net would solve the whole problem.
5 Likes
I put also two cents to your answer: we can now start talking about fundamentals about sharing the wireless with guests, but i think this is a completly other topic.
Short explanation: The wireless device which i got from my priovider when i made the contract does not support open a second wireless.
Second thing is: i have three wireless at home, one for every floor. Only one can open a second wireless. So should i now buy two other new devices, because it is not possible to set authentication in openhab?
Nochmal auf deutsch. 
Ich hab vom Provider leider kein Gerät bekommen, (dsl modem) welches ein gästewlan aufspannen kann. Im Haus habe ich das DSL Modem und zwei Router und nur einer kann ein Gästewlan. Es macht also keinen Sinn extra neue Geräte zu kaufen, nur weil openhab keine Authentifizierung möglich macht. 
1 Like
I’m sorry that my solution didn’t solve the problem in your situation.
However it is still true that the problem only occurs since there are users allowed to use the net that should not use “that” part(i.e. the home-automation) of the net. The decision who shall be able to use the net (including the home-automation) relies with the owner of the net, who could:
-give to all or
-give it only the trusted users/guests.
Yes, by having a kind of user-control within OH that could be solved as well, but there seems to be nobody stepping forward to build it ( there might be reasons for that).
Remember that this software is a community project run by volunteers.
I confess I use nginx and so haven’t directly used htaccess for openHAB - but the answer seems to be here: http://www.eclipse.org/jetty/documentation/current/configuring-security.html#configuring-security-authentication
1 Like
But Version 1 of OH had that function. Why is it gone?
And it seems many want to see this feature again:
https://community.openhab.org/tags/authentication
Yes i know this page. As it seems there is no authentication in OH i have to step into this. 
I totally agree and also would like to see this feature again. I meanwhile configured nginx to do the job on my windows machine, but it nearly wasted me the time of a complete weekend.tgh
I also have a hard time understanding the overall philosophy behind the OH2 architecture regarding this point. On the one hand several UIs are offered to help beginners to define things and items and so on (which also could be easily done in config files). So obviously the manual maintenance of config files is considered to be “too difficult” for the beginner user.
On the other hand the poor beginner user needs to configure a reverse proxy on its own just to get a safe remote access to his OH2 machine. I cannot really follow the thoughts behind this.
In the end the beginner user will rather choose an alternative software and not OH2 (which unfortunately seems to become more and more a gimmick only suitable for freaks that spend most of their free time for home automation and network configuration).
So why can’t the easy way from OH1 (regarding password control) be implemented to OH2?
6 Likes
You got the point!
Just to add, it is not just simple passworded access. From previous discussions, some people would like to set level of priviledge i.e. guests get lighting controls but not heating settings.
Yes, there are ways to do that with selective sitemaps, but it feels a bit clumsy like add-on nginx.
I do not know how all this should be addressed, feels like it should be part of underlying Eclipse system.
But everyone’s instincts must surely be crying out against beginners able to put one’s home ‘online’ without even a default password?
All right, @vossivossi and @gegy, you seem passionate about this. When can we expect your PR to add this feature? There is an open issue out there waiting to be implemented.
Like @opus said, it’s an all-volunteer project. Someone has to step up to make the changes. No one has done so thus far. Will you?
I am perfectly aware of this. However even a team of volunteers should have some arhcitectural guidelines and priorizations. Otherwise you get a big mess of uncomplete functions, missing features, several combinations of bindings/releases and whatever which do not work together or only with hundreds of undocumented restrictions and hacks and so on…
This unfortunately is my perception of OH2 at the moment and it was different in times of OH1 (just a year ago). OH1 was a stable, more or less complete backbone that you really could recommend to run your smart home. OH2 still is a big construction site missing lots of basic and essential features even after nearly one year of the first official release (and years of beta before). And apparently no one cares. While the most exotic bindings are published as beta0-versions the essential basic function are still missing. I think that is a pitty.
3 Likes
If i had time and if i am familiar with the architecture and security things i will do that, but i am not. I am a CAD technican with a few programming skills but not more. So i have wait for someone else who can do that. But if no one says that he want this feature nobody will do i it i think.
My last question was only, why is this feature gone, as it was allready there in OH1. Is OH2 developed from scratch?
There indeed are, but you can’t force a volunteer to work on something they don’t want to work on.
One person’s essential need is another person’s superfluous feature.
We can’t force developers to work on what they don’t want to work on. So should the project refuse to accept bindings just because some features you deem essential haven’t been implemented yet? Some developers had an essential need for these exotic bindings so they implemented it and donated them to the community. We can’t say “no, take your new exotic binding and shove it because all new contributions are being refused until someone works on this issue over here.” That isn’t how open source development works and trying to operate like that is a certain way to kill a project like this.
Essentially yes, it is almost wholly rewritten, or at least drastically refactored from the original 1.x code. This was required to achieve features like automatic discovery of devices and the like.
The issue is already open and it comes up on the forum frequently. I suspect if it were easy to implement it would have already been done.
Another way for non-developers to “vote” for features they deem important is to put some money behind the request. OH works with the Introducing BountySource for funded development which lets users contribute money which will go to a developer(s) who add a desired feature or fixes a desired bug.
Open source developers tend to be a little quirky when it comes to money involved with OS projects, but someone may take up the task if they know they will get a bit of cash out of it.
Implementation of proper authentication (one that will allow conditional access) is a big task. For openHAB and Eclipse Smarthome, many people have tried to work on it and have become stuck in one way or another.
There is yet again an impulse on the topic and for those with an interest in how it’s going, feel free to read about it in the following issue trackers:
Even better, for those that can, feel free to make a contribution!
2 Likes
I really have a hard time with the argument that network services shouldn’t need to implement access control, but rather each service should be run via an isolated network that handles access control (I have at least 5 services running in my home network, partially with differentiated access rights within one service…).
On the other side, I perfectly accept the answer “Nobody donating time and proficiency, or money, has prioritized this security feature so far, and you cannot force volunteers, but you might incent them with donation.” Clearly, hard to argue against that
But aside from feasibility, from a strategic point, I think it is legit to assume that a HA service is not too rarely used as a critical server-based system that should ensure at least basic access control on it’s own. To me, it’s a question of “Is OpenHAB a serious HA server for productive use (secure), or an advanced lego technics alternative (many bindings to a lot of gadgets for a non-critical environment)”. (Both polarized to extremes to make a point). I’m not saying one is better than the other, or that anyone would be in charge to control this - merely that I would want to know before I invest a lot of time into a steep learning curve.
Actually, knowing this, I might have been wrong choosing OH2 for my KNX installation which is supposed to include my burglar alarm system - I was attracted by the simple handling of the new version (ATM, irrelevant for KNX, since the still legacy binding needs config files) and by the productive use maturity (which seems to have suffered from new priorities during the re-coding). Maybe, although OH2 is surely the way for the future, some of us would at the moment be better off with OH1, actually…?
Hello,
so I give my Senf to this topic as well:
I have apache configured to do the authentication but it has a drawback: I cannot logout.
In my case I use a virtual host to access openhab from outside via https. So all other services I use provide LDAP authentication (pydio, roundcube, openvpn) which is the way I prefer.
Using the current openhab VH setup has this disadvantage: I close for example the openhab tab in the browser and afterwards I open a new tab with the openhab URL and no user credentials are required.
At home I have actually the same problem as Georg: no guest WLAN…
This isn’t an either or. Even if a service implements access control, it is standard practice to isolate networks with different functions, especially if one of those networks is somewhat risky and full of TVs that spy on you and cameras that are easily hacked and used to attack websites.
Ideally, one would be able to do both. But if that isn’t possible, one can put authentication to get on the various networks as mitigation.
Having spent some time in cyber security I can add the following.
Physical and logical controls are important, but you should design your systems assuming that the ‘network’ has been compromised - because a lot of them are. This means that you should add layers of authentication and encryption to those functions that you value.
While a home network may often be compromised - usually by some form of remote control malware - there needs to be an incentive for someone to use that remote control to benefit themselves. Normally it is easiest just to encrypt some data and ask for a few euro, engage in coordinated ddos or maybe run a mining op and that reaps some financial reward. Exploiting a weak OH system may not be all that high on their priorities…
However, when someone uses OH to open doors or interfaces with security systems, the weak security is a real concern. Personally, I am working on a bespoke security system and would like to integrate/automate with OH. While I am not implementing a fort knox system, it does need to be resistant to likely threats for a home environment. I do consider network compromise a likely threat. I personally think that authentication is essential for any system that controls physical or logical access, whereas it may not be so important if someone can remotely change TV channels or pull your blinds.
I see that @splatch is working on authentication and I am personally grateful that he is progressing this important addition. Pleasing everyone is hard to do and can make it a difficult task. Personally, just having some level of authentication even without role-based, multi-level security would be a great step forward.
Just my 2 cents.
My thanks to the @splatch and the other devs.
Ron
2 Likes
Just wanted to give my thoughts… I think some kind of built in auth would be great. But, as others have stated no one has stepped up yet. Maybe soon?
Anyways… this is what I would do as a solution to the OP’s problem. Honestly, I’m surprised it wasn’t suggested?!?
- Assign static ip’s to trusted devices >>> really should be done for all devices with minimum dhcp scope… what home user needs a 255.255.255.0 mask?
- Setup iptables / ufw on OH server to only allow traffic from trusted devices on required ports 22, 8080, 8443, etc. **** Be careful…Make sure you don’t lock out SSH!!!
Done!
Hi there,
I found a way to manage authentication with detailed access restriction for the REST API done by a reverse proxy.
1 Like