Talk:Authorization Framework

From PKP Wiki
Revision as of 21:23, 22 February 2010 by (Talk | contribs) (Move outdated discussion to the talk page.)

Jump to: navigation, search

Flexible roles

The 'flexible' in flexible roles does not come from their non-existent abilities to support granular access divisions, but from the fact that the roles are now in the database and can be renamed, disabled, and restored. It was thought that someday, the 'flexible roles' label could change to something simple like 'roles'. The system name for these 'flexible role' entities did not suit the seemingly more appropriate label of 'custom roles' because, in order to support use cases like being able to rename roles, and to prevent having to deal with two types of roles separately (i.e. custom vs shipped), every role is a flexible role, each of which can be associated with a user by way of the 'roles' table.


I think your distinction between roles and access object groups is important. Access rights to certain parts of the system are what is really being associated with a user when a role is assigned to that user in PKP. I think using the term role has worked well so far, as it is a familiar concept to most (i.e. when logging-in in the morning, people identify more closely with 'it is my duty to perform the actions associated with this role'); however, I agree that, at the system level, using the more security-oriented language is more appropriate, as it reserves the term 'roles' for a different purpose and brings the terminology closer to what programmers might expect.


The use cases we have so far only involve intersection-free roles. All 'press-type' roles have access to the same operations in the Role handler. The 'author-type' roles are a bit of a special case in that they need access to author functions, which seemingly boils down to a routing issue. Besides creating more intuitive role spaces, these synonyms do not pack much else in terms of functionality at the moment, but I think they provide a basis for extension and an implementation of something that allows users to be more creative with roles.

In general

In general, I think that it would be good to work in the direction of your proposal, Florian. Pre-handler authorization checks in the dispatcher, as far as I can tell, would be great. Also, since we might not have the energies for another overhaul at this stage in the development of OMP, we could review what we have to make sure that it'll be easily re-factored into new security patterns in the future and that it contains the terminology we'll be able to put up with, while at the same time coming up with a definite approach to the more general design issues. Building custom roles, in the sense that you're describing, should definitely be part of the plan, but an overhaul probably isn't necessary for the current use cases.

Tylkkn 20:06, 7 January 2010 (UTC)

An opinion about the role GUI/code design currently proposed for OMP

Giving feedback on I had a long discussion with Tyler about the proposed authorization system for OMP.

Here my understanding of the current approach:

The basic permission building block is the handler operation. Basic access "roles" are then "hard coded" into the operations ("validation"). The number of roles will be considerably increased but the basic concept remains. Every operation is being assigned to one fixed role. This means that most of the time pre-defined roles are intersection-free: An operation that is part of one role will not be part of another role at the same time.

The "flexible role" approach enables users to assigns synonyms to these "hard coded" roles.

The full system would look something like this:

  1. Users are assigned to role synonyms ("flexible roles") or pre-defined base roles.
  2. "Flexible role" synonyms will be resolved to the pre-defined "base roles" if necessary.
  3. "Validation" (Authorization) is being executed on handler operations level by checking whether the required pre-defined role for a given operation is part of the user's assigned roles.

The difficulties I have with this approach are:

  • The terminology chosen for the approach is not very accessible for somebody not part of the PKP team. What PKP calls "validation" is usually called "authorization". (The term "validation" is usually used in the context of checking form values.) What PKP calls "roles" in the current approach would probably be termed "access object group" by other frameworks or projects. Of course words are just labels. But it certainly helps to keep the code basis auto-documenting and accessible if we use a terminology that is not specific to our project (where possible).
  • If I understand the proposed system correctly then there are no roles (in the classic sense) at all but permission groups are directly assigned to users. The difference between a "real" role and an access object group is that roles can have intersections and access object groups cannot. In other words: I can assign permission to the same access object to two distinct roles but I cannot usually assign the same access object to two access object groups. Access object groups are usually strictly hierarchical while roles can have intersections. Introducing "real" roles between access object groups and users will drastically reduce the number of required roles and the number of necessary assignments per user and thereby increase end-user usability. There have been purely hierarchical access object group systems historically but they are no longer "state of the art"...
  • Implementing custom roles by assigning "synonyms" to pre-defined roles is IMO quite unorthodox. It is ok to use this approach if custom roles will always be 1:1 assignable to pre-defined roles in the future. But IMO a more flexible approach is possible without extra cost. I'm also afraid that usability may suffer if we don't use an authorization approach that is well known to users.
  • Hard coding roles into handler operations is IMO also not the best solution. I guess that the new role system will force us to touch all validation methods anyway. Why not benefiting from this opportunity and refactor authorization into a central place (e.g. somewhere in the dispatcher) which is generally considered best practice for an authorization system.