I haven't looked at Roller's security model for many years, so there's a good chance my comments are nonsense.
If there are really only 4 permissions then there are only 16 possible roles. The point of roles is usually to simplify assigning sets of permissions to users. If there are only 16 possible roles multiple assignments seem sort of excessive. Certainly in this case I'd expect to be able to view which of the 4 permissions a user had. That being said, could the one-role-per user be enforced by simple adding a uniqueness constraint on the user-role association table for the user id? thanks david jencks On Dec 26, 2014, at 5:39 PM, Glen Mazza <glen.ma...@gmail.com> wrote: > > On 12/26/2014 09:30 AM, Dave wrote: >> On Thu, Dec 25, 2014 at 9:42 PM, Glen Mazza <glen.ma...@gmail.com> 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. > > I see it oppositely -- in my evalution, the presence of the userrole table is > the biggest handicap for Roller for getting greater usage in companies today, > the unwarranted clumsiness it adds to the security model makes it that much > harder for a security expert to analyze and assure that it's secure--namely, > that unwarranted roles are not getting attached to users. There's little I > can do for increasing Roller adoption, especially within companies, so long > as we keep that table. I'm thinking about forking Roller over this very > issue. That said, I have very little time to add to the project now anyway > due to work constraints, so I doubt I'll be going my own way on this. If you > guys want to keep this table, we'll keep it, but I think it's a unfortunate > decision. > > >> >> >> 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)? >> > > Oh, the call is simple, but what does it mean when someone has both the > EDITOR and the ADMIN role when they have no reason to have both, as the > latter covers the former? "Well, just make them admin!" But what if it was > the ADMIN and not the EDITOR role which was erroneously given? There's your > security hole, borne from unnecessarily allowing multiple roles for a user. > > The problem with allowing multiple roles to be assigned to a user is that > while you think you've tightened up the security for a user by granting him > just EDITOR, if he happens to still have ADMIN in the userrole table he > remains an admin. And we don't have the user interface that makes it clear > if a user has multiple roles. > > Another problem is that the above check "userManager.hasRole("admin",...)" is > inaccurate because it is the permissions that comprise the role that matter > (indeed, we allow users to create their own roles with whatever permissions > attached.) If you give admin permission to an EDITOR role or take away admin > permission from the ADMIN role the call above is inaccurate. We're supposed > to be checking permissions, not roles--the role is just to be consulted to > see which of the four permissions the user has. You already have the level > of indirection between permissions and a role allowing for convenient > assignment of permissions to users, given that we have just 3-4 permissions, > multiple roles is unnecessary and a source of confusion and bugs. > > >> 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. >> > > Yes, I was recommending changing the labels, no database schema or database > column value changes. (The database doesn't use the terms LIMITED, AUTHOR, > and ADMIN anyway but different ones.) > > Glen > >> - Dave >> >
