Living Room

Stereo Off |
Computer |
AirTunes |
94.9

Roku |
Apple TV |
XBOX

Vol-Soft |
Vol-Normal |
Vol-Loud

Lights-Normal |
Lights-Soft |
Lights-Off

Kitchen

Stereo Off |
Computer |
AirTunes |
94.9

Bedroom

Stereo Off |
Computer |
AirTunes |
94.9

Bathroom

Stereo Off |
Computer |
AirTunes |
94.9

All Rooms

Stereo Off |
Computer |
AirTunes |
94.9

All Lights Off |
All Lights On

Wake Radio:

Disable |
Enable

Hi bTwix,

 

Unfortunately not. It's going to be pretty difficult to figure out what URLs require authorization and which ones don't.

 

With kind regards,

Michel

How about a global checkbox that allows anonymous access to "/rest/*" and "/user/*"?

 

Thanks for considering it.

 

Phil

Hi Phil,

 

We would certainly consider it.

 

With kind regards,

Michel

Hi Phil,

 

Unfortunately we have decided not to implement this feature since it will completely break our security model. This said, we have decided to look further into authentication/authorization.

 

With kind regards,

Michel

Thanks, Michel.

 

For authentication/authorization, an anonymous access feature by resource would be ideal:

- /programs

- /user/web

- /vars

- /elk

- ...

 

Since we have a secure network, if they have physical access to an Ethernet jack they also have physical access to the light switches, TV remote, etc.

 

I appreciate that not all users may want anonymous access, but it definitely simplifies ease of use and wife approval factor.

Hi bTwix,

 

Thanks so very much for the suggestion and feedback. This has been on our requirement list for a VERY long time. The reason is that every time we try to implement it, we face much deeper security challenges.

 

As far as the wife factor, most http clients support Basic Authentication. Is it difficult to hardcode ISY's userid/password in your client? i.e. I am just delegating the security hole back to your client

 

With kind regards,

Michel

I have wondered why you could not use certificates on the mobile device and have the ISY check it? Or a SSH type arrangement where you have to specifically allow rsa keys' to have them talk.

Hi Alan,

 

You could do that with PRO series. This said, this will make ISY not accessible to any device that can do https BUT not client authentication.

 

With kind regards,

Michel

Thanks Michel.

 

Could someone elaborate on how one could tell if your device can support this specifically? E..g. does chrome on android support this vs the device supporting this.

 

I assume mobilinc supports this method.

Hi bTwix,

 

Thanks so very much for the suggestion and feedback. This has been on our requirement list for a VERY long time. The reason is that every time we try to implement it, we face much deeper security challenges.

 

As far as the wife factor, most http clients support Basic Authentication. Is it difficult to hardcode ISY's userid/password in your client? i.e. I am just delegating the security hole back to your client

 

With kind regards,

Michel

 

>> Is it difficult to hardcode ISY's userid/password in your client?

No, that's fine. The issue is that I want the ISY web module to *host* the client web page (remote.htm), so if ISY is up I can control the house via remote.htm, even if my home server is offline or gone (future). However since /user/web doesn't support anonymous access, I have to type in the ISY user/pass every time to access remote.htm if hosted with the ISY web module in /user/web.

 

Can you add a checkbox to enable anonymous access to /user/web, so I can host my remote.htm using the ISY web module? I'll hardcode the user/pass in remote.htm for the other REST calls.

Hi btWix,

 

Got it. This is much easier ... thank you.

 

With kind regards,

Michel

Maybe a per-folder 'Allow Anonymous Access' attribute that can be set - in case we don't want to allow the full /user/web to be accessible? Default it to 'Off' on each folder (so there are no nasty security surprises for anyone).

 

So, for example, I could write log files to /user/web/logs, and authentication would be needed, but an 'index.html' could be served without authentication from /user/web

 

Just my $0.02. I'd make much better use of the user web space on the ISY with this feature.

Hi Michael,

 

This is precisely why every time we try to add anonymous, it immediately becomes a huge requirement to revamp authorization in ISY. Adding a simply boolean at /USER/WEB is easy. Adding a password file for each directory requires investigation of what we ultimately want to do.

 

With kind regards,

Michel

>> Adding a simply boolean at /USER/WEB is easy. Adding a password file for each directory requires investigation of what we ultimately want to do.

Agree. I'd prefer to keep it simple to start (vs. getting nothing). Per directory security would be nice to have, but not required for 80% of the value.

 

>> Default it to 'Off'

Agree.

How about a simple variation on .htaccess..... If there is a .anon file in the directory that the file being requested is in, allow anonymous access. Otherwise, require authentication. It's then up to us to create the .anon file if we choose to allow anonymous to that folder and all files within.

 

Should be easy to implement, and shouldn't break anything (since default would be to require auth).

 

Gives more than 80% I think. And does not need a full revamp.

 

Now, password-less access to the REST interface I agree is a bit more challenging.

I would think the ISY could store one or more 'authorization' strings - and if one of the strings is supplied as a REST parameter, authentication is bypassed. Simple enough..

A bit like API tokens are generated and used by NotifyMyAndroid, Prowl and Pushover (all do this exact thing). ISY is easier because its a single user system.

Hi Michael,

 

ISY is not Linux based so whatever we do is going to be from scratch. .password and .anon are basically the same (or reverse of each other) and something we are definitely considering.

 

Again the simplest path forward is to make /USER/WEB directory either protected or not protected.

 

With kind regards,

Michel

Michel,

 

Sounds good. Thanks.

 

Michael.

I like the ".anon" for /USER/WEB/

 

I like the API KEY for the REST interface (even just one). Especially as I look to integrate with other things.

 

When can we expect at least the .anon portion?

Hi ticklemeozo,

 

Unfortunately we do not plan to provide any unrestricted access to ISY especially given all the reports of security holes/attacks to home automation devices.

 

With kind regards,

Michel

An API Key in the URL over SSL is hardly "unrestricted".

 

I'm pretty sure that:

//192.168.1.100/rest/nodes/12345/key/772ac1a55fab1122f3b369ee9cd31549/cmd/dof

is much more secure than:

//admin:admin@192.168.1.100/rest/nodes/12345/cmd/dof

My first guess on any basic authentication mechanism is going to be "admin:admin". It's going to take a while before you guess my api key. Even unencrypted, the api key still gives me a fighting chance over basic authentication.

 

With multiple API Keys, I can revoke certain devices. Rather than having to change my password on my other n-1 devices because a password leaked.

 

Respectfully.

Hi ticklemeozmo,

 

You are 100% correct and I am not disputing that API keys are more secure. This said, currently we do not have that framework and it'll require much development and major regression testing.

 

At the moment, we do recommend:

a) Changing the certificate

Accessing ISY using HTTPS when outside (even inside)

c) Change your password

 

With kind regards,

Michel

Michel,

 

While we're discussing authentication, would it be possible to implement HTTP Digest authentication (RFC 2617 - http://tools.ietf.org/html/rfc2617) instead of HTTP Basic Authentication? SSL is just too unacceptably slow (takes about 5-10 seconds to turn off a light switch from eKeypad vs almost instantaneous using plain HTTP) but I'd like to have more protection of my password than plain HTTP Basic Authentication provides (that is, none). Is this a possibility?

Hi giesen,

 

Yes we can but even that requires development.

 

I am concerned that SSL is taking too long. It should NOT if the client (i.e. eKeypad) uses session resume. It should only take 10 second on the initial connection. The rest should be just a little longer than http (still less than a second).

 

With kind regards,

Michel

I had not come across resume, does that mean the same subscription that was closed, or something else? Where specifically in the rest docs would I find that one?