[TM Technical Report]
Notes on Access Control Feature
[Authors: Damith, Junchao]
{info about typical access control mechanisms and terminology.}
Roles
x = can do red: course level
category | Manager | Observer | Tutor | |
Courses | Edit/Delete course | |||
Instructors | Add/Edit/Delete instructors | x | ||
Sessions | Create/edit/delete sessions | x | ||
View responses and comments | x | x | x | |
Submit responses and comments | x | x | ||
Edit/delete responses/comments by others | x | |||
Students (of a given section) | View student details | x | x | x |
Enroll/edit/delete students | x | |||
View others’ comments on students | x | x | ||
Give comments for students | x | x | ||
Edit/delete others’ comments | x |
Policies
Additional:
isDisplayedToStudents: controlling whether the students will see this instructor. right now this will be functioning in studentCourseDetailsPage--if the instructor is set to be not displayed to students, s/he will not be shown on that page; studentFeedbackSubmitPage--if the instructor is set to be not displayed to students, students cannot feedback to him/her.
For actions are not supposed to be accessed by the user based on access control settings, most of them will be disabled. Only a few links is hidden--this is mainly because IE does not recognize disabled attribute sometimes. And if the user inspect the element and remove disabled property manually and then click on the action, the action will be triggered with unauthorised exception thrown.
Some rules about privileges for instructor and instructors in the course:
1. At any point of time, there will be at least one instructor in the course who will be able to add/edit/delete instructor for the course--and this is considered as the highest privilege of an instructor.
2. If one instructor is able to edit/delete others’ comments, the privilege for viewing others’ comments will be turned on for him/her automatically. Same for feedbackResponseComment. And also because of the way commenting on student/team/section is implemented, if the give comments on student is enabled, viewing student will also be enabled.
1. InstructorPrivileges: store the privileges of the instructor in the form of HashMaps.
*important API: isAllowedForPrivilege(String privilegeName);
isAllowedForPrivilege(String sectionName, String privilegeName);
isAllowedForPrivilege(String sectionName, String sessionName, String privilegeName); * (for eval, eval-prefix + % + evalName is used to be different from feedbackSessions)
2. InstructorPrivileges is stored in instructor in the form of Text, which is a json representation of InstructorPrivilege
3. Access control code is added to GateKeeper for necessary actions such as InstructorCourseStudentDetailsPageAction, InstructorFeedbackResponseCommentAddAction, InstructorEvalResultEditAction and so on. Besider normal checking of the privilege, the instructor’s privilege will also be checked and only if the result of isAllowedForPrivilege is true can the instructor be allowed to carry out the action. And also some buttons and links are disabled from instructors if the current instructor is not allowed for the action.
4. Actions that are not there yet: Edit Course; Edit/Delete responses by others
Note on the implementation:
The current design is stored InstructorPrivileges as json in the database and also that privilegeNames are defined in constant string in Const.java already. Adding things to instructorPrivileges may be fine in the future, removing privilegeNames may also be OK. but modifying directly will cause the problem of not being able to retrieve the right privileges for instructor. Also that this feature is scattered all over the system(especially actions and JSPs), any change may affect a lot of actions and cause the system to malfunction. Whoever wants to improve this feature must have a good understanding of the system and implementation of AccessControl mechanism.
(the user stories here are more like for future implementation or nice-to-have)
When adding an instructor:
When creating a forum:
Drupal user access control is primarily based on configurable roles.
Configuring roles:
Assigning roles:
A class is divided into sections. A section can be delegated to another faculty (can select from all faculty members in the system, including those from other universities!). Other than that, there doesn’t seem to be other access control mechanism.
http://ipeer.ctlt.ubc.ca/wiki/access_control
A role can be considered as a group of permission a user can have. There are some typical roles in iPeer:
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.