Authorization Framework

From PKP Wiki
Revision as of 06:00, 30 March 2010 by Jerico.dev (Talk | contribs)

Jump to: navigation, search

Role Based Access Control (RBAC)

The PKP framework implements role-based access control (RBAC). The elements of a typical RBAC system are:

  • Subjects (Agents, Users)
  • Objects (Resources) to which access should be controlled
  • Access Modes (e.g. "read", "write", "execute", etc.)
  • Permissions that define a certain mode of access to a resource
  • Roles

Subjects and permissions are assigned to roles. Roles are thereby an efficient way to define which subject has access to which resource and through which access mode.

Refinements of this basic access control model are possible:

  • Roles can be organized in a hierarchy whereby a subordinate role "inherits" permission assignments of its parent role.
  • Subjects, objects, access modes and permissions can be organized in groups so that they can be assigned or otherwise handled in "bulk".

PKP's RBAC implementation

PKP does not require all elements of the generic RBAC model. We apply the model to our application in the following way:

  • The subjects in PKP applications are called "users"
  • The only resource we control are handler operations.
  • PKP applications currently use a hard coded, non-configurable, editorial role model (e.g. in OJS: "editor", "section editor", "author", "reviewer", "journal manager", "site administrator", etc.).
  • PKP applications do not currently implement an explicit role hierarchy although there are two implicit role hierarchies:
    • A hard coded role hierarchy is established in practice: In OJS for example, the hierarchy goes from the site administrator over journal managers and editors down to section editors. Subscription Managers get a few handler operations from the Journal Manager.
    • Some roles (e.g. 'site administrator' and 'journal manager' in OJS) can "log in as" any other user, thereby temporarily inheriting 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.
  • Usually operations only define one mode of access ("execute"). There are a few exception to this rule, where different roles may access the same operation in different ways, e.g. the differentiated access of "editors" and "section editors" to some of the operations in the editorial process in OJS. In these cases access modes are hard coded into the operation.
  • 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.

Mapping of RBAC elements to the database

Entities and Relationships

  • RBAC subjects, objects, object groups, roles, permissions and permission assignments are all hard coded into PKP applications and are therefore not mapped to any database entities!
  • The interface of hard coded roles and the database is via PHP role constants (e.g. ROLE_ID_EDITOR).
  • The "roles" table that has been present in earlier releases of PKP applications is not representing roles but user-role assignments. The name of this database entity is conceptually wrong and was replaced with the introduction of configurable user groups.
  • Only configurable entities and relations are represented as entities in the database. These are "users", "user groups", "user - user group assignments" and "user group - role assignments". The corresponding database entities are "users", "users_user_groups" and "user_groups".
  • As with all PKP entities, the user and user group entity tables will be accompanied by a corresponding settings table that allows for flexible meta-data (=attribute) assignment and internationalization.
  • The "user_groups" table contains a foreign key to the non-database "role" entity. This means that the role column in "user_groups" contains references to the above mentioned role constants defined in the application code.

Cardinalities

  • one user can be assigned to several user groups, one user group can contain several users (0..n:0..m relation)
  • one user group can be assigned to exactly one role, one role can have several user groups assigned (1..1:1..n relation)
  • every role has a standard user group assigned which will never be deleted (which explains the 1.. relation).

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?