Administration Of Rule Based Computer Systems Computer Science Essay

Published:

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.

Writing Services

Essay Writing
Service

Find out how the very best essay writing service can help you accomplish more and achieve higher marks today.

Assignment Writing Service

From complicated assignments to tricky tasks, our experts can tackle virtually any question thrown at them.

Dissertation Writing Service

A dissertation (also known as a thesis or research project) is probably the most important piece of work for any student! From full dissertations to individual chapters, we’re on hand to support you.

Coursework Writing Service

Our expert qualified writers can help you get your coursework right first time, every time.

Dissertation Proposal Service

The first step to completing a dissertation is to create a proposal that talks about what you wish to do. Our experts can design suitable methodologies - perfect to help you get started with a dissertation.

Report Writing
Service

Reports for any audience. Perfectly structured, professionally written, and tailored to suit your exact requirements.

Essay Skeleton Answer Service

If you’re just looking for some help to get started on an essay, our outline service provides you with a perfect essay plan.

Marking & Proofreading Service

Not sure if your work is hitting the mark? Struggling to get feedback from your lecturer? Our premium marking service was created just for you - get the feedback you deserve now.

Exam Revision
Service

Exams can be one of the most stressful experiences you’ll ever have! Revision is key, and we’re here to help. With custom created revision notes and exam answers, you’ll never feel underprepared again.