Projects:Security Review/Functional Specifications

Contents 1 Security Review - Functional Specifications 1.1 Overview 1.1.1 Purpose 1.1.2 Scope 1.1.3 Concepts 1.2 Functional Requirements 1.2.1 User roles & profiles 1.2.2 User stories 1.2.2.1 Audit 1.2.2.2 Other issues 1.2.3 Design Principles for organization filtering and validation policy 1.2.4 Issues and not clear requirements 1.2.5 Conclusion 1.2.6 Functional requirements 1.2.6.1 1st iteration 1.2.6.2 2nd Iteration: Postponed to 2.50 release (a complete enterprise model should be previously finished) 1.2.7 Functional requirements based on business processes 1.2.7.1 Data filtering 1.2.7.2 Access levels 1.2.7.2.1 Data access level 1.2.7.2.2 User level 1.2.7.3 Audit 1.2.7.4 Other issues

Security Review - Functional Specifications

Overview

Purpose

• Multi-client and multi-organization operation should be secured. The Enterprise model -work in progress- is required to define security policies in a multi-client and multi-org operation. Multi-client security policy is completely defined (absolutly isolated client operation) while multi-org operation is not so clear.
• The priority objective for the Security review project is to allow a secure multi-client operation in a SaaS environment and it has been reached (still some manual windows pending for review). It means that the backend checks in all requests that the user is allowed to see, insert, modify or delete that information. Be aware that there are still a security flaw: referenced data is not validated from a multi-client perspective. A user might hack a request to save an order in his client (this is guaranteed by the system) but referencing to a customer in a different client which is not allowed to him just by editing the customerID in the request. Through this flaw a security attack could be done. This validation is not planned for the 2.40 release (should we consider it?).
• As a secondary objective the project aims to review the organization filtering and validation policy to fit multi-organization operation.

Scope

This specifications covers:

• Data filtering
• Audit
• Other issues

Concepts

• Fine grained security systems consist of "Vertical Security" and "Horizontal Security". Vertical security is related to manage access to data entities (Window Access, Table Access, Process Access, etc.). Horizontal security is related to manage access to subsets of data within those entities. In this document only horizontal security (organization filtering and validation) is discussed.
• Organization tree: organization structure according to business necessities. For example (this tree will be used in the examples below):

         0 * (all orgs)
               - A
                 - A1
                 - A2
               - B
                 - B1
                 - B2

• All records of data are assigned to an organization
• All users (though roles) are assigned to one or more organizations. The list of organizations assigned to a user is called the user orgList.
• The standard tree of an org consist of the org itself and all its descendants and all its ancestors. Eg. organizations in the standard tree of B are *, B, B1 and B2
• Data access right: privilege granted to a user to see that data (reminder: only horizontal security is discussed here)
• Data edition right: privilege granted to a user to modify that data
• Data references: link from one record of data to other record. To fully understand the info in the first record is required to see info in the second one (at least the description). The second record migth have other link to a third record (2nd level reference), and so forth (3rd level reference,...,n level reference). Through these data links the information is structured as a web

Functional Requirements

User roles & profiles

This specification applies to all roles

User stories

Let's define the following organization tree:

*
|-A
|-B
  |-B1
  | |-B11
  | |-B12
  |-B2
    |-B21

A Role1 with explicit access to organization B1, and B21.

Role1 can:

