Saturday, January 20, 2007

Guidelines on Designing a Better Security Model

I've collected some quick notes that will be helpful to guide you in designing a better security model. And to make it simpler, I'll explain it in a step by step example.

Assume you designed/implemented a multi-user application and would like to implement some sort of manageable security for the login accounts on the system. Read the following scenario:

1. Your system is comprised from a set of documents and pages.
2. You have multiple users on your system that can login.
3. The different users can perform different actions on the different documents and pages.

Till here we need to take a break and define some standard terminology used all over.

When it comes to security, the documents and pages are termed "resources", the different users are termed "subjects" and the different actions performed from those "subjects" on these "resources" are termed "actions".

4. I'd like now to collect a list of all the resources, actions and users on my application before I step into any design issues.

5. The resources I have are "Documents" and "Pages"

6. The actions I have are "Read", "Read/Write", "Upload", "Delete", "Edit" as an example. Note that certain "actions" can apply to certain "resources", while have no significance for other "resources", for eg. I can "Upload" a "Document", but I cant "Upload" a "Page". This is okay.

7. A list of users, this is usually stored somewhere in a database table or wherever, the important thing here is that those "subjects" are known.

After preparing a list of "resouces", "subjects" and "actions", I'll assume that no security is applied at all in the first place.

This means that any "subject" can perform any "action" on any "resource" whatsoever. In such a system, freedom fighters will enjoy it the most, while the rest will feel very insecure. Serving the rest will need some better security constraints on the different actions and resources in the system (sounds a bit political :\)

Here comes the concept of the "Access List".

The "Access List" simply defines which subjects can perform which actions on which resources?
Database wise, consider it a problem to figure out, simply it could be a table with a user id, resource id and action(s) for each row. Remember, its your design, I'm just giving guidelines here.

Ofcourse, when talking about the resource document or the resource page, we are indicating the resource type, thus its more of a resource type, and not a specific resource. Again, its your design, some might choose a very fine grained security model in which every single document has its own security, others will be comfortable with a certain action applied or denied for all documents.

An example "Access List" will simply say:

Subject "Basil" can "Delete" resource "Documents"
Subject "Basil" can "Read/Write" resource "Pages"
Subject "Whoever" can "Read Only" resource "Documents"
... (and so on)

The problem here is that if I have 100 users on my system, with 8 types of actions and three types of resources, then this "Access List" can grow indefinitely when describing the different permissions and will be hard to maintain by an administrator on the system.

Next post I'll show you how to tackle this problem.

ps. Comments, anybody, please, starting to feel lonely here.

2 comments:

Mahmood Abu Shaireh said...

Beso, I dont know what does resource means in your post? but I have a problem where I need to support inheritance for permissions and I lost my direction while looking for optimized solution that consider both storage and performance.

ANY IDEAS ....

Anonymous said...

Hi mabush,

Resource is simply the item you need to secure. This could be a page, a document, a message, or a collection of documents, pages, etc.

I dont know what you mean by inheritance of persmissions, do you mean "Privilege delegation"? Is it the same?

Hala man.