How to Design Security

Design process

To be able to implement security system, you have to first design it - which means two things:

1. designing rules stating who is authorized to do what under which conditions (this is a managerial decision)
2. translating these rules into ERP5 vocabulary

Stage (a) results in a long text, describing in detail tasks of certain people and various security restrictions. For example, let's assume we have a company X which has a number of departments (A, B, C). Each department can publish articles on the company's web site, but they want to do it in an orderly way. Security document could look like this:

Every employee can create an article for web publication.` Other employees of the same department can see this article and make changes to it. The documents is published only after the boss of the department agrees for its publication. When the document is submitted for the boss' approval, the department employees can not modify it, but the boss can make final modification before publication. Once the article is published, it is not editable at all. The company's management wants to control what is being published or prepared for publication, so they can see every article at every stage, but can not modify them. Once the article is published, the boss of the department and the company management can take it down from web site.

Roles, or who is who

Now, let's anyalyze it the ERP5-ish way: what we see here is that there are five "categories" of people involved:

Note that we don't list the author of the article, because the security document doesn't say anything about him having any special permissions.

What are these four groups supposed to do in relation to the article?

When we translate it into the "5A" roles, it all fits very nicely:

Now we have enough information to write all fancy security scripts and role definitions - for information how to do it, refer to more technical articles. Here we are talking about design.

Workflow

When we read the security document, we see that a document is first created, someone writes it, then the boss looks at it and decides if it is good or not, and finally it shows up on the company's web site. We can now design a workflow, which means states and transitions. From security point of view, there is one rule: if the security settings for a documents change, it means it has to enter a different state. Therefore, we will have the following states:

It should now be pretty easy to fill the second column with roles and permissions (V means "view", M means "modify"):

A word of explanation: we don't have "V" to Assignor in draft or submitted, because every department's boss is an employee of the department, so every Assignor is also an Assignee. Anonymous is a role Zope gives to anybody accessing the system.

Note: the "Author" role is a bit different, because it refers to the module the articles are stored in, not to an article, so it is not used in workflow.

The last question we must ask ourselves, is who can make workflow transitions? The document is quite clear about that, so let's draw a table:

And this is it - a security regulations which took so long to describe now fit in three small tables. And this is just enough information for an application developer to sit down and implement the whole process. Which would take him much less time that it took me to write this article...