Changeset 12849
- Timestamp:
- 12 Apr 2015, 13:15:00 (9 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
main/waeup.kofa/trunk/docs/source/userdocs/security.rst
r12847 r12849 4 4 ******** 5 5 6 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. 7 8 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 permssions. 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. 6 Kofa has a very efficient security machinery. The machinery does not 7 perform authorization checks on the content objects themselves stored 8 in the database but restricts the usage of views, i.e. web pages and 9 forms which are needed to view or edit data. Views are protected by 10 permissions the user must have to use the view. Instead of assigning 11 permissions seperately to users, permissions are bundled into sets of 12 permissions, so-called roles which can be assigned to users through 13 the web interface. 14 15 It is important to note that permissions do not include other 16 permissions. Only roles 'include' permissions. A 'manage' permission, 17 for example, does not automatically enable users to open pages which 18 merely display the data. These pages have their own 'view' 19 permission. Another example is the ManagePortal permission described 20 below. The name of the permission may lead to believe that users can 21 do everything with this permssions. This is not true. It does only 22 give access to certain pages which are dedicated to portal managers 23 and must not be accessed by any other user. 9 24 10 25 .. contents:: … … 13 28 =========== 14 29 15 The whole set of permission and role classes are described in the :py:mod:`Permissions and Roles Module<waeup.kofa.permissions>`. Here we describe only a subset of permission classes which are essential for the security settings configuration. 30 The whole set of permission and role classes are described in the 31 :py:mod:`Permissions and Roles Module<waeup.kofa.permissions>`. Here 32 we describe only a subset of permission classes which are essential 33 for the security settings configuration. 16 34 17 35 General Permissions … … 126 144 ============ 127 145 128 Global or site roles are assigned portal-wide. In contrast to local roles, users have this role in every context. 129 130 Many global roles do only bundle one or two permissions. The objective behind is to share responsibilities and distribute tasks. 146 Global or site roles are assigned portal-wide. In contrast to local 147 roles, users have this role in every context. 148 149 Many global roles do only bundle one or two permissions. The objective 150 behind is to share responsibilities and distribute tasks. 131 151 132 152 Global roles are being assigned via the user manage form page. … … 162 182 :noindex: 163 183 164 In contrast to these specialized sets of permissions, there are two sets which delegate extensive powers on portal managers. 184 In contrast to these specialized sets of permissions, there are two 185 sets which delegate extensive powers on portal managers. 165 186 166 187 .. autoclass:: waeup.kofa.permissions.PortalManager() … … 173 194 -------------------------------- 174 195 175 Global Application Section Roles are assigned portal-wide (globally) but do actually only allocate permissions in the Application Section. 196 Global Application Section Roles are assigned portal-wide (globally) 197 but do actually only allocate permissions in the Application Section. 176 198 177 199 .. autoclass:: waeup.kofa.applicants.permissions.ApplicantRole() … … 187 209 ---------------------------- 188 210 189 Global Student Section Roles are assigned portal-wide (globally) but do actually only allocate permissions in the Student Section. 211 Global Student Section Roles are assigned portal-wide (globally) but 212 do actually only allocate permissions in the Student Section. 190 213 191 214 .. autoclass:: waeup.kofa.students.permissions.StudentRole() … … 210 233 ======================================= 211 234 212 In contrast to global roles, which are assigned portal-wide, local role permissions are gained for a specific context. 213 214 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 application 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. 215 216 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: 235 In contrast to global roles, which are assigned portal-wide, local 236 role permissions are gained for a specific context. 237 238 Some local roles serve a second purpose. At first glance it appears 239 strange that some of these 'odd' roles do not give more permissions 240 than the user already has due to other roles. Their real purpose is to 241 delegate permissions to the students or application section. If a user 242 has for example the LocalStudentsManager role described below at 243 department level, s/he automatically gets the StudentsManager role for 244 those students studying in this department. We call this a **dynamic 245 role**. In contrast to static global or local roles, dynamic roles are 246 not stored in the database, they are dynamically assigned. 247 248 Local roles are assigned either automatically by the system during 249 user object setup or manually through the web interface. The 250 automatically assigned local roles are: 217 251 218 252 .. autoclass:: waeup.kofa.permissions.Owner() … … 239 273 :noindex: 240 274 241 The following local roles do also delegate permissions to the student section. In other words, dynamic roles are assigned. 275 The following local roles do also delegate permissions to the student 276 section. In other words, dynamic roles are assigned. 242 277 243 278 .. autoclass:: waeup.kofa.permissions.ClearanceOfficer()
Note: See TracChangeset for help on using the changeset viewer.
