Authorization Framework - Revision history

Cbdilger: typo

2011-02-09T20:42:53Z

typo

Jerico.dev: Fixing link.

2010-09-02T19:13:03Z

Fixing link.

Jerico.dev: Added spec stubs for PKP lib and OJS

2010-09-02T19:06:30Z

Added spec stubs for PKP lib and OJS

Jerico.dev: Updated authorization framework documentation with the final implementation of policies in mind + general re-structuring and review of this page.

2010-09-02T05:30:42Z

Updated authorization framework documentation with the final implementation of policies in mind + general re-structuring and review of this page.

Show changes

Jerico.dev: Reordering sections

2010-07-06T00:16:09Z

Reordering sections

Jerico.dev: Adding the policy types section

2010-07-06T00:15:25Z

Adding the policy types section

Jerico.dev: Added the structure for the class model

2010-07-05T20:07:31Z

Added the structure for the class model

Jerico.dev: bug fix

2010-07-02T21:58:31Z

bug fix

Jerico.dev: Added a section explaining authorization enforce

2010-07-02T21:57:59Z

Added a section explaining authorization enforce

Jerico.dev: ANSI/XACML compliant wording

2010-07-02T20:40:13Z

ANSI/XACML compliant wording

@@ Line 78: / Line 78: @@
 We can group features that can be accessed by a given role into feature sets. Typical feature sets that we can address as a single unit are:
 * all features within the application
-* all features within a worflow stage
+* all features within a workflow stage
 * all features on a given page (e.g. review page for reviewers)
 * one or more visual blocks on a page.
@@ Line 87: / Line 87: @@
 A typical feature set definition would therefore be: Members of the author role have read access on all features of the submission stage page with exception of file access where they can also add (=upload), delete and edit (=file metadata) objects.
 === Object Access Logic ===

@@ Line 133: / Line 133: @@
 == Permission Specification ==
-Based on these concepts we've developed a [https://spreadsheets.google.com/ccc?key=0ArYsBcy_S9NkdHdfTW9iUS1ad0ZJMWRlcXhkbnhpSUE detailed permission specification for OMP]. Similar specifications will have to be developed for the other PKP applications. Specification stubs exist for the [https://spreadsheets.google.com/ccc?key=tvgktJYvMJgiPwRjjPbM-TQ PKP library] and [OJS https://spreadsheets.google.com/ccc?key=t40Io9zHBsJc07jhgKKF8eA].
+Based on these concepts we've developed a [https://spreadsheets.google.com/ccc?key=0ArYsBcy_S9NkdHdfTW9iUS1ad0ZJMWRlcXhkbnhpSUE detailed permission specification for OMP]. Similar specifications will have to be developed for the other PKP applications. Specification stubs exist for the [https://spreadsheets.google.com/ccc?key=tvgktJYvMJgiPwRjjPbM-TQ PKP library] and [https://spreadsheets.google.com/ccc?key=t40Io9zHBsJc07jhgKKF8eA OJS].
 == What are some restrictions in our access model? ==

@@ Line 133: / Line 133: @@
 == Permission Specification ==
-Based on these concepts we've developed a [https://spreadsheets.google.com/ccc?key=0ArYsBcy_S9NkdHdfTW9iUS1ad0ZJMWRlcXhkbnhpSUE detailed permission specification for OMP]. Similar specifications will have to be developed for the other PKP applications.
+Based on these concepts we've developed a [https://spreadsheets.google.com/ccc?key=0ArYsBcy_S9NkdHdfTW9iUS1ad0ZJMWRlcXhkbnhpSUE detailed permission specification for OMP]. Similar specifications will have to be developed for the other PKP applications. Specification stubs exist for the [https://spreadsheets.google.com/ccc?key=tvgktJYvMJgiPwRjjPbM-TQ PKP library] and [OJS https://spreadsheets.google.com/ccc?key=t40Io9zHBsJc07jhgKKF8eA].
-−
 == What are some restrictions in our access model? ==

@@ Line 246: / Line 246: @@
 == Class Model ==
 === Policy Types ===
@@ Line 279: / Line 277: @@
 * Permit overrides
