Most Powerful Open Source ERP

How To Understand ERP5 Security

How To explaining ERP5 Security and how it is meant to be used.
  • Last Update:2017-01-23
  • Version:003
  • Language:en

This documents explains the basics of the 5A security model in ERP5 and shows how to apply the model in Accounting. This document is explaining theoretical concepts. For the actual steps required to set role based permissions, please refer to how to set user access permissions.

Table of Contents

ERP5 Security Explained

Security is essential in most companies, because not every person in company should be allowed to do the same as other persons. An example would be only qualified accountants being able to validate accounting transactions, because these are legal procedures. Another example is ordinary worker not being allowed to make new purchase order or modify existing orders without approval by a manager.

This means that also within an ERP system there need be certain mechanism preventing people from doing what they should not do. One way of doing this is to specify what a given user can do and cannot do, but this is not scalable, because if you have 100 workers in your company, you would have to set permissions 100 times already.

ERP5 and Zope address these question by using roles. For example, if a company has two or more accountants, it would be a good idea to create a role called Accountants and then set up permissions for this role Accountants instead of specifying permissions for the all accountants separately. This reduces the number of permissions that have to be set dramatically and greatly reduces the cost of maintaining such a system.

However with system complexity or an ERP system with many modules, this role-based security will also be difficult to maintain. Suppose that you have two modules for sale orders and accounting transactions. As above a you will probably define the roles Sale Manager and Accounting Manager so that some restricted people can make final decisions or perform legally relevant tasks. Yet, you will need more roles for ordinary workers, such as normal Accountants or Sale Assistants. The number of roles grows quickly with number of staff and modules in ERP5. If you have 20 modules, you might already need over 40 roles resulting in a huge table of permissions since the table size based on number of permissions * number of roles. Additional complexity is introduced because certain roles are completely independent from each other - a Sale Manager Role will share nothing with an Accounting Manager role.

To manage this complexity at scale, ERP5 uses the 5A Security Model. It reduces the number of roles significantly and provides a clear overview of the security system. 5A stands for Author, Auditor, Assignor, Assignee and Associate - the roles which can be used to define permissions for users in a generic form, and independent of modules. In addition, ERP5 also provides some built-in roles such as Zope such as Owner.

5A Security Model

ERP5 provides a simple and consistent view of business security using the 5A model. It consits of five generic roles: Author, Auditor, Assignor, Assignee and Associate. Users are associated with these roles on a per-module basis using local roles for each module. Local roles are roles which are effective only in a specific module or document context, so it is possible to use a limited number of generic roles to decrease the complexity of the security problem.

The generic roles can be defined as follows:

Author

The Author is the one who can creates new documents. But the Author is not allowed to view documents. Imagine sales people who register drafts of new sale invoice transactions. Usually these people may not do anything else, so they are authors.

Auditor

Auditor are allowed to view documents but they are not allowed to make or modify them. Suppose sales people who should know all products in a company but are not concerned with product design. They are auditors, not authors.

Assignor

Assignor is the most responsible one. This role allows to do all tasks (create and view) and may assign other users to assignees of documents. This is used for sale manager, accounting manager, and so on.

Assignee

Assignee is the one who can do all tasks under the control of Assignor. Assignee is used only if Assignor assigns a user to an assignee of a document. Assignee is supposed to work on a part of a module. For example, you can define a worker as Assignee only for documents related to a specific customer, if the worker is familiar with the customer.

Associate

Associate is allowed to do some tasks on a document only when another document related to that document is assigned. This is a bit complex, so consider this situation: You are a new employee in a restrictive company and are dealing with a sale order requiring you to acess the customer on the sale order. As your employer does not want to give you access to all customers right away, the manager has to limit your access to information on only the customers with which you have to deal. In other words, you are allowed to access a given customer only if a sale order assigned to you is related to this customer. This is the Associate.

Owner

ERP5 uses another role called Owner which is a standard role in Zope. Owner is automatically assigned to a user when the user makes a new document. So if you are willing to allow an author to view documents owned by the author, you can specify proper permission settings based on Owner.

How To Set Permissions For 5A

Permissions are set by through a combination of static settings in modules and workflows.

Module-level security is used to determine who can make new documents, who can modify existing documents, who can delete existing documents and who can view existing documents. Because these settings are on the module level, there is no distinction between documents. If you need to make difference among documents - like Assignee - then you have to use document-level security.

Document-level security is used to determine who can modify a given document, who can view a given document and who can change the state of a given document. So this security is in particular important for Assignee and Associate. Document-level security is sometimes set on the document level and sometimes acquired through a module which contains the actual document.

The security on a module should not be basically acquired from the security on the parent of the module. The parent is usually a portal object (i.e. an ERP5 Site) and the permissions should be different for each module on the site. For example, because a portal can be viewed even by Anonymous in parts to make it possible to login via a web interface for example. In addition, each module may have local roles which are independent of global 5A roles set on the portal.

