In the prototype demonstration of RGP-Admin for Windows NT:

• Objects are NT File System (NTFS) files or directories.

• Roles are Windows NT groups.

• Object Access Types are NTFS ACL specifications.

• Permissions are the NTFS file permissions: Read(R), Write(W), Execute(X), Delete(D), Change Permissions(P), Take Ownership(O).

Figure 1: Roles in a bank.

The Prototype Demo illustrates a small portion of a banking environment where the roles and their hierarchy are shown in figure 1. The roles branch_manager and teller are two that one might expect at a bank's branch office. The role account_rep is authorized for the bank's account representatives who sit at the desks outside of the teller windows. The role financial_advisor is authorized for an account representative who is trained in recommending non-insured investment products. The role financial_advisor inherits account_rep because financial_advisor needs to be able to open and close accounts. The roles account_rep, branch_manager, financial_advisor, and teller inherit the role employee since any user authorized for these roles is a bank employee.

Table 1 shows the role permissions defined for each of the Object Access Types. There are four Object Access Types:

• The Object Access Type account applies to files that contain individual account information and to directories that hold such files.

• The Object Access Type cd_to_dir provides all roles with the capability of traversing a directory in order to access files in the directory.

• The Object Access Type employee applies to files readable by all employees and to directories which contain employee related files. Employees need to be able to write in such directories in order to create suggestions files.

• The Object Access Type suggestions applies to files created by employees containing suggestions for more efficient bank operations.

The RGP-Admin Prototype Demo uses a pair of parenthesized permission lists for describing file and directory permissions. This notation is also used in Windows NT Explorer. For example, table 1 shows that role branch_manager has permissions "(RX) (R)" for the accounts Object Access Type. When a file is the accounts Object Access Type, then branch_manager has Read permission for that file. When a directory is an accounts Object Access Type, then branch_manager has Read and Execute permission for the directory. When a directory or file is created within a directory of Object Access Type accounts, then the file or directory created has Object Access Type accounts.

In support of bank policy, the role permissions for each of the Object Access Types are:

• The role account_rep must be able to create and delete account files. Thus, account_rep has permission to traverse and write into the accounts directory, and read and delete account files. Note that account_rep does not have permission to read the accounts directory because bank policy is that account_rep does not need to be able to create a list of all account holders. Also, the account_rep does not need to write into an account file. When an account is created or deleted, the initial deposit or final withdrawal from the account must be performed by a teller.

• The role branch_manger has permission to read the account directory and account files, and to read and delete suggestion files.

Table 1: Role permissions for each Object Access Type

• The role employee has permission to read all employee information but does not have any permissions to access information about accounts.

• The role financial_advisor is able to read the accounts directory, thus, obtaining a list of all account holders. This permission is necessary in order for financial_advisor to be able to derive marketing information about current account holders in order to identify account holders who might be interested in the bank's uninsured investments. Since financial_advisor inherits account_rep, financial_advisor is has the permissions necessary to function as an account_rep. A financial_advisor needs permission to open and close both insured and uninsured accounts.

• The role teller must have the permission to make changes (deposits and withdrawals) from the account files. Thus, teller has permission to traverse the account directory and read/write account files. Note that teller has no permission for creating or deleting accounts. That is the responsibility of the account_rep.

In order for all roles to be able to traverse the directory tree to access files for which they have permissions, all roles have Execute permission on directories with cd_to_dir Object Access Type.

Figure 2 shows a sample Object Access Type Window of the RGP-Admin Prototype Demo. This view color-codes file icons green if the file has the selected Object Access Type or red if not as shown. In figure 2, the Object Access Type accounts is selected and the icons for the directory accounts and the files *.acc are displayed in green indicating that those files have Object Access Type accounts. The icons for the files a:\, bank_files, and empl_info are displayed in red indicating that those files have some other Object Access Type. On a black and white display, "red" is the darker shading.

Files shown in red can be set to the accounts Object Access Type. If the file to be set is a directory, then files and/or directories in the directory or in the directory tree can be set to accounts. In addition, using this display, a file’s Object Access Type can be copied and added to a collection.

Figure 3 shows a sample of the Object Access Type Editor Window. Using this display, an Object Access Type can be created and/or edited from a collection. In figure 3, the accounts Object Access Type has been selected from the collection for editing. Figure 3 shows that employee is the only role available to be added to the accounts Object Access Type. The Permissions checkboxes are used to set the permissions for a selected role in accounts.

