Access Control

Requirements

User

• A user have at least one role in the system.
• A user may have more than one role. (e.g. a person can be a TA and student)

Role

A role can be considered as a group of permission a user can have. There are some typical roles in iPeer:

Super Admin

• Have access to all the functions without restriction

Faculty/School Admin

• Have the view of whole faculty and school
• Can manage the instructors, students, courses, evaluations within the faculty/school

Instructor

• Have the view of his/her own courses, students, evaluations

Tutor

• Have the view of the courses he/she enrolled in

Student

• Have the view of the courses he/she enrolled in

Permission

The permission can give a user access to the resources. Although CakePHP default ACL can easily control the access to a specific controller/action. It is not enough for iPeer. Consider the following case: the admin and instructor roles both should have access to /user/add controller/action. Because admin should be able to add student and instructor and instructors should be able to add students to their course as well. However, instructor shouldn't have the ability to add admin. Therefore we consider two types of permissions iPeer.

Controller/Action Permission

This type of permission controls if a role has access to a specific controller/action pair, E.g., Admin has access to /user/add or Student is denied from /user/delete.

Functional Permission

This type of permission controls if a role has access to a specific iPeer function. E.g. Admin can add instructors or instructor is not allow to add admin. Here is an example of the permission: function/user/admin/add

List of Permission

Function permissions

Key	Name	Description
functions/user	USER	Operations on all users
functions/user/superadmin	USER_SUPERADMIN	Operations on superadmin, e.g. add/delete
functions/user/admin	USER_ADMIN	Operations on admin
functions/user/instructor	USER_INSTRUCTOR	Operations on instructor

Organization/Faculty

There is another level of access control in iPeer. Consider an admin at the faculty level should have access to all resources to his/her faculty, but not for other faculties.

Some facts for organization/faculty:

• There is a default faculty for the implementations that doesn't need this kind of level control.
• A user can belongs to multiple faculties.
• A course can belongs to multiple faculties. E.g., cross-listed course.
• Faculty information lives in a separate table called faculty.
• For the simplicity, faculty is a flat table. There is no hierarchy for faculty.