Role-based access control - should I have the perm

Question

Generally when implementing some sort of role based access control, we have the following well-known concepts:

• Role
• User
• Permission

And users would be assigned to roles each of which have a set of permissions (to perform an operation / access a resource etc). So users gain permissions to perform operations by being assigned to one or more roles (which have been assigned a set of permissions).

In any given application, permissions are defined at compile time since the code actually enforces the permissions at various places where access to resources .

My thinking is that if the set of possible permissions/operations changes – it requires changes to the code and recompilation any way, so having a lookup/reference table in the database won’t really provide any value beyond the fact that a db admin could do a quick sql query to list all permissions used by an app.

Yet most applications I’ve seen create a lookup table for the permissions and -also- map it to a enum in the code.

Given this, is there any reason to actually have a database table representing the list of possible permissions (other than the fact that it is probably easier for some to look in the db as opposed to digging into the code to find the list/enum of permissions)?

Answer 1

Checklist: 1) Do you need to make changes while the website is online, without downtime? 2) Will you be using built-in role/membership provider? 3) You want to use attributes (like mvc [Authorize]) etc? 4) You want to allow users to programatically change permissions/roles?

Any of the above means you have to store the info on DB.

For smaller scale apps I prefer to just create some static methods that also use some kind of inheritance, ie:

 isadmin()
 {
     if (usernameArray.Contains[currentname]) 
         return true;
     [...]
 }

 ispublisher()
 {
    if (isadmin()) return true;
     [...]
  }

And a table with permissions for each user pseudo-class.

Update: DB schema for specific access: (* is key, & is foreign key)

 Users:
 Username *
 [...]


 UserClasses (EG: admin...)
 ID *
 description

 AccessTypes  (EG: can delete)
 ID *
 description

 UserClassesAssign
 classid *&
 username *&

 AccessPerClass
 accessid *&
 classid *&

So anytime you want to see if 'username' is able to 'CanDelete' you have to check if the User 'username' is linked to any classes that are linked to the access 'CanDelete', and these links can of course change during runtime