Security

Kofa has a very efficient security machinery. The machinery does not perform authorization checks on the content objects themselves stored in the database, but, restricts the usage of views, i.e. web pages and forms which are needed to view or edit data. Views are protected by permissions the user must have to use the view. Instead of assigning permissions seperately to users, permissions are bundled into sets of permissions, so-called roles which can be assigned to users through the web interface.

It is important to note that permissions do not include other permissions. Only roles ‘include’ permissions. A ‘manage’ permission, for example, does not automatically enable users to open pages which merely display the data. These pages have their own ‘view’ permission. Another example is the ManagePortal permission described below. The name of the permission may lead to believe that users can do everything with this permissions. This is not true. It does only give access to certain pages which are dedicated to portal managers and must not be accessed by any other user.

Permissions

The whole set of permission and role classes are described in the Permissions and Roles Module. Here we describe only a subset of permission classes which are essential for the security settings configuration.

General Permissions

class waeup.kofa.permissions.Public[source]

The Public or everyone-can-do-this-permission is being applied to views/pages that are used by everyone.

class waeup.kofa.permissions.Anonymous[source]

The Anonymous permission is applied to views/pages which are dedicated to anonymous users only. Logged-in users can’t access these views.

class waeup.kofa.permissions.Authenticated[source]

The Authenticated permission is applied to pages which can only be used by logged-in users and not by anonymous users.

class waeup.kofa.permissions.ManageUsers[source]

The ManageUsers permission is a real superuser permission and therefore very ‘dangerous’. It allows to add, remove or edit user accounts. Editing a user account includes the option to assign or remove roles. That means that a user with this permission can lock out other users by either removing their account or by removing permissions.

class waeup.kofa.permissions.EditUser[source]

The EditUser permission is required for editing single user accounts.

class waeup.kofa.permissions.ManagePortal[source]

The ManagePortal permission is used for very few pages (e.g. the DatacenterSettings page). Only PortalManagers have this permission. It is furthermore used to control delete methods of container pages in the Academic Section. The ManageAcademics permission, described above, does enable users to edit content but not to remove sub-containers, like faculties, departments or certificates. Users must have the ManagePortal permission too to remove entire containers.

class waeup.kofa.permissions.ViewAcademics[source]

The ViewAcademics permission is applied to all views of the Academic Section. Users with this permission can view but not edit content in the Academic Section.

class waeup.kofa.permissions.ManageAcademics[source]

The ManageAcademics permission is applied to all edit/manage pages in the Academic Section. Users who have this permission can change/edit context objects.

class waeup.kofa.permissions.ManagePortalConfiguration[source]

The ManagePortalConfiguration permission allows to edit global and sessional portal configuration data.

class waeup.kofa.permissions.ManageDataCenter[source]

The ManageDataCenter permission allows to access all pages in the Data Center and to upload files. It does not automatically allow to process uploaded data files.

class waeup.kofa.permissions.ExportData[source]

The ExportData permission allows to export any kind of portal data.

class waeup.kofa.permissions.ImportData[source]

The ImportData permission allows to batch process (import) any kind of portal data except for user data. The User Data processor requires also the ManageUsers permission.

class waeup.kofa.permissions.TriggerTransition[source]

The TriggerTransition permission allows to trigger workflow transitions of student and document objects.

class waeup.kofa.permissions.ShowStudents[source]

Users with this permission do not neccessarily see the ‘Students’ tab but they can search for students at department, certificate or course level. If they additionally have the ExportData permission they can export the data as csv files.

Bursary or Department Officers don’t have the ExportData permission (see Roles section) and are only allowed to export bursary or payments overview data respectively.

class waeup.kofa.reports.HandleReports[source]

The HandleReports permission allows to add any kind of report and to view and remove own reports, i.e. reports which were created by the logged-in user.

class waeup.kofa.reports.ManageReports[source]

The ManageReports permission allows to view, add and remove also the reports of other users. It requires the permission to handle reports.

