|
|
Goal
In many programs, users access application data
using GUI widgets: data is created, deleted, read, and updated using
text boxes, check boxes, buttons, and the like.
There is an important, but little explored, link between visualization
and security: When the application data is protected by an access
control policy, the application GUI should be aware of and
respect this policy. For example, the GUI should not display
options to users
for actions that they are not authorized to execute
on application data.
This prevents user frustration, for example, from filling out a long
electronic form only to have the server reject it because the user
lacks a permission to execute some associated action on the application data.
Taking this idea one step further, the GUI should not, for example,
display options to users to open other widgets when these widgets only display
options for actions that the users are not authorized
to execute on application data. That is,
the application GUI should not just be security-aware
but also smart.
To see how this link between GUIs and security policies might
look, consider the following example: an application
for managing employee information. This information will include, among
other data, employees' names, phone numbers, and
salaries.
Suppose now that the employee information is protected by
an access control policy
that includes, among other clauses,
the following:
- All users can read employees' names.
- Only administrators and supervisors
can read and update employees'
phone numbers.
- Only supervisors can read employees' salaries.
Suppose now that, as shown below,
our application GUI
includes the following windows:
- Window #1 .This is our main window. Here,
users can edit employee data by clicking on
the
Edit Phone Number-button.
- Window #2. Users can select an
employee from
a list of names, shown in a combo box,
and view the information
associated to the selected employee by clicking on
the
-button.
- Window #3. Users can read in the
Name, Phone, and Salary-labels, respectively,
the name, phone number, and salary of the selected employee.
Moreover, users can edit the phone number by clicking on the
Edit-button.
- Window #4. Users
can update the phone number
of the selected employee by typing the new number into the
Phone-entry and clicking on the OK-button.
What behaviour should our GUI have
if it is to be considered "security-aware"? Suppose that
a user with the role administrator wants to edit
an employee's phone number using our GUI. Since administrators
are not authorized to read employees' salaries, when
opening Window #3, our GUI should prevent an administrator
from reading this information in the Salary-label.
Furthermore, how should
our GUI behave if it is also to be considered
"smart"? Suppose now that a user with no
special privileges wants to edit an employee's phone number
using our GUI. Since ordinary users are not authorized
to read or update employees' phone numbers, our GUI
should prevent the user from
opening Window #4
by clicking on the Edit-button,
since the user should not be able to do anything
within this window (i.e., neither
read the phone number of the selected employee in
the Phone-label nor click on the OK-button
to update this information).
The problem we address in this project is how to establish this link
between visualization and security. The default, "ad-hoc" solution,
namely, directly hardcoding the security policy within the GUI,
is clearly inadequate.
First, the GUI designer is often not aware of the application
data security policy. Second, even if the designer is aware of it,
hardcoding the application data security policy within the GUI code is
cumbersome and error-prone, if done manually. Finally,
any changes in the security policy will require manual changes to the
GUI code where this policy is hardcoded, which again is a cumbersome
and error-prone task.
|
