This documents the basic 5A security model in ERP5 and how to apply the model to a real implementation such as Accounting. Caution: This is still in a draft state. Need to add more text and fix the issue of Z SQL Method. ('Yoshinori Okuji',) ERP5 5A Security Model text/html None yo en None 2004-12-02 00:13:03 2004-08-27 13:54:41 () 0 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":http://zope.org/Documentation/Books/ZopeBook/2_6Edition/Security.stx - "The chapter Security in the Zope Developer's Guide":http://zope.org/Documentation/Books/ZDG/current/Security.stx - "NuxUserGroups":http://www.zope.org/Members/nuxeo/Products/NuxUserGroups/ normal stx normal html