1. Edit and create data (for example invoices) in organizations B1 and B21. If he tries to save info in another org an error message will be shown.
2. See information for transactional tables (those with Organization access level) defined in the granted organizations and in all their ancestors and descendants (B, B1, B2 and B21) in this case * would not be accessible because it is not possible to insert data in * for transactional tables.
3. See information for non-transactional tables defined in the granted organizations and in all of it ancestors (including * in case it is applicable).
4. When Role1 is editing an invoice in a granted organization (let's say B1) he can reference transactional information (for example an order) defined in the current organization (B1) and all its ancestors and descendants (B, B1, B11, B12). This rule is the same as #2 but applied to the current organization (B1).
5. When Role1 is edition an invoice in a granted organization (let's say B1) he can reference non-transactional data (for example a business partner) defined in the current organization (B1) and all its ancestors (*, B, B1). This rule is the same as #3 but applied to the current organization (B1).

Audit

When this user navigates by all its accessible data he is able to know who and when each record was created and who and when did the last modification.

This information appears in the bottom of every tab, but he can hide setting a global variable to "not show audit" which will change the behavior for all the tabs in the application; the other way to hide/show this info is clicking a new button in the toolbar which will hide this info just for the current tab.

When this information is shown it appears in edition mode and in relation mode and these fields will be usable in the filters.

Other issues

• Be able to have access to session information window (in order to, for example, change log status) but not to session values.

Design Principles for organization filtering and validation policy

1. The main goal regarding organization -filtering and validation- policy is to create isolated and consistent subsets of data within an Openbravo Systems mapping the organization hierarchy of a company while allowing consistent data sharing between them. Users are allowed to work on one or more of those datasets. For example, a company with two organizations, A and B. The system should provide mechanisms to completely isolate activities in both organizations, so a user in the organization A does not know about activities in the organization B and viceversa. Some data (eg. some common products info) could be shared between both to improve data maintenance and analysis capabilities.
2. The organization policy (filtering and validation) should be:
   1. Simple and easy to understand: the configuration of the security should be simple and predictable. A user without technical background should be able to setup the security without complex analysis.
   2. Robust and thorought: the system should guarantee that a user can not access data without proper privileges. The system should guarantee data consistency (eg. consistency would be compromised if a user is allowed to access an Order header but not its lines)
   3. To get the two previous principles (simplicity and thoroughness) horizontal security should be configured independently from vertical security while consistency is guaranteed.
   4. Rich to implement any possible functional requirement.
   5. Wide: It must not prevent to share data between organizations when it is requiered from functional specification.
   6. Users should be allowed to access data that is referenced by data accessible by them. If not consistency would be compromised. (reminder: only horizontal security is discussed here. Of course the user might be prevented to access data by vertical security mechanisms). So the system should guarantee that referenced data (1st tier, ..., n-tier) is accessible to guarantee consistency.

Issues and not clear requirements

• After exploring different functional requirements the conclusion is that no general restriction regarding organization can be applied to data reference, no matter what type of information (master or transactional) is referenced. All this cases should be allowed:
  • Reference to a master ancestor: an order in org A can reference to a customer in org *.
  • Reference to a master descendant: an order line in org A can reference to a product in org A1 (Org A is a head sales office that entries orders for A1 and A2 orgs which are in charge of product definition and maintenance)
  • Reference to a transactional ancestor: a shipment in A1 references to an order in A (orders in A are prepared and delivered from suborgs A1 and A2)
  • Reference to a transactional descendant: an invoice in A references to shipments in A1 and A2 (centralized invoicing)
• There is no general rule about how to share data. All this cases should be allowed:
  • A user can access to data in his organization and in its ancestors (the natural way of data sharing for master data, such us previous case 1) and/or in its descendants (such us previous case 2).
  • A user is only allowed to access data in his organization, without any kind of sharing from ancestors or descendants (eg. confidencial info such as salary of employees).
• Neither is there a general rule about how to share data for a particular data entity (table). Eg. product info might be shared in different ways depending on Customer requirements
• The result of a process should only depend on explicit inputs to the process (to make it easier to understand). It should be independent from horizontal security. If a kind of organization filtering is required within the process body the organization should be an explicit input to the process. Horizontal security will validate that the organization provided by the user is allowed to him (***it requires confirmation!!!)

Conclusion

There is no way to get all design principles: isolated data subsets by orgs, support to any functional requirement of data sharing and data consistency. These two principles are in conflict. Eg. if a user in the organization A is able to create an Invoice in organization A with lines linked to shipments in A1 and A2 orgs (case 4), and a user in organization A1 should be able to access information of how A1 shipments have been invoiced, he should be allowed to access to invoices in A. If he is allowed to access all lines (including the ones related to A2 shipments) then isolation would be compromised. An if he is only allowed to access lines related to A1 then data consistency would be compromised (the invoice should be treated as unit).

Functional requirements

1st iteration

• Complete review for multi-client operation in manual code. Do not Include client validation for referenced data
  • Wad windows:
    • Users will be allowed to access to any record in the standard tree of his orgList (minimum access restriction).
    • Users will be allowed to edit any record in his orgList (so ancestors and descendants without explicit orgList privilege will not be editable)
    • Directly (first level) referenced records will be forced to be in the standard tree of the referencing organization. N-level references might be from any to any organization. It will cause:
      • Isolation by org will not be guaranteed by the security system (no way to have isolated data subsets in a web of data without reference restrictions). It is not a regression (the same problem is present in 2.3x).
      • Unpredictable behaviour might arise in some odd cases. Eg. customer in org * has a pricelist in organization B. A user in organization A creates an order in organization A using that customer. The callout will try to set the order pricelist to the customer pricelist in organization B. It will fail because that pricelist is not allowed (reference from an order in A to a pricelist in B is not allowed). A complete code review (out of scope for 2.40 release) is required to ensure that error is properly communicated to the user. It is not a regression (the same problem is present in 2.3x).
• Manual code: no change will be done except for selectors (to be able to close the project before april 4th). Reports, processes, callouts, ... will work in the same way that they do in 2.3x: only records in the orgList will be shown. During the alpha phase some manual code might be modified to apply the new policy.
• Selectors will be modified to show information in the standard tree of the user orgList.

2nd Iteration: Postponed to 2.50 release (a complete enterprise model should be previously finished)

• Client validation for referenced data
• Manual code review (to be done by product development team):
  • Callouts need to be reviewed to apply (if necessary) horizontal security filtering and to communicate eventual errors caused by the horizontal security policy.
  • Drop-down lists and selectors in filters for reports will shown all accessible data (standard tree of the user orgList)
  • Reports output will shown all accessible data (standard tree of the user orgList)
  • Processes need to be reviewed to apply (if necessary) horizontal security filtering. General accounting processes are organization independent and are not filtered by horizontal security policies.
  • Inputs to processes need to be reviewed to apply horizontal security filtering. Cases to be defined/confirmed:
    • Invoicing process: only organizations in the orgList are allowed to be invoiced. Organization is a mandatory input for the process.
    • Invoicing process: all accessible customers (in the standard tree of the user orgList) are allowed to be invoiced.
    • Create shipments from orders (in general, create/copy documents from documents): only orders in the orgList are allowed to be selected (since the process will modify the order itself
    • ...

Functional requirements based on business processes

Data filtering

Requirement	Importance	Status	Estimated time
Add access filters to WAD windows: standard OrgList.	Must have	Complete	0.5d
Add edition filter to WAD windows: role's OrgList and * in case it is applicable.	Must have	Complete	1d
Difference organization combo when the record is editable and when it is not: when it is editable it should be loaded just with the writeable organizations when it is not it could just contain the current value.	Should have	Complete	1.5d
Add reference filter to WAD windows: standard OrgList for the current record organization.	Must have	Complete	0.5d
Review manual code to ensure it is correctly using filter for client.	Must have	In progress	3d
Modify selectors in order to show information in the standard tree of the user OrgList.	Must have	In progress -> This tasks will be accomplished within the ajax grids project	1.5d
Add filters to linked items, and in case it is not accessible show a message.	Must have	Complete	1d
Revert this changes: Add the possibility to log into any of the implicitly accessible organizations, currently it is possible to log into the explicitly granted.	Must have	Complete	0.5d
Implement read only logic for columns. When the logic is true the associated fields will not be editable and when it is false (and if it is in a editable window) it will be editable.	Should have	Complete	N/A
Implement read only for tables (one role can access to a table but cannot write on it). This development can be divided into two stages: Functionality. Perform the required checks in order to allow or not to write. Currently the method Utility.canUpdate exists but it seems to be used only in Field Sequence window. It should be used in every one. Interface. Once it works functionally another enhancement would be to show the window fields as non-editable and not to show the save buttons in the toolbar if the role doesn't have write permission.	1st stage: Should have 2nd stage: Nice to have	1st stage: Complete 2nd stage: Complete	1st stage: 2d 2nd stage: 2d
Do the same implementation (in 2 stages) for Window -> Write access.	1st stage: Should have 2nd stage: Nice to have	1st stage: Complete 2nd stage: Complete	1st stage: 2d 2nd stage: 2d
As data access level is going to be reviewed, a revision of which access level has every table must be performed to ensure each table is in the level it should be in.	Must have	to be started	2d
Create an All user level.	Nice to have	to be started Previously to this task it must be ensured that this kind of level will not cause any problem to the current implementation of user levels and data access levels. The main point here is to check how sequences are given depending on the client.	1d
When organization and client list are calculated take into account user and access levels to ensure that those levels which are forced to access only to 0 don't have access to other ones.	Must have	Complete	4h
Add backend control for processes. When a process is going to be launched in a non-editable record, the backend should guarantee it is not possible (now it is done by the interface). Due to technical limitation this is going to be developed for automatically generated buttons, the manual ones which do no post to the main servlet only be checked by interface.	Nice to have	Complete	0.5d

Access levels

Access levels must be reviewed.

Data access level

Defines how information is shared between different clients and organizations. It is defined in tables.

	Client	Org
System	0	*
System/Client	Any	*
Organization	No 0	No *
Client/Organization	No 0	Any
All	Any	Any

User level

Defines which clients and organizations can be accessed. It is defined for roles.

	Client	Org
System	0	*
Client	No 0	*
Organization	No 0	No *
Client + Organization	No 0	Any
All This is a new level which should be added in case it does not generate any problem with the current implementation.	Any	Any

Audit

Requirement	Importance	Status	Estimated time
Insert audit fields in all WAD windows in edition mode	Must have	Complete	N/A
Insert audit fields in WAD windows in relation mode	Should have	Complete	4h
Add audit fields to filters (in WAD windows) in case they are shown.	Nice to have	Complete	1d
Create new button in the toolbar to show/hide audit info. An implement its usage.	Nice to have	Complete	1.5d
Add manageability of this element using window preferences in order to be able to set a window to show or hide by default this info regardless the global configuration.	Nice to have	Complete	0.5d

Other issues

Requirement	Importance	Status	Estimated time
Separate session info and session values windows	Must have	Complete	N/A
Make possible not to have access to different selectors. Access for selectors is calculated based on the access where it appears: in case it appears in at least one accessible tab it will be accessible, otherwise it will be not.	Must have	Complete	3d
When the password for a new user which has not already been saved is tried to be changed, it is not changed for that user but for the user who has logged into the application. It should not allow this behavior, instead it should show an error message in this case. Related bug	Must have	Complete	N/A
Have different DB log capabilities (deleted records, any change...). This log shouldn't be just a text-plain file but historical tables in DB containing the whole change history for every single record. http://sourceforge.net/tracker/index.php?func=detail&aid=1853840&group_id=162271&atid=823132 http://sourceforge.net/tracker/index.php?func=detail&aid=1853844&group_id=162271&atid=823132 One possible approach could be the creation of a new table containing the logging level for every table in the system. When the log level is not 0 a process would create a table for the log and a trigger that would be launched depending on the log level. If this is done we should be able to maintain the historical values although the table structure is altered.	Nice to have	Postponed