Role Based Security

Just a quick summary from the last security post...

A resource is what you need to protect. It could be a document, html page, folder, part of the system, etc.
A subject is the user, him or her who acts on the resource.
An action is what the subject performs on a resource.
An Access List is a table describing what 'action'(s) can a subject perform on a resource.

Lets say we have an admin application, with four sections. User Management, Reporting, Backup & Restore. These can be 3 resources that we want to protect. Remember, a 'resource' is any thing you want to restrict access to.

The subjects are the 10 users. For simplicity, the actions can be Allow, Deny. (ofcourse, some actions could apply to certain resources only specially when you have finer permissions).

The access list could contain:
User A --> Allow --> User Management
User A --> Allow --> Backup & Restore
User A --> Allow --> Reporting
User C --> Allow --> Reporting
User C --> Allow --> Backup & Restore
User C --> Deny --> User Management
User D --> Allow --> Reporting
...
For 10 users, the table grows, for 100 users the Access List becomes so big... and so administratively consuming. The poor administrator will have to assign the action for every and each user on the system.

Here comes the concept of the "Role". A role is simple a middle entity between the subject's (ie. users) and the actions that would greatly simplify maintaing the access list. The access list in role-based security is called a Role Based Access Control List (abbr. RBACL).

We can now create three Roles; Reporter, Full User, and Guest. The Role Based Access List will now hold Role --> Action --> Resource instead of User --> Action --> Resource.
And another table will hold the User --> Role mapping.

See how simple the Access List becomes:
Full User --> Allow --> User Management
Full User --> Allow --> Reporting
Full User --> Allow --> Backup & Recovery
Reporter --> Allow --> Reporting
Reporter --> Deny --> User Management
Reported --> Deny --> Backup & Recovery
Guest --> Deny --> Backup & Recovery
Guest --> Deny --> Reporting
Guest --> Deny --> User Management

Thats it! Now all you have to do is to add a column in the users table
to specify a Role.

for example, User --> Roles will be:
User A --> Full User
User D --> Guest
User E --> Reporter
User F --> Guest

See how simple it becomes, every new user will only need to assign him or her one Role instead of re-defining all the actions he can perform.

Next post, I'll introduce you to extending your design, and some guidelines to stick to.