Administration Of Rule Based Computer Systems Computer Science Essay

Published: Last Edited:

This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.

Abstract

Administrators in an organization are responsible for making policy decisions based on specified rules. As organizations are becoming ever more complex, with variety of job functions and roles, the need to have an administrative system that manages roles and their associated job functions and permissions become even more significant. This project investigates how rules can be used to define administrative policy for efficient administration of roles. I would use the ARBAC97 model for user-role assignment and permission-role assignment to demonstrate this. In addition, concept of temporal authorization will be introduced as an extension to the model. Rule-based or declarative language would be used to express policies. Datalog has been the language of choice for expressing rule-based policies and hence would be used throughout the project. GUI implementation of an administrative system would be developed using prolog.

Rule-Based Systems

A rule based-system is a system where all behaviors are determined by set of explicitly specified rules. In rule-based systems, rules are used to specify system policies and constraints. These policies and constraints guide the daily operations of a system and are declared using rule-based languages such as datalog. Rule-based language is a declarative language, which combine logic with rules. An obvious advantage is that it is completely declarative which makes it is easier for security administrator to define policies.

Rule based languages can be used to define security policies in systems like RBAC and to define administrative operations inherent in these systems.

In RBAC, users are assigned to roles, permissions are assigned to roles and users acquire permissions of roles by being members of the role. Within an enterprise organization, roles are created for a variety of job functions. The permissions to execute certain operations are explicitly assigned to particular roles. Staff members and/or other system users are assigned specific roles thereby acquiring the permissions of the role to perform particular system functions. Because users are not directly assigned permissions, but only acquire them through their roles, administering individual user rights simply becomes the issue of assigning appropriate roles to user; this makes common operations, such as adding a user, or changing a user's department much more easier.

Three key rules are defined for RBAC:

1. Role assignment: A subject can execute an action only if the subject has been assigned a role.

2. Role authorization: A subject's active role must be authorized for the subject. With rule 1 above, this rule guarantee that users can assume only roles for which they are allowed.

3. Transaction authorization: A subject can execute a transaction only if the transaction is authorized for the subject's active role. With rules 1 & 2, this rule guarantees that users can perform only actions for which they are authorized.

RBAC can be extended to include constraints such as separation of duty (no user assignment to exclude role pairs) and role hierarchy can be applied as well; roles can be combined in a hierarchy in which roles high up the hierarchy subsume permissions possessed by sub-roles.

Facts in RBAC can be expressed in datalog as follows

F1: ura(bob, manager)

F2: pra(sue, f1, cashier)

F3: me(cashier, auditor)

F4: ds(manager, cashier)

F1 is a user-role assignment and can be interpreted as "the user Bob is assigned the role of a manager". F2 is a permission-role assignment and can be interpreted as "Sue acting in the role of a cashier is authorized to access file f1. F3 expressed the mutual exclusivity constraint. It means the role of a cashier and an auditor are mutually exclusive. F4 expressed role hierarchy relation. It means role of manager is directly senior to the role of a cashier.

In the same way datalog can be used to represent facts, it can also be used to model organizational policies. These policies may be limiting access to system resources or prohibiting access to certain users or group of users. Consider the following policy below:

"An organization includes two roles: r1 andr2. Bob is assigned to the r1 role, and

Sue to r2. Members of r1 can read all files classed as "public". Members of r2

can read all files classed as "secret" and can write the file f2."

The above policy can be represented in datalog as follows:

ura(angus, r1)

ura(Sue, r2)

pra(read, O, r1) ← Classed_as (O, public)

pra(read, O, r2) ← Classed_as (O, secret)

Administration in Rule-based systems

The administration of systems that implement traditional RBAC has been exhaustively

discussed in literatures. However, administering systems that uses set of rules or policies defined by an administrator requires taking into consideration that administrators do not assign users to roles directly. Instead, the whole process is preset based on authorization rules which permit users to roles based on the attributes they are associated with. The question now is how to determine who has the power of administering these attributes. Also on what basis this power should be distributed if a decentralized approach is required.

