Tips for developing app with different permission levels

Does anyone have any tips as we develop an application that will require each user to be assigned a permission level. The permission level will determine what functionality is available to the user.

Any advice?

How would you (do you) employ such functionality in your application?

From stackoverflow

• This is the partial ER diagram for identity module in Turbogears, Python. It implements what you are looking forward to. Users are associated with groups and groups have associated permissions.

  The two ways restricted feature availability can be implemented are:

  1. (I prefer)In your controllers check the group to which the user belongs to and moderate your response to the View according to that. Thus View is just a renderer - no business logic.
  2. The View gets the user details like groups and permissions and it decides what to display and what not to (MVC violated).

  Read more about MVC (and Turbogears may be).

  

• It depends a lot of the language you use and the architecture of your application (web service ? client software ?).

  For a server toy project, I though about assigning a minimum permission level to each command, and check it directly when a command network packet is received, triggering a permission error when the user hasn't a high enough level. I might not be suitable for another architecture.

  Helios : C#, client/server desktop application

• First you need to figure out what functionality you want to cover by your permission system, and in what detail:

  • Access to tables (List, CRUD)

  • Functions/Modules

  • Access on record level (=ACL)

  • Positive (grant) or Negative (revoke) semantics

  • What is the "admin" role allowed to do

  If you want to restrict access to tables, you can easily set up an additional table containing all the table names, and grant select-list/select-record/insert/update/delete access to the roles/groups, as sketched by JV.

  If you want to grant access to functions or modules, have a table of modules and grant execute to roles/groups.

  Both functionality is equivalent to grants in SQL.

  Access restriction on record level is much more complicated, as you need to model access rights on the status of a record (e.g. "public", "private", "released" in CMS apps), or have explicit permissions on each record.

  If you want to implement a permission scheme equivalent to NTFS, you calculate the permission per record based on the group the user is assigned to, and have user-specific permissions that may override the group permissions, and revokes overriding grants.

  My applications typically work on table+function / group level, which may be good enough, depending on your requirements.

• It may be a bit of a dead end to pursue the concept of 'levels'. It may suit your current application, however a data model that consists of a mapping of roles to privileges is more general and suits most purposes.

  Assign roles to users. A user may have more than one role, and their role(s) define the privileges they have. The concept is similar to groups, however 'role' is usually easily mapped directly to business logic (think of roles such as 'administrator', 'user', 'clerk', 'account manager', 'regional manager', etc). Privileges also map fairly directly to functions and data objects. You may also be able to map to implementations that use underlying platform access control (e.g. Java privileges).

  In the controller code, you check (via their roles) that the user holds the required privilege to perform a function. It is also good practice to modify your views to hide functions that the user does not have the privileges to perform.

  In your design you can visualise / document the access control system as a matrix (roles to privileges).