-=== Role-Permission Assignment ===
+=== Decision Points ===
 == Open Questions ==
 * Can the "groups" table be integrated with the "user_groups" table. This would be preferable
 * Can we better implement role inheritance so that the currently implicit hierarchy is made explicit and enforced systematically?

@@ Line 249: / Line 249: @@
 === Decision Points ===
-=== Permission Types ===
+=== Policy Types ===
 === Role-Permission Assignment ===

@@ Line 191: / Line 191: @@
 * '''Subject-role assignments''' are configurable via the role administration UI in PKP applications.
 * We recently introduced configurable '''subject groups''' or in PKP terminology "user groups" that allow bulk assignment of several users to one (and only one) of PKP's hard coded roles. The names of user groups can be freely defined in the role administration UI. Applications that make use of user groups will no longer allow direct subject-role assignments. It must be stressed that user groups are not roles although end users do not necessarily need to understand this distinction. PKP developers should be very clear in their terminology, though, to avoid confusion and implementation errors. '''The term "flexible role" is deprecated in favor of "user group" and should no longer be used.'''
 == Policy Configuration and Enforcement ==
@@ Line 244: / Line 229: @@
 * Hard coded roles: If we want to introduce a new role we'll have to introduce it in code which means that we cannot let the user introduce new roles with differentiated access levels.
 * Scattered authorization functions: We currently have several different models for the distribution of authorization functions accross the
 == Open Questions ==
 * Can the "groups" table be integrated with the "user_groups" table. This would be preferable
 * Can we better implement role inheritance so that the currently implicit hierarchy is made explicit and enforced systematically?

@@ Line 234: / Line 234: @@
 * Data object based decidions are taken directly within the handler that makes the decision request: either as part of the validate() method call or within the handler operation itself.
-=== Authorization Decision Requests and Enforcement ==
+=== Authorization Decision Requests and Enforcement ===
 Currently all authorization decision requests emanate directly from the handler and will also be enforced there:
 * Authorization decisions taken by way of the HandlerValidator classes will be either enforced in the PKPHandler (e.g. by re-directing the request to the log-in or another permitted page) or in the handler operation itself by letting the validate() pass the decision result to the handler operation which then is responsible to correctly enforce it.
@@ Line 243: / Line 243: @@
 * Hard coded permissions: permissions cannot be configured by the end user nor can we create "permission profiles" for different applications or use cases if such would become a requirement. This also implies that if we need to implement different permissions for different applications then we have to write application-specific sub-classes which means that permission definitions either have to follow the inheritance hierarchy or have to be duplicated in several places. Hard coding permissions also means that requirements like subscription based access have to be hard coded into the operations rather than providing central access profiles which could be changed in one single place.
 * Hard coded roles: If we want to introduce a new role we'll have to introduce it in code which means that we cannot let the user introduce new roles with differentiated access levels.
 * Scattered authorization functions: We currently have several different models for the distribution of authorization functions accross the
 == Open Questions ==
 * Can the "groups" table be integrated with the "user_groups" table. This would be preferable
 * Can we better implement role inheritance so that the currently implicit hierarchy is made explicit and enforced systematically?

@@ Line 184: / Line 184: @@
 ** Some roles (e.g. 'site administrator' and 'journal manager' in OJS) can "log in as" any other user, thereby temporarily inheriting all permissions of the impersonated user's role.
 * '''Permission-role assignments''' are hard-coded into the application. Handler operations define which roles may access it. Currently authorization checks are part of the request "validation" procedure.
-** Most of the time all operations within a handler may be accessed by the same roles. In these cases the handler constructor (for pages) or handler-wide validation method (for AJAX controllers) implement the permission-role assignments for all contained operations. In other words: We usually define an '''access object group''' that contains all operations of a handler.
+** Most of the time all operations within a handler may be accessed by the same roles. In these cases the handler constructor (for pages) or handler-wide validation method (for AJAX controllers) implement the permission-role assignments for all contained operations. In other words: We usually define a '''policy''' that contains permissions for all operations of a handler.
 ** HandlerValidatorRoles classes define the assignment of operations to roles
 ** Database object permissions are usually either hard coded into the validate() method or the handler operation itself