3

I am trying to come up with a UI for controlling Resource based Access Control Lists (RBAC) in web application.

So far I would go with this approach:

ACL Control

I have a Searchbox with suggestion support. Once a user/role is selected it will appear in the list. I can then check or uncheck the corresponding permissions.

Is there a better way to do this, or is my suggestion suitable?

Ben Brocka
  • 40,865
  • 10
  • 112
  • 183
timeu
  • 261
  • 3
  • 5

2 Answers2

1

Tables like the one you have mocked in the question are an appropriate solution. However, I would recommend assigning a user to one or more user groups and assigning permissions to the user group rather than the user directly as it will save an administrator the task of having to set permissions for each user.

Virtuosi Media
  • 10,350
  • 4
  • 45
  • 54
  • Regarding groups: I believe that's what the "Role" shown in his mockup represents? – Kit Grose Jul 26 '12 at 00:04
  • @KitGrose Right, but those two shouldn't serve the same purpose as in his mockup. If roles exist, permissions should only be assigned to the roles, not the users. Roles, in turn, should be assigned to the users. However, if you're assigning permissions directly to the users, roles aren't necessary. The way he has it now is redundant functionality and could be potentially confusing. – Virtuosi Media Jul 26 '12 at 00:11
  • Ah, but that's defeating one of the main reasons for ACLs; you can say "this whole group has read access, but this one person has write access, regardless of whether or not she's in that group". I think it's exactly that flexibility that makes ACLs a difficult design problem, but I don't believe forcing users to make multiple permutations of each role to cover every situation is a reasonable outcome. – Kit Grose Jul 26 '12 at 00:16
  • @KitGrose - I guess it's a question of how a role scales. My initial reaction would be to just assign a user to multiple groups/roles. For example, if you have Group A with read-only access but want to give User Y write access as well, there are two ways to do it. Option 1 is to toggle write-access for User Y manually whereas Option 2 is to create Group B that has write-access and assign User Y to both Groups A and B. If Y is the only person ever to need that, Option 1 might be better. However, if we need to give write-access to Users X and Z as well, Option 2 would scale better. – Virtuosi Media Jul 26 '12 at 00:29
  • And ACLs give you the flexibility to make that decision on a case-by-case basis. I agree that they do give users enough rope to hang themselves, but having 1,000 roles defined with minimal people in each and really only applicable to one or two access control objects (ACOs) seems like the worst possible outcome. – Kit Grose Jul 26 '12 at 01:23
  • Another options is to have a user belong to a group but at the same time allow giving certain users permission directly. Permissions given directly to the user always win over the group permission. – Anna Rouben Aug 23 '12 at 23:01
0

The table you have created makes sense, but I would recommend switching the X and Y axes. You will most likely have fewer roles than feature sets that you would need to assign permissions to. For example, you may have 3-5 (Admin, Manager and End User, etc) roles, but multiple modules that each have Read, Write, Delete, Admin. You may be adding additional modules in the future.

By switching the axes, you are minimising the need for scrolling horizontally, and allowing the user to scroll vertically instead. This might be preferred.

Another option is to use a "tree structure with checkboxes" instead of a regular table. The tree structure will allow you to create additional dimensions. This would be recommended for larger scale applications. Each role could have its own tree structure.

Arjun Gupta
  • 1
  • 1