As discussed earlier in Section2.3.1, auserrepresents both people and non-human entities that need to access a particular web application, and it would be beneficial to support user modelling in a RIA modelling language. User modelling is very closely related to access control modelling, as user au- thentication often requires both authorisation and authentication.
There are many different techniques and methods for describing the roles of users in secure sys- tems, and for describing how resources may be accessed or permissions granted. Depending on the scope and requirements of the modelled system, the access control model can either be very simple, or very detailed. In this section, a number of existing access control methods will be discussed; however, a full discussion on the security properties of each of the following systems is well outside the scope of this thesis.
Because access control is generally an overarching property of the system, the complexity man- agement techniques discussed earlier in Section4.1may be applied to access control modelling. For example, aspect-oriented modelling can be used to define system access separately from other system functionality; UWE uses this approach to model access control in web applications by using UML state machines [374]. However, the ISO/IEC 9126 software quality model defines access control as a functional requirement of a software system [166].
As Ceri et al. [52] discuss, although some user information is generic – for example, most web application users have an e-mail address and a password – other information is domain-specific. A modelling language for web applications therefore needs to support profile modelling for specific domains, whilst still supporting common user modelling scenarios. In many ways, user modelling can be considered a form of domain modelling, and this concept is discussed further in Section5.10.1.
4.8.1 Access Control Lists
AnAccess Control List(ACL) is perhaps one of the simplest forms of user access control in computing, and forms the core of many of the other approaches discussed here. ACLs allow an object to be associated with a list of permissions against particular users and groups. When the object needs to
4.8 Users and Access Control 81
Figure 4.16: Component lifecycle events in OSGi [318], represented using a UML state dia- gram
Scope Represents Example Use
Component elements in the DOM Once an interactive map has loaded, move focus to a text box. Request a single HTTP request Transform generated XML to HTML at the end of a request. Page many requests over AJAX Close a previously-opened window when the parent page is
closed. Session a single web application
session [246]
Delete a temporary shopping cart on session timeout. Login user authentication over
many sessions
Save a temporary shopping cart to the database on logout. User the user itself When a user closes their account, delete all their previously-
saved blog entries.
Application the RIA itself When an application is initialised, create temporary adminis- trator accounts.
Table 4.3: Possible lifecycle layers of Rich Internet Applications and their potential use, adapted from Wright and Dietrich [368]
File 1 File 2 File 3 Program 1
Ann own read execute
read write write
Bob read read
write
Carl read execute
read
Table 4.4: Example of an Access Matrix, adapted from Samarati and di Vimercati [292]
be accessed by a client, the client is evaluated against the list of permissions provided by the ACL in order to identify its current permissions.
Traditional Unix permissions are a simple form of ACLs applied to file systems, where every filesystem object is provided with three permissions (read, write, and execute) for three types of users (owner, owner’s group, and other users). Unix permissions are widely used in computing and in the deployment of web applications. However, Unix permissions can become too simple and limiting when different objects regularly need to be shared with specific people. Since permissions cannot be assigned per-user but only per-group, providing the same permission to two users involves the creation of an entirely new group.
4.8.2 Discretionary Access Control
Discretionary Access Control(DAC) policies are based on individual users, and on access rules stating what permissions each user possesses [292]. Every user in the system has a set of permissions against every object in the system, and this set may be empty. These rules are often represented using access matrices as in Table 4.4, but as the matrix is usually sparse, policies are often implemented using ACLs instead [135].
As secure systems often deal with large numbers of both users and objects, DAC policies can quickly become overwhelming. Without a concept of roles or groups, it can be difficult to accurately apply new permissions or objects to a common group of users. However since permissions are defined explicitly and per-user, it is not possible to override any of these permissions from elsewhere in the system, improving the inherent security of the approach.
4.8.3 Mandatory Access Control
Mandatory Access Control(MAC) policies are based on mandated regulations, determined by a cen- tral authority [292]. Groenewegen and Visser [135] explain how this policy can be implemented on assigning labels (e.g.TopSecret,Secret,Unclassified) to objects, and users are given a clearance label that indicates their access level. The relative importance between labels is defined by a partial order, and users can only create objects at a level they can access. The central authority regulations are then used to determine access permissions for a particular user against a particular object.
As Groenewegen and Visser argue [135], MAC policies are mainly aimed at preserving confiden- tiality of information, by preventing the unsafe transfer of information contained within objects to other security labels. The use of a MAC-based system is made easier if labels can override lower-level