How to Implement Role Based Access Control 3

[Eugen Fintina]

I’m trying to find a method to implement Role Based Access Control.

Initially, I’ve defined some fixed roles (SuperAdmin, Admin, SuperUser, User, Visitor) and assigned each of them its access rights. Each role has all rights as lower one level plus some specific rights. All was Ok and worked as I expected.

But now, I need to define a custom role with access rights that belong to different fixed roles previously defined. It seems that I must change the philosophy.

So, I ask you to help me with some ideas about the way that I must take away.

 

[Tom Borgmann]

Hi Eugen,

SuperAdmin, Admin, SuperUser, User and Visitor are by definition group roles.
You will have to decide if a single user can be part of only one group or several groups.

IMHO its easier to maintain, to assign a User to only one group and to create a second login for another group, however, the users won't be amused

You will have to define group priorities as a group with a higher prio must be able to overwhelm rules from lower prio groups.
Your list already shows the correct prio queue. SuperAdmin rules all and Visitors don't rule anything.

I assume, that you already have a field or table where you store the group the user is assigned to. The simplest solution might be to allow a comma seperated group list in that field and to change your select from group = columnvalue to INLIST(group,columnvalue). Then add an order by priocolumn asc and you will always find the highest prio rules as the first record and you can ignore all follow ups.

EDIT:
This doesn't automatically break the way you organized you group until now, it only changed the way you handle the rules found by the INLIST() command as you can build specialized groups that don't have to inherit rules from lower prio groups.

OTOH, creating spezialized groups even just for a single user might also come in handy and you don't have to assign one user to several groups.

JM2C

-Tom

https://www.blogger.com/profile/08903165976787522012

 

[JRB-Bldr]

I assume that you are using the VFP Menu's SKIP FOR ... methods and/or the LOAD/INIT methods for individual VFP Forms as your Role Based access control.

If so, then its not very difficult to add one or more additional conditions from a Custom Role to the qualifying (or Not-Qualifying) criteria.

We typically use a numeric access right approach (10,20,25,30,35,40,etc.) rather than an Alpha word assignment (e.g. SuperAdmin, Admin, SuperUser, User and Visitor). That enables us to more dynamically control rights to any specific function.

However, as Tom said above, you should limit your users to only One Single role - be it one of the 'standard' roles or the 'custom' role.

Good Luck,
JRB-Bldr

 

[Olaf Doschke]

An access level is something many such systems begin with and having a numeric level the nature of a higher level inheriting all access permissions of a lower level is very easy, but yes, I've rarely seen such systems becoming too one dimensional.

First of all, some logical places to check permissions are in the menu, as already suggested with SKIP FOR conditions, then within Init or Load of forms rejecting access with RETURN .F. from nit or Load.

At the end what I most often implemented, was a series of low granularity permissions. when a user logs in all his permissions are accumulated into a bit pattern and what access levels are needed is determined by another bit pattern of the functionalities, a match is made with BITAND(Userpermissions,Featurerestrctions)=Featurerestrctions, so a user needs all the bits set, which an object or functionality needs.
With varbinary you can go up to 25*8 low-level permissions you can combine with BITAND or BITSETs, so you're not limited to 4 Byte ints with at maximum 32 bits. And you still check permissions with a single BTAND operation.

You can define, assign the necessary low level very fine granular permissions like READING a certain table, WRITING to a certain table, etc. and assign them bit numbers. Let's say you really just go for read/write permission of all your database DBFs and you have 40 DBFs of which 5 are only system relevant and never written to by users, 10 are publicly readable, means you need 25 tables are relevant to decide to assign read and write permissions and for the 10 tables everyone can read you only need bits to define write permission, your overall userpermission binary bits are fitting in 60 bits., which would only need a Q(8) field, 8 Bytes long.

To have it easier to assign these permissions you stay with the concepts of roles, rather groups you can assign users to and low-level permissions (bits). For the fast check, you use application initialization to pull together these Q(8) values for the features and the user and then during application usage only need the bit checks.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[Eugen Fintina]

Dear friends,

Thank you all for your detailed suggestions. Certainly they will help me implement a robust permission control system.

Now I just have to start working!

All the best,
Eugen