Group Concept

Roles essentially provide a way of grouping subjects together. This idea is now almost universally applied in organisational computer systems. Most operating systems, including the current versions of both Windows and MacIntosh systems, utilise hierarchical group structures. Groups in such systems are very similar to, if not identical to, RBAC roles.

Useful Aspects:

The concept of roles and groups are now central to access control systems. The idea of placing users into groups is a task that is well understood by systems administrators. The existence of role/group hierarchies has also assisted in simplifying administration. Systems have evolved which routinely facilitate role/group management.

Problem Aspects:

While the possibilities of utilising roles on a large scale are attractive, applying RBAC to large organisations has proven difficult. Kern & Walhorn (2005) give some insights into role management in a number of large organisations which vary from having 150,000 users with 50 roles at one extreme to 11,500 users with 2800 roles at the other. They state that “the administration of roles in large organisations can become quite cumbersome and needs to be automated”. If roles are to be used

on a more global scale, the task becomes even more complex. Rhodes & Caelli (1999, p. 1) state that “…emerging networked systems, which have greater numbers of users, roles, and program components, challenge the expressive power of these classical RBAC models”.

DR#7: Hierarchical Groups

3.3.2 Context Concept

Many RBAC based models have taken contextual conditions into account in order to model complex access control needs. The basic idea is that as well as using role- based controls, certain context variables are checked at runtime to determine whether accesses should be permitted. Neumann & Strembeck (2003) define a conditional permission as an RBAC permission which is constrained by one or more context constraints. Attributes representing context conditions are often stored for each user. For example, each user could be given an attribute which described their current location. Certain types of accesses could then be restricted to users in specified locations. Other researchers that use this approach include Bacon et al. (2002), Beresnevichiene (2003), and Georgiadis et al. (2001).

Useful Aspects:

The approach extends RBAC and preserves its advantages. It offers an additional means for the definition and enforcement of fine-grained context-dependent access control policies (Neumann & Strembeck 2003, p. 1).

Problem Aspects:

There is a fundamental problem with the approach because all users need to be given each attribute, say location, even if it is totally irrelevant to their access needs. To find which users have a particular attribute requires all users be searched. It seems likely, therefore, that there are more efficient ways to achieve this functionality. Also, the attributes are checked at the time that an access is requested. If access is given at this point and an attribute changes so that access should be denied, there is no obvious mechanism to stop the access. The proponents of these systems refer to

best described as “static” because changes in context do not trigger any access review mechanism.

In this dissertation a context check is a static process and the word context implies a one-time condition checking process. In contrast, 3.3.4 deals with constraints, which imply a dynamic process.

DR#8: Represent Contexts

3.3.3 Multiple Contexts

Fernandez (2005, p. 2) points out that current methods using Access Control Lists (ACLs) and group based policies have had problems modelling multiple contexts. He states that “…static listings usually determine resource access by evaluating an object’s name or unique identifier. Groups determine resource access by evaluating a single object characteristic. However, resource access is usually based on the evaluation of multiple object characteristics contained in an object profile”.

Another aspect that requires modelling are “negative permissions” (Gollmann 1999, p. 38), where the onus is on denying a particular access instead of allowing all the other possible accesses. Allowing all possible accesses is much more complicated than making a general rule with limited exceptions (denials). Negative permissions are also necessary because there are circumstances where access needs to be specifically denied to a particular user, say, to a hospital worker who is an ex-partner of a patient.

In order for fine-grained control to be achieved in an access control system, the system must be able to take more than one context into account. For example, an access request may need to take a worker’s role, the current time and their location into account before granting access. It must be possible to form complex rules. The problem is that complex rules normally incur inordinate administrative overheads. Simple administrative techniques that have a degree of automation are required to ensure that overheads are acceptable.

Two related issues are how to store the rules and how to process inter-domain access requests. These are addressed at 3.10.

3.3.4 Constraint Concept

Beresnevichiene (2003, p. 16) states that “[a]uthorisation constraints are an important aspect of access control and are a powerful mechanism for laying out higher level organisational policy. With the help of constraints the designers can lay out a broad scope of what is acceptable, and make it across administration domains”.

In RBAC security policies are expressed as constraints (or rules) on users and roles; separation of duties is a well-known constraint (Bertino et al. 1999, p. 1). RBAC based models use the concepts of sessions and mutually exclusive roles to deal with separation of duties.

