On security system, part 2

This is the second part in a series of posts that are dedicated to security system concept in DataObjects.Net. The first part contained common considerations and bits of theory.

In this part I'll tell you about the development approach we chose.

To avoid the situation when a framework is being built according to some pure theoretical ideas and as a result it is hard to use it in real world scenarios we had decided to start from the other side: try implementing an application that seems to be more or less real, put into practice our security concepts and thus develop the security system.

We chose Northwind database model as a playground and slightly modified it to add some complexity in company staff relationships.

Here is the updated organization chart for our Northwind company.

There are 2 sales departments: first is located in Seattle and second is in London. Both of them are managed by a sales manager, each of them has 2 sales representatives and 1 stock manager. Sales representatives report to sales manager, both sales managers report to sales president.

In this application model we defined the following main types of entities to secure:

• Customer
• Order
• Product
• Employee

There could be much more types to secure but there is no necessity as those four is enough to build more or less authentic model.

Next we have to define which company staff will have access to these secured entities, and which won't. Moreover, there might be several levels of access, for example, read, write and any other more specific ones.

According to the organization chart, we define 4 main roles:

• Stock manager
• Sales representative
• Sales manager
• Sales president

Each of them has its own set of duties, responsibilities, permissions and limitations. In our model there is the following distribution of all that stuff:

• All staff has read-only access to employees data.
• Stock managers manage products. They doesn't have access to customers and orders.
• Sales representatives have read-only access to products, have full access to customers of their sales department and their own orders. They don't have access to order approval.
• Sales managers also have full access to customers of the sales department, to their own orders and well as to orders of sales representatives in their sales department. Moreover, sales managers have access to the order approval operation.
• Sales president has access to all kind of information without limitation, but in read-only mode. In addition, he can manage employees (hire, dismiss, so he also has write access).

Here is the graphical matrix that shows access rights to entity types:

This matrix that demonstrates the additional limitations that must be met as well.

So, here is the deal: we need to provide a flexible and efficient security framework that can be used in domain models like this one with all above-mentioned permissions and limitations. In the next post I'll show you whether we managed to achieve the goal and how we did it.