Introduction

Security is essential in most companies, because each person should not be able to do what the person should not do. An example is that only qualified accountants should be able to validate accounting transactions, because this is a legal procedure. Another one is that an ordinary worker should not be allowed to make a new purchase order or modify exisiting orders without approval by a manager.

This means that we need a certain way to prevent 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 could be a nightmare, because if you have 100 workers in your company, you must set up permissions 100 times.

Zope addresses this question by roles. For example, if your company has two accountants, it would be a good idea to make a role called Accountants and set up permissions for the role Accountants instead of specifying permissions for the two accountants separately. This reduces the number of permissions that you must set up dramatically and this makes the cost of maintenance much cheaper.

This role-based security is, however, still hard to maintain, if you have many modules in ERP5. Suppose that you have two modules for sale orders and accounting transactions. In these modules, probably you will define the roles Sale Manager and Accounting Manager so that some restricted people can make final decisions or legally important jobs. And, you will need more roles for ordinary workers, such as Accountant and Sale Assistant. The number of roles grows up as you add a new module into ERP5. If you have 20 modules, the number can become over 40. In this case, you must maintain the big table of permissions, because the size of the table is determined by the number of permissions times the number of roles. Even worse, this makes things complex, because Sale Manager is a completely independent role of Accounting Manager.

ERP5 reduces the number of roles significantly and provides a clear vision of the security system thanks to the 5A security model. 5A stands for Author, Auditor, Assignor, Assignee and Associate. These are roles which can be used to define permissions for users in a generic form, regardless of modules. Also, ERP5 uses some built-in roles in Zope such as Owner.

5A Security Model

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

Here we describe what each generic role means:

Author

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

Auditor

Auditor is allowed to view documents but not allowed to make or modify documents. Suppose sales people who should know all products in your company but not concerned with any new product design. In this case, they are auditors but not authors.

Assignor

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

Assignee

Assignee is one who can do all tasks under the control of Assignor. Assignee is used only if Assignor assigns a user to an assingee 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 in a certain document only when another document related to that document is assigned. This is a bit complex, so consider this situation: You are a new worker in a very strict company. Now you are dealing with a sale order so you need to know the customer. Because this company does not want you to look at other customers, the manager of this company must limit your access to information on customers with which you must deal. In other words, you are allowed to access a given customer only if any sale order assigned to you is related to the customer. This is the Associate.

Also, ERP5 uses the role 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 the 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 this is settings in a module, this does not distinguish documents. If you need to make difference among documents - like Assignee - then you must use document-level securiry.

On the other hand, 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 important in particular for Assignee and Associate. Document-level security is sometimes set at a document level and sometimes acquired from a module which contains this 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 very different from each module in the portal. That is, for example, because a portal can be viewed even by Anonymous in part to make it possible to login via a web interface. In additional, each module may have local roles which are independent of global roles set in the portal.

The details about how to set up permissions depends on the policy of your site / module. But this is the principle in module-level security:

• 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, Add portal content should be enabled only for Assignee and Author, because the other roles should not be allowed to create new documents.
• Manager should be allowed to do anything.

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 do a given transition of a state. So permissions for a document is configured by setting up one or more workflows used for the document precisely.

For the permission settings in a workflow, you should add at least these permissions:

• Access contents information
• Modify portal content
• View

"Access contents information" is basically the same as "View". So these should be enabled for Assignee, Assignor, Associate and Auditor but not for Author, because Author may not view documents by definition. Also, you can enable these permissions for Owner so that Author can view 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 Owner to modify documents, you should not allow that in some status, such as stopped in Accounting Transactions, because changing validated transactions is illegal. The same thing can be applied even to Assignor, because closed Accounting Transactions should not be modified by anyone.

Also, permissions must be set for transitions. Transitions are used to change the state of a document, so this is a kind of modification on existing documents. You can define who can do a transition by specifying required roles.

Case Study: Accounting

In accounting, security is extremely important, because of the laws that only qualified people (i.e. accountants) may validate accounting transactions. Here, we see how to set up the security 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 your company is not very strict, 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.

First, the module accounting defines who can view the module itself, who can make new documents, who can delete documents, and so on. Basically, all 5A roles must be able to look at the module. So these are the results:

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

Secondly, let's set up the workflow accounting_workflow. This workflow is used for all portal types based on accounting transactions (Pay Sheet Transaction, Purchase Invoice Transaction, etc). Here two things must be set up:

1. The permissions in each state
2. The required roles in each transition

TO BE WRITTEN...

Resources

• The chapter Users and Security in the Zope Book
• The chapter Security in the Zope Developer's Guide
• NuxUserGroups