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:

employed in the company

working in the same department as the author

the department's boss

the management

working in other departments

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?

employed in the company

create a new article

working in the same department as the author

cooperate on writing the article

the department's boss

approves the article

the management

monitors the publication activity

working in other departments

do nothing at all

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

employed in the company

create a new article

Author

working in the same department as the author

cooperate on writing the article

Assignee

the department's boss

approves the article

Assignor

the management

monitors the publication activity

Auditor

working in other departments

do nothing at all

-

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:

draft

submitted

published

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

draft

Assignee (VM), Auditor (V)

submitted

Assignee(V), Assignor (M), Auditor (V)

published

Anonymous (V)

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:

submit

draft --> submitted

Assignee

publish

submitted --> published

Assignor

reject

submitted --> draft

Assignor

unpublish

published --> draft

Assignor, Auditor

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...

HowToDesignSecurity (last edited 2008-01-03 13:48:04 by localhost)