Figure 3.14: The pixel history graph: the profile of the thematic pixel evolution over time is displayed in a matrix that eases seasonal and yearly pattern identification. Each cell is filled with a colour representing the thematic class observed for a the same area at the time identified by year-day crossing.
(land cover) observations where the stems are the years for which some data may be available in the archives (it is potentially covered by a data source) and the leaves are uniformly sized boxes, coloured according to the observed value and the absence of data is considered a valid observation for plotting purposes that is assigned the plot background colour. The result is a matrix that displays the class observed at any given day in rows, each row representing a year and each year presented below the preceding one; year stems are chosen to ease identification of phenomena following yearly cycles that become clearly identifiable along rows while the identification of patterns across year is also eased by consistency of day of year along along column, to ensure alignment to calendar days, a background coloured box is also added corresponding to February 29 for non leap years. That design makes the PXH also comparable to multiple run charts for categorical variables over a year, since it is a multi-row plot on the temporal dimension. The PXH visualization matrix is outlined in Figure 3.14. The Pixel History graph can also be used to select identified patterns by selection of cell ranges to be used as a basis for evolution model definition. The other elements of the interfaces are also oriented toward the specific goal of the system and are defined in detail in chapter 5, where examples of Pixel History graph display of actual values are also presented.
3.5
Access Control
Along the access control model introduced in 2.1, which is centred on object ownership, use groups and simple level of authorization paired with user roles, the following access control policy have been defined for the MEA system. By definition any unregistered
46 CHAPTER 3. MULTI-TEMPORAL ANALYSIS SYSTEM user accessing the system, if allowed to do so, is assigned the standard user role for the duration of his session and some additional limitations may be applied to him as an unregistered user. Unregistered users are also by definition members of the system group “Everyone” while registered ones are members of the “Registered” group: those system level groups are defined to allow assignment of permissions to a broad category of users without the need to list them in a user group. Furthermore, each user can belong to one and only one of the defined user roles: Expert, Standard and Administrator.
Having defined system level user roles (used to present different views of the system and its functions, thus regulating access to the system interfaces), we can now detail the authorization policy with respect to user provided access to controlled entities (i.e. Evolution Models): that model is based on the two essential concepts of ownership and user groups, according to the following principles:
Three permissions are defined: read, edit and run (taking from the Unix read, write, execute flag set) and are granted to user groups (not to individual users); A set of operations available on models is assigned to each permission label as
listed in 3.2;
Users are grouped into user groups where each group has an owner (by default its creator) who is the only user (besides administrators) authorized to add or remove users from that group;
Each Evolution Model has an owner (by default its creator) who is the only user (besides administrators) authorized to manage the model and to grant or revoke access permissions for it to user groups.
Following the aforementioned principles, any user group may have different per- missions for different EM so that a project may have its own groups to manage who can edit models related to that project or thematic collections of models may be made accessible according to thematic user groups to ensure their prompt accessibility. An approach to allow administrative delegation over user groups is also proposed by grant- ing Expert users the permission to create new user groups without requiring action by an administrator. This approach has been chosen to ensure autonomy to (potential) model owners in deciding who is going to access their models and how. This approach
3.5. ACCESS CONTROL 47
Ownership Group Permission User role Operation Model Group Read Edit Run Expert Admin
Create model V V
Change model ownership V* V View/copy model V V V
Edit model V V V
Apply (run) model V V V
Publish model V* V
Restore published to editable V
Delete Model V** V
Withdraw published model V
Create group V* V
Delete group V V
Edit group V V
Assign group permission V V Change group ownership V* V Change group membership V V Add users to the system V
Delete users V
Manage users V
(*) revocable semi-administrative operation; (**) actually a “hide element” operation.
Table 3.2: Permissions reference matrix
of granting semi-admin privileges to Expert users also allows to ease management of permissions at project level. Suppose some project requires creation and use of ex- perimental models for a given study; permissions can be easily managed by Experts involved in the project by creating a user group for that project to effectively grant user permissions, without requiring an administrator to intervene.
Besides user defined groups, the applicability of that same model to manage per- missions for the entire user community and the general public, two default system level groups are also foreseen: “Everyone”, that includes any user accessing the system and “Registered”, comprising only registered users: by granting specific permissions to these groups a model owner can make his model publicly accessible.
Figure 3.15 illustrates and example of group assignments and permissions for mod- els, clarifying a possible scenario.
Supposing that User 1 is the owner of all the three models, the following applies2: Owning them, User 1 has full permissions on model 1, 2 and 3, regardless of
group permissions;
48 CHAPTER 3. MULTI-TEMPORAL ANALYSIS SYSTEM
Figure 3.15: Authorization policy example
of the Registered group); Run models 1 and 3 (due to Everyone system group); User 3 can: Read model 2 (as a Registered user) and Run model 1 (as member
of the Everyone group) and model 3 (for group permission).
The expert user who defines a model becomes its owner and is the main referee for that model. The owner grants permissions to other users (with respect to that model) and is the only user that can decide whether or not to mark its model as stable or make it accessible to the user community. During its development stage, an EM can be accessed only by expert users that are developing it; when model has reached a stable point where it can be effectively used by the user community it can be published: by publishing a model, the model owner creates an immutable copy of that model that can be applied by any authorised user. Once a model is published, only an administrator can remove it from the available models.