DEFINING ROLES

Three different security management activities are involved in role management:

•  The defining of roles.

•  The allocating of roles to users.

•  The allocating of access rights to resources based on roles.

Who should be responsible for these activities? The last two are relatively easy to position. It is a user administrator (at some level of the organization) who allocates users to roles, and it is the controller of the resource who has the ultimate responsibility for its security, and, therefore, who should decide which roles get access to it. However, it is more difficult to pin down who should be able to define roles.

If roles vary at different levels (and not all roles will be understood across the whole organization), the roles with a wide scope should reflect the overall job for which a user was and should be defined at the whole enterprise level. It is essential that the business significance of such a definition be clearly understood across the entire organization, because it will be this level of role that will be used ubiquitously. Clearly, it jeopardizes security if a resource controller thinks that the role of company secretary indicates that of a company board member or director, or if the user administrator thinks that it was just any secretary working for the company. It seems reasonable that such roles would be defined as part of the company security standards.

In contrast to these globally understood roles, some roles may be specific to a particular department, and some even to a team level. Almost all organizations, in practice, are hierarchical in some way, and any security administration system must reflect this hierarchical organization, enabling authority to be placed where it is most appropriate.

Some roles may be artificial, merely existing to group together users who have a particular series of system-related activities they need to be able to perform. Thinking of this kind of role as a set of activities allows roles of this type to be defined by resource controllers, rather than, as is more intuitive, defined by the user administrator.

These pseudo-roles stretch the concept of role, but they form a useful extension if used with moderation and are confined to coherently related groups of activities that are stable over time. Typically, such roles would not be allocated directly to users but might be identified as part of other more traditionally defined job roles.

ROLE HIERARCHIES

Stemming from the concept of roles is the concept of role hierarchies. More precisely, it is the concept of directed graphs, but it is easier to think of it as a set of multiply-linked hierarchies. Specifically, role types should be related to each other so that one role can encompass other roles, which can then encompass others. In general, any given role can be contained in more than one higher role, but there must be no loopbacks. The rule is that a user who has been granted a higher-level role is also automatically granted the roles contained in it. The definition of roles becomes an activity that is extended to include the definition of these relationships. Organizational affiliation can also be defined in this way. Although further discussion of this topic is not within the scope of this chapter, much of what is said about role definition applies equally well to affiliation.

Exhibit 3 illustrates a role/hierarchy graph. The exhibit shows three interlinked role hierarchies, based on three enterprise-level roles: Management Administration, Order Clerk, and Financial Controller. Each of the top-level roles contains other roles shown by the arrows. Of these lower-level roles, some may be visible at the enterprise level (e.g., the Expenses Authorization role) and be granted directly as one of the highest-level roles a particular user may have, but others are more resource-oriented roles (e.g., Office System Functions), which would be defined by a resource controller.

Exhibit 3.  Role Hierarchies

ENGINEERING THE ROLE CONCEPT

In engineering roles within actual product, it is convenient to make a distinction between different uses of roles — on the one hand as seen and used by the user and on the other hand as seen and used at the protected resource.

Role Names and Role Attributes

Users see roles as names to be used when signing on to the system. A user might say, “I am signing on in the role of Duty Officer.” Roles used in this way are called role names. At the resource end, access control logic looks at a role field in a security record and compares it directly with a value associated with the resource, typically in an access control list. Roles used in this way are called role attributes. Using this terminology, when a user specifies a role name like Order Clerk, it describes how multiple role attributes may be given to that user (e.g., in a PAC). Using the graph in Exhibit 3, the role attributes are resource related: Office System Functions and Orders.

Some roles appear in both forms. All roles that are not part of a hierarchy are likely to be named by users and to appear as attributes in their access control data. However, one example of such a role in a hierarchy is Expenses Authorization, shown in Exhibit 3. A Financial Controller might sign on specifically to authorize expenses and, therefore, would say “with a role of Expenses Authorization.” This role, however, is sufficiently precise in its focus to be used directly by resource access control logic and could, therefore, be mapped directly into a role attribute.

At ICL, the name and attribute distinction has been a great benefit in clarifying thinking in this area. ICL’s AccessManager product maintains the distinction explicitly. The user signs on specifying (or defaulting to) a role name. This affects the attributes the user will be granted and also directly affects the desktop that appears, coordinated with what the user is allowed to access in that role. If the target resource is capable of receiving PACs, the underlying SESAME technology will convert this role name to one or more role attributes in the PAC, and such attributes can then be made available at the server for use in access control decisions. This concept of converting role names into one or more role attributes enables an organization to specify much more clearly what actually happens in the engineering of role hierarchies.