Authorization

Authorization

Modus operandi

Ilios grants or denies access to its server-side API by checking the given access levels of the user requesting/interacting with a resource. This implies that authentication-checks ("is the user logged in? what is the user's identity?" ) must always precede authorization checks, since the authorization relies an established user identity to be present at execution-time.

Access Levels

Ilios defines three access levels, listed in the first column of the matrix below. Access levels correlate directly to user roles, listed in the second column. In order to obtain a given access level, the user must be associated with at least one of the related user roles.

access level	requires user-role assignment	grants access to functionality	session attribute to check
Learner	"student"	student calendar/dashboard	is_learner
Instructor	"faculty", "developer" and/or "course director"	instructor calendar/dashboard	has_instructor_access
		instructor-group management
		learner-group management
		program management
		course/session management
		offering management
Administrator	"developer" and/or "course director"	same as Instructor access-level, plus user-management	has_admin_access

Implementation details

Access levels are set only once for a given user - during the user-login process.

Ilios will load the current user's user-role associations from the user_x_user_role table, and then give the appropriate access levels based on the rules outlined above.

The identified access levels are then cached as flags is_student, has_instructor_access and has_admin_access in the user-session.

$sessionData = array(
    'is_learner' => $this->user->userIsLearner($user->user_id),
    'has_instructor_access' => $this->user->userHasInstructorAccess($user->user_id),
    'has_admin_access' => $this->user->userHasAdminAccess($user->user_id),
    ...
);

$this->session->set_userdata($sessionData);

Consecutive access checks are build exclusively around checking these session attributes - there are no further trips to the database to retrieve this info again.

public function saveCourse ()
{
        $rhett = array();
        $lang =  $this->getLangToUse();

        // authentication check
        if ($this->divertedForAuthentication) {
            $this->_printAuthenticationFailedXhrResponse($lang);
            return;
        }

        // authorization check
        if (! $this->session->userdata('has_instructor_access')) {
            $this->_printAuthorizationFailedXhrResponse($lang);
            return;
        }
// ...
}

All access level checks are explicitly wired into each API endpoint ("Controller Action").

If the user authorization fails, the response from the server will indicate that access was denied.

• XHR handlers will respond with a JSON formatted array containing an error message (keyed off by error) as its sole item
• Full-page requests will be answered by returning the "Access denied" page.

Current Limitations

Access levels are granted application-wide. There are no checks/boundaries in place that pertain to a user's school affiliations. As a consequence, it is currently possible for users with elevated privileges, such as faculty, to access and modify courses, programs etc. that belong to schools that they are themselves not affiliated with.

A more fine-grained access control mechanism must be implemented to enforce a more restrictive permissions model.