Data Access Control represents the other fundamental part of the softwares
security system. Permission schemes and data access control allow full
control over the users options to use and access the software and the
data handled with it. Permission schemes handle the access control to
the applications commands and menus, whereas data access control handles
the users rights to view, copy, modify and delete the data used in the
application. Similar to the permission schemes the access control for
the data is organized in levels - the so called "roles", which
allow the assignment of access rights to the users. Data access roles
are designed to be hierarchical, granting only a few rights to the lowest
level (role) and full rights to the highest level (role).
Data Access Control works best for data contained
in projects.
The applications project format is ideal for handling data in a data access
control environment. Single spectra and data from libraries may also be
signed/used in a data access control context but exporting/converting
to other formats will remove the data access control settings from the
object.
The data access roles will be set up by using the Data
Access Control Wizard which may be invoked automatically after the
initial security setup or manually by selecting the command "Setup
Data Access Roles" in the Security Menu. The administrator of the
software may create any number of roles but the software initially defaults
to 4 access roles. An overview is most easily given by an excerpt of the
Data Access Role Manager which guides the administrator in setting up
the access control system:
This picture nicely demonstrates the four
hierarchically organized access roles. The default role names reflect
the roles position in the hierarchy. The supervisor role has complete
control of all data, the chemist may not delete data, the operator may
only view data and the guest has no rights at all.
All roles are subordinate roles to the top-level
role. Because of this individual access rights for a user to an object
may differ depending on the "highest" role signature the data
object was signed with. The above picture represents the access rights
for an object that was signed with the top-level role, the "Supervisor"
role. If an object has not been signed by a superior role yet, the access
rights may differ. This is illustrated by the access rights view for the
"Operator" role:
As long as the object is signed with the "Operator"
role as the highest role the user may also copy/modify spectra and projects.
After signing the object with a role superior to
the "Operator" role, these rights will be revoked as can be
seen in the first picture. This system represents the general "bottom
to top" workflow (the operator records a spectrum and passes it on
to the chemist/supervisor) as well as the "top to bottom" access
hierarchy.
The administrator may completely customize
the role names, the number of roles and the individual access rights.
This may be done with the Data Access Control Wizard or the
command "Edit Data Access Roles" in the Security Menu.
Simply assigning a role to a user will not
affect his access rights to regular data objects that have not yet been
signed. The actual data access control starts with signing an object which
will "tag" the object with the users role. This is done by opening
the object and selecting the command "Sign Object" from the
Tools menu. The object now resides on the access level corresponding to
the signing role. Higher levels may now still have full access, where
as lower level will have very limited access. Signing an object usually
prepares it to be moved to the next higher level of the hierarchy. This
can be illustrated by a simple workflow:
The operator records a spectrum
and prepares it for the further workflow. He will sign the spectrum to
"approve" it for the next level.
The chemist checks the spectrum
and maybe modifies it further. He will sign the spectrum to "approve"
it for the next level. This will revoke the copy and modify rights for
the lower "Operator" level and will prepare it to be processed
by the higher levels.
The spectrum will be processed
by the next higher level and so on...
Signatures are always permanent and can not
be revoked. If, for any reason, a lower level role needs to have access
rights again that have been revoked by a higher signature, the object
needs to be released from the normal data access hierarchy by a "release
signature". This will remove any data access restrictions from the
object.
Signatures are permanent and can not be removed!
Once a signature has been issued it is permanent and can not be removed
from the object again! If a lower level access - which normally would
be prevented by a higher level signature - needs to be enabled again,
the object has to be released from the data access hierarchy by a release
signature.
The actual signature can be accompanied by
a signature comment to express workflow related information. In the default
setup for example, the operator may choose between the comment "Accepted"
or "Measurement failed" when signing objects. All signature
comments may be customized by using the command "Manage Signatures"
from the Security Menu.