The details about how to set up permissions depends on the policy of a specific ERP5 site and module. In general for module-level security, the following principles apply:

  • All permissions to read data should be enabled for all 5A roles. This is fine, because document-level security determines whether a user can view a document eventually.
  • Permissions to write data must be set up carefully. For example, allowing to Add portal content should be enabled only for Assignee and Author, because the other roles should not be allowed to create new documents.
  • Managers should be allowed to do anything.

Workflow Permission Management

In document-level security permissions are managed by workflows. DC Workflows used in ERP5 support setting permissions based on the state of a document and they can limit who can trigger a given transition from one state to another (like changing a document from Draft to Published). Thus permissions for a document are configured by defining one or more workflows used for the document. For the permission settings in a workflow, you should at least consider these permissions:

  • Access contents information
  • Modify portal content
  • View

Access contents information is basically the same as "View". This should be enabled for Assignee, Assignor, Associate and Auditor but not for Author, because the Author may not view documents by definition. Also, you can enable these permissions for Owner so that Author can view the documents only if the documents are created by the Author.

Modify portal content should be allowed for Assignee, Assignor, and optionally for Owner. But even if you want to allow the Owner to modify documents, you should not allow this in some states such as stopped in Accounting Transactions, because changing validated transactions is illegal. The same principle can be applied to Assignor, because closed Accounting Transactions should not be modified by anyone.

Permissions must be set for transitions, too. They are used to change the state of a document, so this is a type of modification of an existing documents. You can define who can perform a transition by specifying required roles.

Case Study: Accounting

In accounting, security is extremely important because of the legal requirments usually stating that only qualified people (i.e. accountants) may validate accounting transactions. In the following example we see how to set up the security permissions for accounting.

The 5A roles are considered like this in accounting:

  • Author - All users who can create drafts of accounting transactions. Maybe including sales people.
  • Auditor - All users who can view accounting transactions. If a company is lenient, you can allow all users in your company to see everything.
  • Assignor - This is the accountant(s).
  • Assignee - Assistant(s) for accountant(s).
  • Associate - This might be useful, if you generate accounting transactions from other documents, such as Sale Packing List.

Initially the accounting module defines who can view the module itself, who can create new documents, who may delete documents, etc. Basically, all 5A roles must be able to look at the module. The following would be a desired security configuration:

  • Acquisition is completely disabled
  • Manager can do all
  • Author, Auditor, Assignor, Assignee and Associate are permitted to:
    • Access Transient Objects
    • Access contents information
    • Access session data
    • List folder contents
    • View
    • View History
  • Author and Assignor are permitted to add portal content
  • Assignor can do these:
    • Copy
    • Move
    • Delete objects
    • Modify portal content
  • The other roles (such as Anonymous) cannot do anything

After this configuration is made, the workflow accounting_workflow needs to be setup. This workflow is used for all portal types based on accounting transactions (Pay Sheet Transaction, Purchase Invoice Transaction, etc). We will use another example to demonstrate setting permission on a workflow.

Case Study: Web Publishing

Implementing a security systems requires to design it first, specifically:

  • defining rules stating who is authorized to do what under which conditions (this is a managerial decision)
  • translating these rules into ERP5 vocabulary

Defining Rules

The first step usually results in a long text, describing the task of certain people and various security restrictions in great detail. For example, assume company X 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. A 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.

Translating Rules to Roles

From the first phase we can see that there are five "categories" of people involved:

  • Employed in the company
  • Working in the same department as the author
  • Department's boss
  • Management
  • Working in other departments

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

What tasks are these four groups supposed to perform in relation to a publishable article?

  • Employed in the company => create a new article
  • Working in the same department as the author => cooperate on writing the article
  • Department Boss => approves articles
  • Management => monitors publication activities
  • Working in other departments => nothing to do

When we translate this into the 5A roles, it fits nicely:

  • Employed in the company => create a new article => Author
  • Working in the same department as the author => cooperate on writing the article => Assignee
  • Department Boss => approves articles => Assignor
  • Management => monitors publication activities => => Auditor
  • Working in other departments => nothing to do

This information is sufficient to define security scripts and role definitions. Here we are talking about their design.

Workflow Security

When we read the security set on a document, we see that a document is first created, 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 encorporates states and transitions. From security standpoint, 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)

Explanation: we don't have "V" to Assignor in draft or submitted states, 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 itself, so it is not used in a workflow.

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

  • submit | draft => submitted | Assignee (VM), Auditor (V)
  • submitted | submitted => published | Assignee(V), Assignor (M), Auditor (V)
  • reject | submitted => draft | Assignor (M)
  • published | published => draft | Anonymous (V)

And this is it - a security regulations which took so long to describe now fits in three small tables. And this is just enough information for an application developer to sit down and implement the whole process.

Resources

Additional information can be found here:

Related Articles