Useful Aspects:

The need to be able to model constraints in access control has been accepted. Botha & Eloff (2001, p. 1) give a clue to the solution for modelling constraints when they point out that “[t]he workflow environment, being primarily concerned with the facilitation of complex work processes, provides a context in which the specification of separation of duty requirements can be studied”. One of the fundamental arguments presented in this dissertation is that Workflow Managements Systems should be used to enforce constraints. It was the study of this topic that led the research into the Business Managerial field.

Problem Aspects:

RBAC based models fundamentally don’t deal well with constraints. Beresnevichiene (2003, p. 16) states that “[u]nfortunately, the analysis and enforcement of constraints within role-based security systems has been only preliminary and tentative” Bertino et al. (1999, p. 1) concur in observing that “[u]nfortunately, current role-based access control models are not adequate to model such constraints”. El Kalam et al. (2003, p. 1) go further in arguing that “[n]one of the classical access control models such as DAC, MAC, RBAC, TBAC or TMAC is fully satisfactory to model security policies that are not restricted to static

permissions but also include contextual rules related to permissions, prohibitions, obligations and recommendations”. Pappas & Hailes studied traditional access control models and found that “[a]ccess control mechanisms currently employed in various applications lack the power to provide (express and enforce) complex, dynamic relationships between users and resources in a scalable and consistent way” (Pappas & Hailes 2003, p. 1).

This dissertation argues that the fundamental reason why these models do not deal with constraints is that constraints represent relationships between processes (or tasks/services). The relationship is between the states of different processes. In other words, there is dependence between processes. As the states of the processes change dynamically, static attributes and static components like sessions and mutually exclusive roles cannot represent these relationships in a simple way, or indeed at all. In contrast to constraints, contexts are independent in nature in that one context does not affect another. For example, a Worker’s role does not affect their location, though both may be relevant to determine if an Authorisation is to be given. The dissertation argues that the fundamental difference between “context” and “constraints” is that contexts model static independent conditions whereas constraints model dynamic dependent conditions.

DR#10: Represent Constraints

The requirement to model constraints is evident in Access Control Research but there is no clear solution within the Research Field. Solutions are, however, evident in IT Business Management research (see 3.12.3).

3.3.5 RBAC Conclusion

While the study of RBAC (and its derivatives) revealed some key Design Requirements and other important issues, it essentially revealed that there were considerable problems relating to practical RBAC implementations. It was therefore deemed insufficient to base the Model on RBAC. As this is a substantial issue, a detailed argument as to why RBAC was not preferred is contained in the Results and Discussion chapter (Chapter 7).

While the Model does draw on the RBAC Design Requirements listed, it incorporates its own unique access control system. This system draws on the Business Management and Legal fields as well as other access control and IT research.

3.4

Set Theory

3.4.1 Set Based Access

Set Theory is a foundational mathematical model and is well known and understood. It has very broad application, indeed Lehnen (date unknown) states that “the goal of Set Theory was to provide a common axiomatic basis for all of mathematics”.

The thought here is to model groups using set theory. In set theory a set is essentially a collection of things of any kind. A group could also model a collection of things of any kind; for example, a group of users, a group of objects, a group of tasks, or potentially any other collection of things of the same kind. The benefit would be that set operations could be used to specify rules involving groups. For example, the Rules of Set Theory can be used to describe interactions between associated roles and associated object groups.

Set theory has been used as the basis for a number of computing mechanisms. For example, Dovier et al. (2000) incorporate set theory in their studies into handling constraints in logic programming. More specifically, there are a number of examples where set theory has proved useful in access control. Chen & Sandhu (1996) use a language based on set theory to specify constraints in a role-based model. Set theory is also the basis of the Role-based Trust Management Framework proposed by Li & Mitchell (2002, ; 2003). They define new operators to facilitate authorisations from multiple individuals in different roles.

Useful Aspect:

The benefit of basing groups on sets is that set operations can be performed on combinations of groups. For example, users can be grouped into sets and set operations can be used to allow privileges to be given to set unions, intersections and

relative complements. This is significant because fine-grained access control rules can be specified without the need to add additional groups to represent fine-grained roles. Group/role management is a much simpler task with because there are fewer groups to manage. For example, the intersection of “Doctors” and “Patient A Care Team” groups can provide what previously needed to be defined as a separate “Doctors for Patient A” group.

DR#11: Set Operations