View source | View content page | Page history | Printable version   
Toolbox
Main Page
Upload file
What links here
Recent changes
Help

PDF Books
Show collection (0 pages)
Collections help

Search

Projects:Security Review/Functional Specifications

Contents

Security Review - Functional Specifications

Overview

Purpose

Scope

This specifications covers:

Concepts

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

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

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

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
2nd Iteration: Postponed to 2.50 release (a complete enterprise model should be previously finished)

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

Retrieved from "http://wiki.openbravo.com/wiki/Projects:Security_Review/Functional_Specifications"

This page has been accessed 8,514 times. This page was last modified on 8 June 2012, at 05:30. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.