Applicants Section Permissions

class waeup.kofa.applicants.permissions.ViewApplication[source]

The ViewApplication permission allows to view application records.

class waeup.kofa.applicants.permissions.HandleApplication[source]

The HandleApplication permission is reserved for applicants. Applicants ‘handle’ their data. Officers ‘manage’ the data.

class waeup.kofa.applicants.permissions.ManageApplication[source]

The ManageApplication permission allows to edit the data. This permission is reserved for officers and portal managers.

class waeup.kofa.applicants.permissions.PayApplicant[source]

The PayApplicant permission allows to add an online payment ticket.

class waeup.kofa.applicants.permissions.ViewApplicationStatistics[source]

The ViewApplicationStatistics permission allows to perform statistical evaluations. Only portal managers have this permission.

Students Section Permissions

class waeup.kofa.students.permissions.ViewStudent[source]

The ViewStudent permission allows to view all student data.

class waeup.kofa.students.permissions.HandleStudent[source]

The HandleStudent permission is reserved for students. Students ‘handle’ their data. Officers ‘manage’ the data.

class waeup.kofa.students.permissions.ViewStudentsContainer[source]

The ViewStudentsContainer permission allows to view the students root container page.

class waeup.kofa.students.permissions.ManageStudent[source]

The ManageStudent permission allows to edit the data. This permission is meant for students officers.

class waeup.kofa.students.permissions.PayStudent[source]

The PayStudent permission allows to add an online payment ticket and to manage tickets.

class waeup.kofa.students.permissions.HandleAccommodation[source]

The HandleAccommodation allows to manage bed tickets.

class waeup.kofa.students.permissions.UploadStudentFile[source]

The UploadStudentFile permissions allows to upload the passport picture. The respective page additionally checks the state of the student.

class waeup.kofa.students.permissions.ClearStudent[source]

The ClearStudent permission is needed to clear students or to reject clearance. This permission is meant for clearance officers.

class waeup.kofa.students.permissions.LoginAsStudent[source]

The LoginAsStudent is needed to set temporary student passwords and login as (impersonate) students.

class waeup.kofa.students.permissions.EditStudyLevel[source]

The EditStudyLevel permission is needed for editing course lists. Students and course advisers do have this permission.

class waeup.kofa.students.permissions.ClearStudent[source]

The ClearStudent permission is needed to clear students or to reject clearance. This permission is meant for clearance officers.

class waeup.kofa.students.permissions.ValidateStudent[source]

The ValidateStudent permission is needed to validate or reject course lists. This permission is not needed if users already have the TriggerTransition permission.

Global Roles

Global or site roles are assigned portal-wide. In contrast to local roles, users have this role in every context.

Many global roles do only bundle one or two permissions. The objective behind is to share responsibilities and distribute tasks.

Global roles are being assigned via the user manage form page.

Global General Roles

class waeup.kofa.permissions.AcademicsOfficer[source]

An Academics Officer can view but not edit data in the academic section.

This is the default role which is automatically assigned to all officers of the portal. A user with this role can access all display pages at faculty, department, course, certificate and certificate course level.

class waeup.kofa.permissions.AcademicsManager[source]

An Academics Manager can view and edit all data in the scademic section, i.e. access all manage pages at faculty, department, course, certificate and certificate course level.

class waeup.kofa.permissions.DataCenterManager[source]

This single-permission role is dedicated to those users who are charged with batch processing of portal data. A Data Center Manager can access all pages in the Data Center, see ManageDataCenter permission above.

class waeup.kofa.permissions.ImportManager[source]

An Import Manager is a Data Center Manager who is also allowed to batch process (import) data. All batch processors (importers) are available except for the User Processor. This processor requires the Users Manager role too. The ImportManager role includes the DataCenterManager role but not vice versa.

class waeup.kofa.permissions.ExportManager[source]

An Export Manager is a Data Center Manager who is also allowed to export all kind of portal data. The ExportManager role includes the DataCenterManager role but not vice versa.

