This page last changed on Nov 09, 2009 by juha.

We've started putting in the basic pieces of security in the communication between Boss panels and controller.

I am moving some of this discussion online to record the scope of the first implementation.

The current goal is to be able to secure specific commands being sent from the panel and to secure component value updates being pushed from controllers back to panels.

By 'secure' in this case means encrypted and requiring authentication. The initial implementation secures REST API with HTTP Basic over HTTPS.

The discussion below is related to securing the views on the panel as well as the actions and data updates. While it's a valid argument, I currently consider it a lower priority unless somebody has a compelling use case that would require the static visual elements in the panel to be protected.

By compelling use case I mean a concrete blocking issue, not a vague "well I could foresee needing it sometimes somewhere" (yeah, me too) or "nobody should see my screens because they are mine" (true, but it won't kill you right now).

Note that any component that receives its values from the controller can have those values protected (e.g. I won't see if your bedroom light is on or off, I just see that you can turn it on or off but am unable to do so myself).

Also note that this only relates to a user group that all have been granted access to the same controller (for example, family members sharing the same house). Outsiders (e.g. your neighbours) can be blocked from seeing any of your screen definitions, period.

Regarding user identity list selection, there's something to discuss:

1) if no user identity is selected in iPhone(without login from the begining), user can go through the screens everywhere, iPhone can't restrict navigation to protected screen. because iPhone doesn't know who he is and what he can do or can't do. but tapping the <navigate> can't let iPhone know who he is.

That's correct. Your <user> definition would address this.

However, at this phase of first iteration, I am fine with having a "read" access to the entire group of screens across all users.

We are protecting updateable components' status values so those cannot be seen without authentication, and nobody can execute a protected command without authentication. That's the high priority to complete, so that no actions can be executed without authentication (if they're protected).

Securing screen contents on the panel is nice but a a lower priority for now.

Analogy here to an OS file system is that all users are allowed to change and list directory contents of the entire filesystem (navigate) but cannot change or alter protected files without authentication.

2) groups should be linked to user in panel.xml, telling iPhone how many groups and screens belong to a user, whether he is seeing his own screens, not others'. in this way, iPhone can stop a user before he enters this screen by validating the username.

Sure, the real security occurs on the controller REST API though (on securing actions). Securing the view is a lesser item.

The iPhone side of this implementation

  • managing the HTTP Authorization header addition to REST HTTP requests
  • handling for HTTP 401 responses from the controller
  • Creating HTTPS requests to encrypt the sensitive authorization headers

is being developed and can be reviewed in a feature branch here:

Posted by juha at Nov 11, 2009 11:46
Document generated by Confluence on Jun 05, 2016 09:31