eyedia / aarbac

An Automated Role Based Access Control .NET framework with T-SQL Query Parser which automatically parse select, insert, update, delete queries based on the logged in user role

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Framework questions

percramer opened this issue · comments

Hi,

i found your codeproject article and started reading. Looks like this might be something that is good for a project of mine.

All the role data is now stored in an xml file apposed to in the database, is there a reason for this?

Can a user have multiple roles?

But i might need to alter it a bit so it becomes more generic, because it now looks like it is really fixed to your vision (which is not to bad), but i already have got a system setup for showing / and disabling interface parts and i need to see if this can fit into your system. Forking it and making changes wouldn't be to good because that would break the compatibility with future updates from you.

Regards,

Per

  1. Role data: (a) CRUD Permissions, in framework term, 'RBAC MetaData' and (b) Entitlement data; both are in XML format, & stored in database. Check out RbacRole table, the columns are MetaDataRbac and MetaDataEntitlements respectively.

  2. Multiple roles - Currently 'No', but design wise its very easy to implement, that is in my todo list.

  3. My goal is to provide a generic solution, if you can let me know your use case, I can comment. As per understanding (probably I am guessing!) your requirement is fitting into it.

By the way, code project wants me to more elaborated article and they removed it, I was busy partying these holidays and did not get time to modify it! LOL.

Happy new year!

ofcourse a happy new year also!

Yeah i saw that codeproject put the article down last week. I am still searching a bit through your code to see what does what :-)

In my program the users are allowed to add fields etc through the interface. So they are basically doing schema changes through my software. This is because i think that no software matches the users processes and it is also not good if a user should alter it's internal companies processes to a software. Well to a certain extend it is ok if users are forced to work through a standard / process.

  1. So if i see it correctly the entire metadata is stored in a single field? So for the entire role. I am just wondering what is easier for maintenance. At this moment is store them in separate rows in a sub table per role. But that doesn't mean that what i am doing is better. For maintenance it might be easier because i can do a lot in the sql manager now (by just doing simple editing and adding of sub rows to a role.

  2. I think this one is important for a good security system. Because creating a role for every option that might be available is a hell of a job to maintain. In my basic setup that i use now users can just have multiple rolls. So i add them to the "basic usage" roll and just give an accounting person also the "accounting" role.

  3. All interface parts that a user can click on are generated dynamically in my software. Actually the entire interface in generated dynamically from the content of the database. So also the entire edit forms for data editing. Buttons, menu's etc are stored in a table called "links". Links are of a certain type and have got a parent / child structure (to create menu's and sub menu's for example).

I am not opposed to xml, settings for single items / fields etc i also store in xml in the database. I am just wondering if the editing / maintenance of user rights and links are easier in a singel xml fields or multiple data rows

This is turning out to be an interesting conversation.

Following are my comments wrt the aarbac framework, I do respect your thoughts around your requirements.

1 – Yes, into single field. I wanted to try to abstract all maintenance into a framework & let the code be as clean as possible, no ifs, elses & other checks. Aarbac reads the database schema and extracts everything into an XML and then let admin put security on top of it. Currently it supports CRUD on tables with conditions.

If I understood correctly, based on their permissions, users will be able to add/modify/delete columns into/from tables based on the roles. E.g. user ‘u1’ can add new column into table ‘t1’ but cannot delete column from ‘t1’, can rename existing columns on ‘t1’. aarbac can be modified to handle these additional permissions on the tables. Note - the main advantage of aarbac is no ifs, elses, your code is not growing, hence maintenance is low. I have some thoughts around the screen look and feel and one of my UX friend helped me designing the screen. Look at this small video

2 – Well, in aarbac also you can create ‘basic usage’ role and assign ‘accounting’ role to accounting person.

3 – No comments, thanks for explaining.

This discussion helped me to find a valid use case. If this is a common requirement, I want to try to implement it in aarbac. But a bigger thought is required to set a line…can user create table? Can user delete table? And so many other open questions…

Good thoughts! Keep it coming!

So on point 2, that is exactly what you don't want in bigger erp / crm systems. Because that would mean that you need to create roles for everything you can think up. It is way maintainable if you could apply multiple roles to a person / group. So you don't have to do all the settings again and again for certain roles. So stack roles is way easier to maintain

alright my friend! Happy programming! Let me know if my framework can help you on anything.

cheers!