class waeup.kofa.permissions.ACManager[source]

This is the role for Access Code Managers. An AC Manager can view and manage the Accesscodes Section, see ManageACBatches permission above.

class waeup.kofa.permissions.UsersManager[source]

A Users Manager can add, remove or edit user accounts, see ManageUsers permission for further information. Be very careful with this role.

class waeup.kofa.permissions.WorkflowManager[source]

The Workflow Manager can trigger workflow transitions of student and document objects, see TriggerTransition permission for further information.

class waeup.kofa.reports.ReportsOfficer[source]

The Reports Officer has the permission to view, add and remove own reports.

class waeup.kofa.reports.ReportsManager[source]

The Reports Manager has the permission to view, add and remove all reports.

In contrast to these specialized sets of permissions, there are two sets which delegate extensive powers on portal managers.

class waeup.kofa.permissions.PortalManager[source]

The PortalManager role is the maximum set of Kofa permissions which are needed to manage the entire portal. This set must not be customized. It is recommended to assign this role only to a few certified Kofa administrators. A less dangerous manager role is the CCOfficer role described below. For the most tasks the CCOfficer role is sufficient.

class waeup.kofa.permissions.CCOfficer[source]

The role of the Computer Center Officer is basically a copy of the the PortalManager role. Some ‘dangerous’ permissions are excluded by commenting them out (see source code). If officers need to gain more access rights than defined in this role, do not hastily switch to the PortalManager role but add further manager roles instead. Additional roles could be: UsersManager, ACManager, ImportManager, WorkflowManager or StudentImpersonator.

CCOfficer is a base class which means that this role is subject to customization. It is not used in the waeup.kofa base package.

Global Applicants Section Roles

Global Applicants Section Roles are assigned portal-wide (globally) but do actually only allocate permissions in the applicants section.

class waeup.kofa.applicants.permissions.ApplicantRole[source]

This role is dedicated to applicants only. It defines the permissions an applicant gains portal-wide.

class waeup.kofa.applicants.permissions.ApplicationsOfficer[source]

The Applications Officer is allowed to view all application records.

class waeup.kofa.applicants.permissions.ApplicationsManager[source]

The Applications Manager is allowed to edit all application records. The role also allows to add payment tickets.

Global Students Section Roles

Global Students Section Roles are assigned portal-wide (globally) but do actually only allocate permissions in the students section.

class waeup.kofa.students.permissions.StudentRole[source]

This role is dedicated to students only. It defines the permissions a student gains portal-wide.

class waeup.kofa.students.permissions.StudentsOfficer[source]

The Students Officer is allowed to view all student data.

class waeup.kofa.students.permissions.StudentsManager[source]

The Students Manager is allowed to edit all student data, to create payment tickets, to handle bed tickets and to upload passport pictures.

class waeup.kofa.students.permissions.StudentsClearanceOfficer[source]

The global StudentsClearanceOfficer role enables users to view all student data, to clear students and to reject clearance portal-wide. Usually, this role is not assigned manually. We are using the correspondent local role instead which assigns the StudentsClearanceOfficer role dynamically.

class waeup.kofa.students.permissions.StudentsCourseAdviser[source]

The global StudentsCourseAdviser role enables users to view all student data, to edit, validate or reject course lists portal-wide. Usually, this role is not assigned manually. We are using the correspondent local role instead which assigns the StudentsCourseAdviser role dynamically.

class waeup.kofa.students.permissions.StudentImpersonator[source]

The Student Impersonator gains the LoginAsStudent permission, nothing else, see description above.

Local Roles and Dynamic Role Assignment

In contrast to global roles, which are assigned portal-wide, local role permissions are gained for a specific context.

Some local roles serve a second purpose. At first glance it appears strange that some of these ‘odd’ roles do not give more permissions than the user already has due to other roles. Their real purpose is to delegate permissions to the students or applicants section. If a user has for example the LocalStudentsManager role described below at department level, s/he automatically gets the StudentsManager role for those students studying in this department. We call this a dynamic role. In contrast to static global or local roles, dynamic roles are not stored in the database, they are dynamically assigned.

