Restricting Access to OH3 Overview and Pages to Selected Users (other than visibleTo)

Hi I am trying to figure out how I can restrict access (to an OH3 UI) to only admin or ordinary users?

Pls consider a use case where as a parent (admin) I am ok for my kids (users) to have access to the controls for e.g the blinds & garage door, but not for the garden watering system.

A similar example would be airbnb type scenario where the owner (admin) lets their house out to a guest and wants the guest to have OH3 access to some controls and not others.

Commercial applications - in a workplace, would see a very significant rise in the number of examples / use cases.

I have experimented with visibleTo but this does not appear to provide a means to prevent a determined user from simply typing in the IP address and port number - arriving at the Overview page (!). Even if I have taken the step of making the Overview Page itself ‘visibleTo admin’ only, the Locations, Equipment and Properties can be readily accessed.

Complex hacks/ workarounds are not going to be possible for me as a beginner user - nor would they be practical to implement for third party guests to my house. Is there a straightforward way to do what I have described?

If not, is there any chance of one being introduced?

Many thanks!

I’ve moved this to a more appropriate category. Tutorials & Solutions is for posting solutions, not for asking for one.

OH does not have fine grained controls like that. You have admin users and you have normal users. Unless otherwise configured, by default, a non-logged in user is a normal user (this can be changed in the security settings).

Access to all Items is allowed for all types of users. Admin users additionally have access to rules, add-ons, Things, and the ability to change the settings on widgets and stuff like that.

As you have seen, you can hide certain UI widgets so that they are only visible to a certain type of user but that is not a security control (this is made clear in the docs). It does not prevent access to that Item/widget/page.

But that’s all that openHAB supports.

You can change the security settings to that they have to log in in order to see anything at all. In MainUI navigate to Settings → API Security and turn off “Implicit User Role”. That will force everything in OH to be closed except to authenticated users.

You can omit Items end users should not interact with from the semantic model. Those won’t be shown in the autogenerated tabs.

You can hide the auto generated tabs from all users in the overview page settings. This is different from visibility in that it doesn’t even render those pages any more.

If you need more than this, it’s going to require “complex hacks/ workarounds”. Ultimately, if you can’t trust the people on your LAN not to try and break into your openHAB, why are they allowed on the LAN in the first place?

Probably not any time soon. There isn’t really that big of a demand for this type of fine grained control in a home context (the H in openHAB stands for “Home”) and it’s a really big problem to solve well.

Thank you for answering, Rich.

Didn’t know about the ability to hide auto Generated tabs - this sounds the most promising.

Eliminating items from the semantic model is ok - though perhaps this is a little counter to the purpose of the semantic model in the first place.

I hear you on the "Home’ use point - though I would note that OH3 has made significant progress in broadening its appeal through more UX options and rule automation. With more, less technical, users, will come the need for some kind of authentication - especially if there is ever a plan to introduce a commercial model - but perhaps it is still early days.

Cheers

I don’t think that stuck. It’s still in Tutorials & Solutions. :wink:

Actually, many people recommend not putting everything into the semantic model. It really depends on your perspective, and if you’re designing for a regular user then you wouldn’t want to include anything that they don’t need.

The openHAB Foundation is a registered non-profit organization and can’t engage in money-making activities, so there’s no intention to turn OH into a commercial product. Since it’s open-source software, any individual can try to do that themselves. However, they would have to remove all mentions of openHAB and provide direct support to their customers. Alternatively, people can just act as consultants to people who want help setting up openHAB.

Either way, openHAB is not looking to generate profit. That’s why some things (like user management) are less of a focus; the developers need to believe that the work will benefit the majority of users.

1 Like

We do have “some kind of authentication”. It’s just not fine grained as you’d like, which is fine. But it’s there with two roles and the ability to require logging in to access anything in OH. I don’t want future readers of this thread to think there is no authentication at all.

And perhaps some day a developer will volunteer to implement more fine grained controls. It’s impossible to predict really.

There are some people using OH in some commercial/industrial contexts, but they do so knowing the limitations of the platform and they often get warnings from us. IMO, the core architecture of OH makes it unsuitable for any context where health and safety are a factor which pretty much eliminates almost all commercial and industrial contexts. OH lacks real time processing, transactions, and guaranteed order of operations which, when data comes in too fast means what OH will do with them is non-deterministic.

I forgot to move it. :flushed:

1 Like

Thanks both!

You can restrict who sees those tabs with this property:

However at the moment there’s no RBAC system wrt. items (I suppose these are most important objects to “segregate” as things and rules are not accessible to non-admins anyways - but there could be a need for those as well). Any such restrictions that you see in the UI are only for display purposes and won’t restrict a tech-savvy user to do the proper API call and achieve what they want.
That being said with visibleTo to you can:

  1. restrict the display to additional roles (role:apartment1) (that you define in the Karaf console)
  2. restrict the display to specific users (user:landlord)

I know RBAC systems have been implemented in forks but they aren’t part of openHAB because they haven’t been suggested for inclusion to the upstream yet.

1 Like

oh wow. I did not know this. Because in the UI you can only choose the role, but not the specific user. This is great. Thank you.

Why you don’t leave your overview page blank (or only show general information like time and weather).
Then you create pages and give specific access to do controls or anything else?

This option does not exit in the tapped pages. Is there a special reason for it?
I can not edit the parameter because it is not shown on the ‘Code tab’. Also I can not create it manually. When I save the page it is disappearing. I am missing:

config:
  visibleTo:

At the moment I am running openHAB 3.3.0.M3.

I think it’s all or nothing.

You can hid all the model tabs or show all of them based on user.

Or you can hide certain tabs from all users with that “Hidden Model Tabs” option.

An other (less practical way) would be to run 2 instances of openhab. The fist one with the ‘low security’ thing/items and the other with all your stuff.

Also you can do for “normal” pages. E.g. chart page:

Now I have one problem: Why is this not possible fĂŒr tabbed pages? The configuration is missing in the codes tab:
@ysc Do you have an explanation for this?

There is already an issue filed on github:

This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.