A change in the user's attributes may cause some changes to the set of rules that are relevant to the user by causing the user to satisfy new rules. In the same vein, these changes could cause the user to fail to satisfy some rules that were hitherto relevant, leading to the user being revoked from roles to which he used to have authority over.

Administering users' attributes involve determining what roles they are authorized to trigger.

Changes made to a user's attributes have an effect on the set of rules relevant to that user. These new set of relevant rules may:

• Authorize the user to activate new roles,

• Revoke the user from roles previously authorized to activate,

• Grant/revoke from him negative authorization,

• Authorize/revoke him to/from mutually exclusive roles.

• Subject him to new constraints.

ARBAC97 is particular relevance to this project and would be extensively references throughout the this work. ARBAC97 is the de facto model for rule based administration. ARBAC97 describes decentralized administration and has three major components

1. URA97 which is deals with user-role assignment

2. PRA97 which is deals with permission-role assignment

3. RRA97 which is concerned with role-role assignment

The two essential concepts of ARBAC97 are the administrative ranges and the prerequisite

conditions. Together these two regulate and impose restrictions on the administration of roles.

The administrative ranges, or role ranges, reflect the boundary of the administrator authority,

Where as the prerequisite condition limits the set of users the administrator can

assign roles to.

In ARBAC, rules are used to define administrative duties. These rules can be naturally expressed in declarative languages.

The URA97,which deals with the question of which administrative role can assign/revoke role can be expressed using:

Can_assign_u (AR, prereq_ura, 2roles)

Can_revoke_u(AR, 2roles)

Consider the following administrative policy:

"Members of sso can assign to senior manager roles those that are members of manager role and does not belong to project1 role"

This can be represented in datalog as follows:

can_assign_u(sso, mgr ¬ ˄ project1, snr_mgr)

For PRA97 is a dual of URA97, permission assignment and revocation is treated as ura hwre prereq_pra constrain permission. In datalog PRA97 rules can be shown as follows:

Can_assign_p (AR, prereq_pra, 2roles)

Can_revoke_p (AR, 2roles)

The RRA97 defines administration for role hierarchies and has five update functions as follows:

can_assign_a(AR, prereq_a, 2A)

can_assign_a(AR, prereq_g, 2G)

can_revoke_a(AR, prereq_a, 2A)

can_revoke_g(AR, prereq_a, 2G)

can_modify(AR, 2up_roles)

What I am going to do

Because of its significance, RBAC has been extensively researched. However, even though RBAC has attained a good developmental level, some significant requirements are still missing One such requirement is its lack of temporal dimension. In many organizations, roles may have limited or temporal period. Consider, for example, the case of a temporary staff in an establishment, and suppose that the temporary staff is authorized to work within the given organization only for three months. If the temporary staff is represented by a role, say manager, then the above requirement would mean that this role should be activated only during the aforementioned temporal period. The format for the requirement above can be represented in datalog as follows

ura(u, r, T)

Hence, if a user bob is assigned to a role of manager between 01/01/2010 and 01/01/2012, this can be represented as follows:

ura(bob, manager, 01/01/2010, 01/01/2012)

Just as RBAC can be extended to include temporal authorization, RBAC administration could also support temporal dimention. This is the main focus of this project. Administration of RBAC using rules to specify policy decisions is the main focus of this project.

In some applications administrators may want to assign role to users for a specified period of time after which the new role would be automatically revoked and the user would revert back to his/her original role. Similarly for permission. I am looking at way in which this could be incorporated in ARBAC97 for user-role assignment and permission role assignment. The above requirement could be represented in datalog below:

Can_assign_u (AR, prereq_ura, 2roles, T)

At first glance, the inclusion of temporal dimension seems to render unnecessary, the can_revoke-u() function for URA97. I have decided to retain the function bearing in mind that an administrator can at any time manually revoke role from user even before the expiration of the time the user is assigned to a role.