Local roles are assigned either automatically by the system during user object setup or manually through the web interface. The automatically assigned local roles are:

class waeup.kofa.permissions.Owner[source]

Each user ‘owns’ her/his user object and gains permission to edit some of the user attributes.

class waeup.kofa.applicants.permissions.ApplicationOwner[source]

An applicant ‘owns’ her/his application record and gains permissions to handle the record, upload a passport picture or add payment tickets.

class waeup.kofa.students.permissions.StudentRecordOwner[source]

A student ‘owns’ her/his student object and subobjects and gains permissions to handle all data, upload a passport picture, add payment tickets, create and edit course lists and handle accommodation.

All other local roles must be assigned manually via context manage form pages.

class waeup.kofa.permissions.ApplicationsManager[source]

The local ApplicationsManager role can be assigned at applicants container and at department level. At department level an Applications Manager can manage all applicants which desire to study a programme offered by the department (1st Choice Course of Study).

At container level (local) Applications Managers gain permissions which allow to manage the container and all applicants inside the container. At container level the permission set of this local role corresonds with the permission set of the same-named global role.

class waeup.kofa.permissions.DepartmentOfficer[source]

The local DepartmentOfficer role can be assigned at faculty or department level. The role allows to list all student data within the faculty/department the local role is assigned.

Department Managers (Dean of Faculty or Head of Department respectively) can also list student data but not access student pages. They can furthermore export payment overviews.

class waeup.kofa.permissions.DepartmentManager[source]

The local DepartmentManager role can be assigned at faculty or department level. The role allows to edit all data within this container. It does not automatically allow to remove sub-containers.

Department Managers (Dean of Faculty or Head of Department respectively) can also list student data but not access student pages.

class waeup.kofa.permissions.Lecturer[source]

The local Lecturer role can be assigned at course level. The role allows to export some student data within the course the local role is assigned. Lecturers can’t access student data directly but they can edit the scores in course tickets.

The following local roles do also delegate permissions to the student section. In other words, dynamic roles are assigned.

class waeup.kofa.permissions.ClearanceOfficer[source]

The local ClearanceOfficer role can be assigned at faculty or department level. The role allows to list or export all student data within the faculty/department the local role is assigned.

Clearance Officers can furthermore clear all students or reject clearance of all students in their faculty/department. They get the StudentsClearanceOfficer role for this subset of students.

class waeup.kofa.permissions.LocalStudentsManager[source]

The local LocalStudentsManager role can be assigned at faculty or department level. The role allows to view all data and to view or export all student data within the faculty/department the local role is assigned.

Local Students Managers can furthermore manage data of students in their faculty/department. They get the StudentsManager role for this subset of students.

class waeup.kofa.permissions.LocalWorkflowManager[source]

The local LocalWorkflowManager role can be assigned at faculty level. The role allows to view all data and to list or export all student data within the faculty the local role is assigned.

Local Workflow Managers can trigger transition of students in their faculty/department. They get the WorkflowManager role for this subset of students.

class waeup.kofa.permissions.UGClearanceOfficer[source]

UG Clearance Officers are regular Clearance Officers with restricted dynamic permission assignment. They can only access undergraduate students.

class waeup.kofa.permissions.PGClearanceOfficer[source]

PG Clearance Officers are regular Clearance Officers with restricted dynamic permission assignment. They can only access postgraduate students.

class waeup.kofa.permissions.CourseAdviser100[source]

The local CourseAdviser100 role can be assigned at faculty, department or certificate level. The role allows to view all data and to list or export all student data within the faculty, department or certificate the local role is assigned.

Local Course Advisers can validate or reject course lists of students in ther faculty/department/certificate at level 100. They get the StudentsCourseAdviser role for this subset of students.