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¶