|
|
|
Shift work — A continuous session under the role is active, but the person executing the role changes at intervals. The role cannot be closed and reopened, because the information must be continually presented. However, the identity of the person undertaking the role must be recorded for accountability purposes. There are similarities to the hospital scenario previously described. Manufacturing — People often have one role most of the time (e.g., as a shopfloor worker), but occasionally need to assume a different role (e.g., acting supervisor). They do not want to close the first role to do the second, but rather suspend the first role. A similar situation occurs when someone in his or her normal role temporarily wants to look at someone else’s mailbox. Retail banking — The range of transaction types permitted for different people in such an environment varies. For example, a teller role will be allowed one set of transaction types and the manager role some additional transaction types. This is probably the archetypal role example. Manager roles may or may not encompass the roles of the individuals under them, depending on separation-of-duty requirements. Further, the same role at different branches may have different affiliations, allowing access only to data relevant to each branch. Senior manager roles may be created that include affiliations that permit them to access data at more than one branch. OTHER ROLE MODELS A 1993 article introduced the concept of roles in its simplest form, without looking at hierarchies or separating the concept of affiliation.3 A 1994 article defined the concept of role profiles, which it describes as all the resources needed for a given role.4 The appropriate role profile is assigned to users who have the associated role. The chapter distinguishes between static and dynamic role profiles, the former relating to long-term business roles, the latter to project-related roles. This chapter shows how a role profile fits into a more general access control profile hierarchy, thereby linking the role profile in one direction to users and, in the other direction, to either transaction profiles (static) or project profiles (dynamic). Both of the latter then link down to resource profiles. There is no concept of role hierarchies or affiliation.
The National Institute of Standards and Technology is adopting yet another model, which includes role hierarchies but bundles up affiliation within the role concept itself. One approach analyzed the role model against general requirements such as least privilege and separation of duty.5
Other papers and articles on various aspects of roles are by Mohammed and Dilts,6 who take a very dynamic view of roles in a data base context; Sterne,7 who discusses the construction of a trusted computing base that can support RBAC; and Baldwin, who describes extensions to SQL that permit users and resources to be grouped into named protection domains, which have many features in common with roles.
SUMMARY The role concept is utilitarian not only for users, who get a simple view of the access rights available to them, but also for managers, the concept forming a stable bridge between the volatility of the user population and the volatility of the resources being accessed. Roles should be used in the context of other access rights. Individual identity and organizational affiliation are two major orthogonal dimensions, the whole making an access control cube. This chapter has also described the various ways in which different organizations actually use the RBAC concept. A unique feature of this chapter is that role-based access control is viewed as being only one mode of control that must exist within a context of other modes — the access control cube. This reflects real-life requirements of systems running many heterogeneous applications.
|