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 |
functions/user/admin | USER_ADMIN | Operations on admin |
functions/user/instructor | USER_INSTRUCTOR | Operations on instructor |
Controller Permissions
Key | Description |
controller/user | All user actions |
controller/user/add | Add user |
controller/user/delete | Delete user |
controller/user/edit | Edit user |
controller/course | All course actions |
controller/course/add | Add course |
controller/course/delete | Delete course |
controller/course/edit | Edit course |
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.