I agree with Dave overall. I don't think getting rid of multiple roles per user will buy us significant simplification.

A couple of additional comments.

The multi-role model is pretty common. For example, it is supported "out-of-the-box" in Shiro:

https://shiro.apache.org/static/1.2.3/apidocs/org/apache/shiro/realm/jdbc/JdbcRealm.html

However, in the "common" model, if you use permission granularity, roles are just sets of permissions and you want to check permissions (not roles) for determining access rights. Roller is weird in that roles are app-wide, permissions are scoped to blogs, and our usage of these notions is correspondingly somewhat skewed. Maybe that is what is hard to work with.

--a.



On 12/26/14 6:30 AM, Dave wrote:
On Thu, Dec 25, 2014 at 9:42 PM, Glen Mazza <[email protected]> wrote:

For the next release of Roller, I have some suggestions that I think will
increase adoption of Roller in corporate multi-blogger environments:

1.) I've brought this up before, but with 5.1 now out, I'd like to revisit
it.  I'd like us to tighten up our security subsystem by moving from
multiple roles per user to just a single role (presently ADMIN, EDITOR, or
whatever custom role an integrator may choose to create.) Specifically the
userrole table (lines 28-32 here: http://svn.apache.org/viewvc/
roller/trunk/app/src/main/resources/sql/createdb.vm?
revision=1625869&view=markup) would be dropped, and the rolename column
moved to the roller_user table.

Roller is not the Oracle RDBMS, we do not have nearly enough permissions
(just 3 or so) to assign to those roles to warrant needing to store
multiple roles with each user, and code needing to maintain and query
multiple roles per user is much more confusing/complex and prone to
security holes.  The current over-functional security architecture does not
provide easy confidence to integrators that Roller is secure to use,
harming adoption IMO.

By way of analogy, if you're crossing a stream via a footbridge very high
up, you don't care about all the bells and whistles the footbridge has, you
just want it to be clearly strong and solid, even if it's plain-looking,
else you won't walk on it.  Excessive bells and whistles may be great with
functionality but backfire with security as you lose confidence in the
product's ability to accurately calculate the proper permissions for each
user.

I think that is an unnecessary change that will have zero impact on
adoption, will cause and schema churn and introduce bugs. I would be better
to stick with the simple and conventional model, which is users have roles.


2.) Once that is done, it will be easier to determine who's an Admin, and
we have JIRAs already to allow Admins to drop users as well as obtain email
notifications of when users create or drop blogs.  I think blog admins
would like this increased "driver's seat" functionality and it would make
them more likely to adopt Roller within their company.

The change will not make it easier to determine who is an admin. What could
be easier than userManager.hasRole("admin", users)?


3.) (I've brought this up before, but I think I had bad replacement
suggestions at the time.)  The titles of the three blog
permissions--LIMITED, AUTHOR, and ADMIN--may be harming Roller adoption in
companies.  The permissions they contain is not the problem, it's just
their titles.  "LIMITED" can be taking as degrading to any user granted
that role and if I were a boss I'd be concerned about getting two week
notices from employees given that ranking.  "AUTHOR" has the problem in
that the person with that role frequently isn't the author but just
sanity-checking and publishing the blog article done by the person with the
LIMITED role, further irritating the latter.  ADMIN is less polished a
title for the blog owner, and it conflicts with the title we give the blog
server administrator.

Perhaps we should switch to CONTRIBUTOR, PUBLISHER, and OWNER (or
CO-OWNER)?  CONTRIBUTOR has no negative connotation and can fully imply
authorship of the submitted blog articles.  PUBLISHER is win/win, not only
is it a grander term than AUTHOR, at the same time it doesn't cause offense
to the CONTRIBUTOR by implying authorship in those cases where the
Publisher is just hitting the "Publish" button.  OWNER (CO-OWNER on the
permissions assignment page) is a more polished term than ADMIN while at
the same time reserving the latter term for those special people at the
top, the blog server admins who choose to install Roller in their companies.

I agree, limited is not a great term but I would disagree that we need any
schema change to fix this -- its just a label.

- Dave


Reply via email to