Forums : OR Boss Security
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.
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.
Sure, the real security occurs on the controller REST API though (on securing actions). Securing the view is a lesser item.
|Document generated by Confluence on Jun 05, 2016 09:31|