Figure 4 shows a sample of the Role/Group Permission View Window. Because the Prototype Demo illustrates a Windows NT implementation, the title "Role/Group Permission View" serves as a reminder that roles are Windows NT groups. This view color-codes file icons green if the selected role has the selected permission for the file and red if not. If no permissions are selected, then file icons are color-coded blue if the selected role has any access. If Hierarchy Mode is selected, then the color-coding is based on the selected role and any additional permissions that the selected role inherits from the roles which it inherits.

In figure 4, the role financial_advisor, Hierarchy Mode, and Read permission are selected. All files except a:\ and bank_files are shown in green indicating that financial_advisor has read permission on those files. On a black and white display, "green" is the lighter shading. Note that financial_advisor has Read permission for the accounts directory as a result of the fact that the directory has Object Access Type accounts (see tab. 1 and fig. 2). The role financial_advisor has Read permission on all of the other files displayed in green as a result of inheritance. If Path Mode were also selected, then the directories a:\ and bank_files would also be shown in green indicating that financial_advisor has either Read or Execute permission. If so, financial_advisor is able to traverse those directories. If no permissions are selected, then file icons are colored blue if the selected role has any access.

Windows NT does not support multilevel group hierarchies. Windows NT Local Groups can contain Domain Groups as members, but Domain Groups cannot contain Local Groups or other Domain Groups. The RGP-Admin Prototype Demo includes multilevel group hierarchy in order to demonstrate how RGP-Admin could be implemented with such a feature. Most RBAC mechanisms support role hierarchies. The use of hierarchies in administering the user/role relationships can significantly reduce administrative costs.

One approach to implementing multilevel role hierarchies in Windows NT is to represent role hierarchies by manipulating user membership in NT groups according to a hierarchy representation external from the NT User Manager Database. This is the approach taken in the adaptation of the RBAC/Web Admin Tool for Windows NT. If role A inherits role B, then all users in the NT group representing role A are members of the NT group representing role B.

Windows NT supports users as entries in ACLs and negative permissions associated with ACL entries. These features present a problem with regards to what it means for a role, i.e., an NT group, "to have a permission for a file." The preferred meaning would be: "any user who is authorized for a role (i.e., a member of an NT group which is an entry with positive permissions in a file’s ACL) has the access indicated by the permissions associated with the entry."

With ACLs that can have entries with negative permissions overriding entries with positive permissions, this preferred meaning is not possible in general. For example, an ACL may have an entry for a role with positive permissions and also an entry negating those permissions for a user authorized for that role. The result is that although the user is authorized for the role and the role associated with permission, that particular user does not have permission while all other users authorized for that role have permission. Thus in general, the meaning of the statement "role having a permission for a file" becomes: "the role has an entry with positive permissions in the file’s ACL."

The nature of Windows NT ACLs also implies an alternative meaning for Hierarchy Mode. Hierarchy Mode becomes "Effective User Access" mode which only applies to users. When this mode is selected, the effective access of a selected user (i.e., whether this user has access to the file as determined by Windows NT criteria) color-codes the file icons according to the selected permissions. When this mode is not selected, then the color-coding of the file icons indicates that the selected user or role has an entry in the ACL with the selected positive permissions.

The use of roles in administering access policy is usually less error-prone and less costly than directly associating users with permissions. Much of the effort in developing administrative tools to support the use of roles has been devoted to tools which associate users with roles. RGP-Admin is a tool that manages the association of roles and permissions by means of Object Access Types.

An Object Access Type is an access control information specification which can be manipulated as an entity separate from the object with which it is associated. Just as roles and objects can have hierarchies, hierarchical relationships could also be defined for Object Access Types based on permission inheritance. This might be useful for reusing access specifications across applications, projects, and/or organizational units. The concept of an Object Access Type hierarchy is a subject for further work.

RGP-Admin allows Object Access Types to be created, edited, and associated with objects. In addition, RGP-Admin displays graphically the association of Object Access Types and objects, and the association of roles, permissions, and objects.

Figure 2: Object Access Type View Window

Figure 2 shows that the Object Access Type accounts is selected and that the icons for the directory accounts and the files *.acc are displayed in green indicating that those files have Object Access Type accounts. The icons for the files a:\, bank_files, and empl_info are displayed in red indicating that those files have some other Object Access Type. On a black and white display, "red" is the darker shading.

Figure 3: Object Access Type Edit Window

Figure 4: Role/Group Permission View Window.

Figure 4 shows that the role financial_advisor, Hierarchy Mode, and Read permission are selected and that all files except a:\ and bank_files are shown in green indicating that financial_advisor has read permission on those files. On a black and white display, "green" is the lighter shading.