Need some advice on my own Role Based Access Control (RBAC)

Question

I have a pretty simple profile page where users can upload images and videos. I have implemented my own role system and I'm not using .NET (I wanted to learn and builded my own). I'll have 10´000 users at the most and about 50-100 users simultaneously using it.

I have three tables in the DB that handles my RBAC:

Roles: Admin, User, Manager, Guest
Permissions: SendEmail, AdvancedSearch, RemoveUser... etc.

Authorized: In this table I map a role to a permission. I run a check every time a permission is required for an action. If the permission<->role is in the table I return true and the action is authorized.

So, here's a few questions on this scenario.

• Is this a light weight way to check authorization? By quering the DB on every page load and action the user makes.
• Should I keep this in an XML-file for faster result?
• Is there a better structure for this sort of RBAC?

Thanks in advance!

Answer 1

For 50-100 users, I would just cache something per-active-user in the app. This avoids any small overhead from a db fetch, except for when it expires. So just have some small object that you can cache cheaply, but which includes all the user information you need to run the app's core functions.

Ther's nothing stopping you using this to implement an IPrincipal to use the inbuilt [PrincipalPermission(...)] stuff, but doing it yourself works too.

Answer 2

Below are the answers to your questions.

• Is this a light weight way to check authorization? By quering the DB on every page load and action the user makes.

Ans. I would apply configurable caching system layer on database, and use this cache system for authorizations with customizable expiration time.

• Should I keep this in an XML-file for faster result?

Ans. I would not prefer xml file, instead use serialization.

• Is there a better structure for this sort of RBAC?

Ans. As far as the structure of the DB and RBAC is concerned, it should be secure enough that, access controls or permissions for applications cannot be directly tempered from DB.