Login as non-admin

[elionce]

How can I login to the ISY as a non-admin user account?  I've searched high and low, but couldn't seem to figure it out.

There are quite a few obvious issues with just always logging in as admin (i.e. it's unnecessary to have full administrative privileges just to perform simple device control; I have to give all family members and/or guests the admin credentials even if they're computer illiterate / don't know how to use password managers; having everyone always login as admin leads to using a less complex password than if I were the only one using it; leaving the admin credentials "remembered" on mobile devices could potentially be a security issue if the device gets lost; logging in as admin from unknown/untrusted networks could potentially be an unnecessary security risk; etc, etc, etc).

I can't recall if I asked this somewhere before, but couldn't find it, so apologies if it's a repeat

[Brian H]

I don't believe it is a possible option. As I have never seen a reference to a users only log in.

 

[lilyoyo1]

It's not possible. The admin console was created to program and configure not for controlling devices

[elionce]

I'm not referring to logging into the full admin console as non-admin.   Just to do basic device control (i.e. from Agave app on Android, from the web UI in browsers, from the rest API, etc).

[lilyoyo1]

2 hours ago, metal450 said:

I'm not referring to logging into the full admin console as non-admin.   Just to do basic device control (i.e. from Agave app on Android, from the web UI in browsers, from the rest API, etc).

You didn't make that clear in your previous post.

I don't use interfaces to control my house so I can't speak on that. I know mobilinc pro can be set to where access can be had for specific tasks such as locking others into a favorites screen. Can't speak on if agave has that capability as I've never used it. 

[elionce]

That would still be limitations placed by the client application, which doesn't really address the issues mentioned above.  Every device is still storing the full administrative credentials, sending the full administrative credentials over the wire with every command, etc. If a guest comes over & wants to be able to flip some devices on or off from the web UI, they still need to be told the full administrative credentials.

I don't really see how a limitation placed by Mobilinc or Agave would address any of this...?

[lilyoyo1]

11 minutes ago, metal450 said:

That would still be limitations placed by the client application, which doesn't really address the issues mentioned above.  Every device is still storing the full administrative credentials, sending the full administrative credentials over the wire with every command, etc. If a guest comes over & wants to be able to flip some devices on or off from the web UI, they still need to be told the full administrative credentials.

I don't really see how a limitation placed by Mobilinc or Agave would address any of this...?

It doesn't. It's a work around for something that doesn't exist. Personally, I wouldn't give guests access to any interface regardless of permissions. 

[elionce]

Bummer. Just curious if there are any plans to rectify this?

Frankly I'm a bit shocked that this doesn't come up more often - I can't really think of any online/remote system I've ever worked with where the sole way to interact with it is with full administrative credentials. It feels so nuclear to say either "give access to every single function with no limitations," or "can't use it at all."

[lilyoyo1]

20 minutes ago, metal450 said:

Bummer. Just curious if there are any plans to rectify this?

Frankly I'm a bit shocked that this doesn't come up more often - I can't really think of any online/remote system I've ever worked with where the sole way to interact with it is with full administrative credentials. It feels so nuclear to say either "give access to every single function with no limitations," or "can't use it at all."

Probably not. At least not in the near future. The way Ive set my system up, no interface is needed. What little human intervention that is needed is provided using voice or keypads

[elionce]

I don't doubt that scenarios could exist where proper user credentials aren't necessary. I guess yours is one such scenario. Mine is not.

[simplextech]

9 minutes ago, metal450 said:

I don't doubt that scenarios could exist where proper user credentials aren't necessary. I guess yours is one such scenario. Mine is not.

I've sorta followed this but not closely...

So what is your scenario?  Why do your guests need admin access?

[elionce]

Guests do *NOT* need admin access - that's the issue. The only access that can be given currently is admin, to everyone, on all devices.  So if I want to i.e. give someone a way to easily turn something on or off via the web UI...it can't be done. Either I give them the administrative login, or nothing.

Plus the other security-related issues mentioned above (storing full admin credentials on devices unnecessarily, sending full admin credentials over the wire unnecessarily, etc).

[simplextech]

3 minutes ago, metal450 said:

Guests do *NOT* need admin access - that's the issue. The only access that can be given currently is admin, to everyone, on all devices.  So if I want to i.e. give someone a way to easily turn something on or off via the web UI...it can't be done. Either I give them the administrative login, or nothing.

Plus the other security-related issues mentioned above (storing full admin credentials on devices unnecessarily, sending full admin credentials over the wire unnecessarily, etc).

For the last part of storing the admin credentials... yeah any interface currently would need the credentials to interface with the REST interface.  That's just the way it is today.  There's been talks about improving that.  It would be nice to move to a token based setup for interface access.

For the first part.  What web UI are you referring to or is this just in general?  The built in UI is not really intended to be AS-IS user facing and is more of a framework to be extended on or used AS-IS and with it's limits of requiring you to login.  There's another project HousePanel that is coming along very nicely where credentials and information are not prompted for by users. 

  

[elionce]

>>yeah any interface currently would need the credentials to interface with the REST interface.  That's just the way it is today.  There's been talks about improving that.  It would be nice to move to a token based setup for interface access.

I agree tokens would be more ideal.  But at the very least, if credentials are going to be sent, it should be possible to not have to send the *admin* credentials. 95% of usage is just controlling devices, not actually modifying programs or reconfiguring - so there's no reason to be giving that level of access to every endpoint.

Analogy: when working on a Linux machine, do you login as root & do every action as root? Of course not - you just sudo the few commands that might actually require it, & the rest of your work uses a regular limited-access user account. And that's just on a local machine.  Here we've got a networked device that effectively requires you to use root for everything. Every client, every command, any access at all, is done as root. Even remote ones executed over the internet.

>>For the first part.  What web UI are you referring to or is this just in general?

In general.

[simplextech]

2 minutes ago, metal450 said:

I agree tokens would be more ideal.  But at the very least, if credentials are going to be sent, it should be possible to not have to send the *admin* credentials. 95% of usage is just controlling devices, not actually modifying programs or reconfiguring - so there's no reason to be giving that level of access to every endpoint.

Ok.  But this is how the ISY works today.  This isn't a multi-user system and doesn't run a multi-user OS.  The reason to need admin access for any interaction is because it's the only access.

The Linux analogy is nice, you must run Ubuntu or Debian maybe.  Most other Linux distros don't come with sudo pre-configured and do require you to login as root and then you can decide if you want to configure sudo or not.  No actual Unix system comes pre-configured with sudo.  So I understand your analogy but it's the exception and not the rule.

The ISY is an embedded system and is not going to have multi-user capabilities today with the OS and hardware it runs on.  It's not designed for that.  There's improvements and changes coming.  That's the whole basis of Polisy afterall. 

Not what I think you are wanting to hear but that's the current situation.

[elionce]

>>Most other Linux distros don't come with sudo pre-configured and do require you to login as root and then you can decide if you want to configure sudo or not.

Well, or you login as a standard user and su (rather than sudo) when you need to perform administrative actions.

Perhaps a better analogy might be my NAS. When the media players login to its media shares to access media, they don't do so with full administrative privileges. When backup software logs into a backup share to upload data to it, it doesn't send full administrative credentials over the wire. Only when actually performing administrative tasks will one login as admin. Same is true for my security camera controller, database server, and so on. Indeed there is exactly one device I have running where every client is always admin - and you can probably guess which that is

>>There's improvements and changes coming.

Fingers crossed! ?

>>That's the whole basis of Polisy afterall.

I wasn't aware of Polisy. Seems like this additional device is aimed at providing a different set of integrations than I actually need though. The existing ISY's functionality is already fantastic - it's just the inability to use it in a security-conscious way that's a bit troubling.

>>The ISY is an embedded system and is not going to have multi-user capabilities today with the OS and hardware it runs on

I hear that the answer is "no it's not available," but just to respond to this, checking user permissions is almost certainly not limited by hardware or by virtue of it being an embedded system. If the hardware can validate one set of user credentials, I can't think of any reason it'd be unable to validate against a few.  It's really just a matter of it not having been coded (yet, hopefully).

[kclenden]

On 4/7/2020 at 4:40 PM, metal450 said:

If the hardware can validate one set of user credentials, I can't think of any reason it'd be unable to validate against a few.  It's really just a matter of it not having been coded (yet, hopefully).

I don't think the issue is validating more than one set of credentials.  It's more likely the necessity of defining a security structure and then building it.  First you have to define what levels of access are going to exist, then define which devices and actions fall under which access levels, and then create a structure and methodology to enforce the different levels.

Sure, based on what you're asking for, you could probably just create two levels (one with total control and another that lets you do everything but program) but you effectively already have that based on whether you're using the Admin Console or just web access.  More likely, even with just two levels of security, you'd want the ability to assign devices and scenes to either the ANY (anyone can control) or ADMIN ONLY (only Admin can control) level.  To do that, you'd have to modify the UI, and underlying ISY operating system.  You'd have to review every possible usecase and decide how security should handle it (e.g. should an ADMIN ONLY device be allowed to exist in a scene with an ANY device?)  And even after doing that, you'd be left with a kludge since Insteon doesn't support different levels of security, so even just having the lowest security level (ANY) would give you a theoretical avenue to controlling ADMIN ONLY devices that you're not supposed to be able to control.

[elionce]

5 minutes ago, kclenden said:

I don't think the issue is validating more than one set of credentials.  It's more likely the necessity of defining a security structure and then building it.

Right, of course it would have to be built (aka would have to be implemented by the developers of the ISY).  I was merely responding to simplextech's statement that it's "an embedded system and is not going to have multi-user capabilities today with the OS and hardware it runs on."  The hardware, and the fact that it's embedded, is not a limiting factor. The only limiting factor is the fact that the firmware has just not been implemented in a way that takes access control into consideration.

10 minutes ago, kclenden said:

you effectively already have that based on whether you're using the Admin Console or just web access.

...No - again, access control is a server-side issue, not a client-side one.  Whether you use the Admin Console or web access (or rest api or mobile app) is irrelevant to the issue I'm describing; you're still always communicating with the ISY via the same admin credentials, which have full permission to do everything.  There is no credential I can give someone that will let them only work with the web UI, but not the admin console.

13 minutes ago, kclenden said:

you'd have to modify the UI, and underlying ISY operating system

Right.  Thus, the conclusion was: the ISY simply cannot do it (as it's currently been implemented) :P

[KeviNH]

Speaking of Linux, if you are running a Polyglot nodeserver on Linux (e.g. on rPi), you can install NGINX as a "proxy" and set it up to store your admin credentials and provide "guest" users access to just certain URLs.

I've got this configured so the  UDAjax web interface is accessible to most internal users, allows viewing all device status and controlling most devices, and also "RunIF" for programs, but nothing else - no admin console, no network resources, etc.

Not saying this solution is something the average enduser can build and deploy without considerable effort, but it does work.

[elionce]

33 minutes ago, KeviNH said:

if you are running a Polyglot nodeserver

I'm not, & that sounds like an awful lot of work.  Which to me that just serves as evidence that proper user credentials *is* something people actually want/need.

[simplextech]

1 hour ago, metal450 said:

I'm not, & that sounds like an awful lot of work.  Which to me that just serves as evidence that proper user credentials *is* something people actually want/need.

People want a web interface because they want it.  What you and many are wanting is great and doable but UD isn't going to invest into the older platform that was designed around a switch/dimmer/keypad being the user interface not a iPad.

[kclenden]

1 hour ago, simplextech said:

What you and many are wanting is great and doable

Insteon devices do not support separate user access levels.  Neither, AFAIK, does Z-Wave.  So at best UD would be building security into their device that can not be replicated at the device level.  That would merely provide the illusion of security not much better than @metal450 can currently obtain by not showing his guests the Admin Console but merely showing them the web portal.

If his network is setup properly, someone having the admin credentials to his ISY couldn't use them unless they had credentials for his WiFi or physical access to his ethernet network.  If they have that access, then he clearly trusts them more than a random stranger.  Surely he can trust them not to download a rogue copy of the Admin Console to start programming his ISY.

If this goes beyond the ability to program, and it's individual device and scene control that he wants to be able to grant, then that would take a lot of effort on UD's part AND would only provide the illusion of security.  It might provide a little bit of protection against someone accidentally turning something ON or OFF that shouldn't be turned on or off, but he can pretty much already do that by putting devices into separate folders based upon the access level he wants to grant.  Additionally, I doubt even a plurality of forum members, let alone less technical ISY users, would rank separate user access levels very high on their wish list.

18 hours ago, metal450 said:

The only limiting factor is the fact that the firmware has just not been implemented in a way that takes access control into consideration.

UD only controls the firmware to the ISY.  They don't control the Insteon, Z-wave or Zigbee device firmware.  Building security into the ISY level, but not the underlying Insteon, Z-wave or Zigbee firmware only gives the illusion of security which at best might reduce accidental device control.  As mentioned above, there are already ways you can do that via folders and device naming.

[lilyoyo1]

20 minutes ago, kclenden said:

 

If his network is setup properly, someone having the admin credentials to his ISY couldn't use them unless they had credentials for his WiFi or physical access to his ethernet network.  If they have that access, then he clearly trusts them more than a random stranger.  Surely he can trust them not to download a rogue copy of the Admin Console to start programming his ISY.

Additionally, I doubt even a plurality of forum members, let alone less technical ISY users, would rank separate user access levels very high on their wish list.

I agree with all of this. If I cant trust a guest to leave my system alone, they do not need to be in my house at all. Separate user access is not my concern at all due to my previous comment. The fact is, Ive designed my system in a way where an app is not needed while in the house. With keypads on the walls, next to the bedsides as well as voice control, there is no reason for anyway to use an app to turn something on/off

[elionce]

17 minutes ago, lilyoyo1 said:

The fact is, Ive designed my system in a way where an app is not needed while in the house. With keypads on the walls, next to the bedsides as well as voice control, there is no reason for anyway to use an app to turn something on/off

You keep sharing how your system is setup - that's great, but as stated previously, yours clearly isn't the same as everyone's.  I understand that I can invest time & energy in installing a bunch of extra keypanels all over the place to (partially) workaround the lack of user access control.

....And still leave the root credentials "remembered" on everyone's mobile devices for when they aren't home

....And continue sending those full administrative credentials over the internet with every command

....Including if a family member unknowingly ends up using their phone on an unknown/untrusted network

...And continue having to personally setup everyone's client for them, rather than simply being able to say "visit this URL & enter this user/pass"

[elionce]

 

3 hours ago, simplextech said:

UD isn't going to invest into the older platform

Huh? You mean the ISY-994i is an old/deprecated controller, and there's a newer / full replacement for it for which the API does have proper access control...?

54 minutes ago, kclenden said:

Insteon devices do not support separate user access levels.  Neither, AFAIK, does Z-Wave.  So at best UD would be building security into their device that can not be replicated at the device level.  That would merely provide the illusion of security not much better than @metal450 can currently obtain by not showing his guests the Admin Console but merely showing them the web portal.

[...]

Building security into the ISY level, but not the underlying Insteon, Z-wave or Zigbee firmware only gives the illusion of security

Completely false. The ISY is a network-connected device, on the internet, controlled by online devices.  Insteon is a short-range local interface where you need physical access to a device before you can pair it with a controller.  These are not even remotely the same topic.  Saying "there's no point in being able to limit access privileges on a online API, because someone could physically go and unscrew the light switches from the wall and relink them to a new controller" - I don't even know where to begin.

Anyway, this has gone way off the rails and needn't be discussed any further.  I have my answer, and it's clear enough: the ISY runs a REST api where the only way to connect to it is by sending full administrative credentials with every command.  There are no credentials that I could tell any user that would enable them any access other than "administrative."