In the Security Model section, we will examine the following topics:
Security is a concern when more than one user will be accessing and modifying a database. Multiple users may simultaneously open a database with multi-user access, or one at a time or with single-user access. It makes no difference. In either case you will want to control each user's access rights, and track each user's actions in the audit trail.
This section should be read by the database administrator, the person given the primary responsibility for adding users and granting their access rights.
NewViews security is controlled by granting access rights to users. Each user has an access table. You grant the user access rights by adding rows to this table and attaching each row to a database object, thus granting access to that database object. The access table is called Access Tos in window lists because it is used to grant a user access to various parts of the database.
By itself, this technique would mean connecting a lot of access rows because there are so many objects in a typical database. But when access is granted to an object, say ACCOUNT/AR, access is also automatically granted to all objects below it. Since all customer accounts are below the ACCOUNT/AR account, granting access to ACCOUNT/AR also grants access to all customer accounts.
The same technique works throughout a database. You can grant access in a very narrow manner. For example, you could attach an access row to a specific journal such as JOURNAL/PURCHASE/PO, to grant access to the purchase order journal. Or you could grant access in a wider manner. By attaching an access row to JOURNAL/PURCHASE, you grant access not only to the purchase order journal, but also to any other sub-journals below JOURNAL/PURCHASE, which would include the purchase invoice journal as well.
There is no limit to how widely access can be granted. You can grant access to all journals by attaching to /OBJECT/NEWVIEWS/JOURNAL, the root journal, or grant access to all accounts by attaching to /OBJECT/NEWVIEWS/ACCOUNT, the root account. In the extreme, you can grant access to the root object, which actually grants access to the entire database. Having said that, there is indeed a limit to how widely access can be granted, but that limit is the entire database.
There is no limit to how narrowly access can be granted. You could, for example, attach access rows to individual accounts. A user might therefore be restricted to work on a specific bank account, or a few selected customer accounts for which the user is responsible. Theoretically, you can even grant access to individual transactions such as invoices. However, this would rarely by done in practice and we mention it only to make a point and to help you understand the security model.
The user with the name ADMINISTRATOR is special for the following reasons:
The administrator is added automatically.
When you create a new database the administrator is added automatically. Otherwise there would be no users at all and therefore no way to access to the database. The administrator is added with an empty password so after creating a new database one of the first things you should do is set the administrator password.
The administrator is granted access to the root object.
One row is automatically added to the administrator access table, and this row is attached to the root object of the database. This grants the administrator access to the entire database because all other objects are below the root object.
You cannot change the administrator's access rights.
You cannot change or delete the administrator's single access table row, or add new rows to the administrator's access table. Nor can you change the administrator's name. Regardless of what rights are granted to other users, it is essential that at least one user have access to the entire database and that user is the administrator. Otherwise it would be possible to lock yourself out of the database.
Only the administrator can change the administrator password.
In general, any user who has been granted access to a user object can change fields in that user, including the password. The administrator is a special case. No user other than the administrator can change the administrator password, even if they have been granted access rights to the administrator user object.
When adding access rows for a user, you may be allowed to select the root object. Suppose you attach an access row of user WHITE to the root object. Be aware that WHITE will have rights to the entire database if you do this, exactly like the administrator. The only differences between WHITE and the administrator are that WHITE's rights can be taken away again by deleting or changing WHITE's access table rows, and WHITE's password can be changed by anyone with access rights to the WHITE's user object.
The granting of access to users should be consistent with your own internal control requirements. Internal controls are in general beyond the scope of this documentation in any advisory role. However, as we describe various security examples, we may point out from time-to-time, how the granting of access could relate to internal control requirements. Be aware that any such comments are for illustration only, and are not intended to be advisory.
When the administrator opens a database, the left pane is the main explorer tree which is based on the root object. When the administrator activates any folder in the explorer tree, the right pane displays more detailed information about the selected folder. Because the explorer tree is based on the root object, the administrator can explore anything in the database.
Regular users, meaning anyone but the administrator, can only view those parts of the database to which they have been granted access. Suppose WHITE is a regular user in a database. When WHITE logs into the database, WHITE's left pane will be a table instead of a tree, and the table will have one row for each object to which WHITE was granted access. When WHITE positions on a row, the right pane will be restricted to the object and anything below that object. For example, if WHITE has been granted access to the ACCOUNT/AP then there will be a row for vendor accounts in the left pane. WHITE can position on that row and details about vendors, but nothing else, can be explored in the right pane.
In the examples of user access rights, see Sample User Access Rights, we grant users access to various accounting objects such as accounts and journals. The example access table for purchase clerk SMITH is shown in the table below.
| Line | User Name | Object Name | Object Description | Access To=> | Folder |
| 1 | SMITH | AP | Accounts Payable | /OBJECT/NEWVIEWS/ACCOUNT/AP | folder |
| 2 | SMITH | PURCHASE | Purchase | /OBJECT/NEWVIEWS/JOURNAL/PURCHASE | folder |
SMITH was granted access to vendor accounts and purchase journals. But for internal reasons, SMITH also needs access to the SMITH user object so that SMITH's password and user options can be accessed. These fields are needed internally when SMITH logs in and works on the database. So we have added a third row to SMITH as shown below, granting access to SMITH's own user object.
| Line | User Name | Object Name | Object Description | Access To=> | Folder |
| 1 | SMITH | AP | Accounts Payable | /OBJECT/NEWVIEWS/ACCOUNT/AP | folder |
| 2 | SMITH | PURCHASE | Purchase | /OBJECT/NEWVIEWS/JOURNAL/PURCHASE | folder |
| 3 | SMITH | SMITH | John H. Smith | /OBJECT/NEWVIEWS/SYSTEM/USER/SMITH | file |
This third row grants SMITH internal access to the USER/SMITH user object. The access is internal because the Folder field at the right end of the row has been set to file, not folder like the other rows. If you do not add a row granting access to the user object when you set up and access table, one will be added automatically, just as shown above, the first time the user, in this case SMITH, logs into the database. So you actually do not need to add it at all.
When the Folder field is set to file, the user's window system will not allow the user to view the object or anything below it (unless given access independently through a different access row). What this means is the case of SMITH is that SMITH will not be able to see SMITH's own user object or edit its contents. The access is internal only, so that the user options can be accessed internally while SMITH operates on the database, but SMITH cannot access and change the SMITH user object. The main explorer in the left pane will not have a row for SMITH's user object when SMITH logs in and therefore SMITH will not see the SMITH user object. You have to set the field to folder for that to happen.
As the administrator you decide whether SMITH, or any user, should be able to access and change their own user object. If you want to allow SMITH access to the SMITH user object, change the Folder field from file to folder on the access row that grants rights to the user object. You can revoke this right just as easily by changing the Folder field back to file.
If you grant SMITH access to the SMITH user object then SMITH will be able to change SMITH's own options. Some of the options are options that you, as the administrator, might not want SMITH to change. For example, SMITH would be able to change edit dates that restrict transaction activity to a particular date range. SMITH could turn off the edit reconcile safety which prevents the inadvertent editing of reconciled transactions. Smith could change SMITH's password and turn on the ability to view SMITH's own audit records and access information. See Setting User Options.
Whether or not you grant a user such as SMITH access will depend on whether or not you want SMITH to have these abilities. Note, however, that granting SMITH access to SMITH's user object will not give SMITH any additional privileges not explicitly granted through the access table. For example, SMITH will only be able to view audit records for transactions that SMITH already has access to.
A user's access rights can be changed at any time except when the user is currently logged in. You can revoke access rights by deleting rows from the access table. You can grant new access rights by adding new rows. You can change existing access rights by re-attaching rows to different objects.
Suppose you, the administrator, want to prevent user SMITH from accessing a database in the future. You cannot just delete SMITH because SMITH will likely have a history of sessions, audit records, and so on, and this history cannot be thrown away. But there are ways you can keep the user from accessing the database:
Change the user's password.
As the administrator you can access all user objects. Position on the user folder in your explorer tree and switch the right pane to the Users Explorer. You can position on the password field of any user and change it, effectively locking the user out of the database. Note, do not clear the password because that will have the opposite effect.
Delete all rows from the user's access table.
This will deny the user access to the database.
Suppose you have a multi-user database and you have an emergency situation. Say SMITH is a very bad user and SMITH is currently logged in. You must get rid of SMITH immediately; there are several courses of action. The most drastic action is to shut the server down, either by shutting the program, terminating the process, or pulling the plug. But a less drastic action is to delete the SMITH's connection from the server's connection table. Then immediately change SMITH's password before SMITH can attempt to re-connect. This action will let you kick out a user without interrupting database service to other users.
In the previous examples we granted access to such objects as the root vendor account, or the root purchase journal. By doing so we granted access to all objects below the selected objects. Experience shows that this technique covers a wide range of security requirements. However, the security model is general in nature and is capable of granting access to suit a wide range of security requirements. For example:
Granting access to a report.
When you grant access to a report object, you automatically grant access to all accounts on that report. These accounts are below the report and inherit its access. You therefore have an unlimited ability to organize accounts on reports according to your internal control requirements. This is rarely necessary but it can handle special situations where the account class hierarchy does not address your security needs.
Granting access to a total account.
When you grant access to a total account, you automatically grant access to all accounts that total to it, directly or indirectly. These accounts are below the total account and inherit its access. You therefore have an unlimited ability to organize accounts in their total structure according to your internal control requirements. Like using reports, the use of the total structure is rarely necessary but it can address special situations.
Experience shows that the security model as described above is sufficient for any internal control requirements encountered to date. However, the NV2 security model is actually more advanced than the documentation above would indicate.
Built into the security model is the ability to restrict access on a field-by-field basis, and on an operation-by-operation basis. What this means is that operations such as the creation, modification, and deletion of objects can be controlled separately. Also, the ability to access and/or change individual fields, while restricting changes to other fields on the same or other objects, can be individually controlled in a custom manner.
These advanced features are entirely consistent with the security model as described above. They are possible because the access objects are actually intelligent, meaning configurable and programmable. We have not exposed this functionality in the current release of NV2 since we have not encountered situations where this functionality is necessary. We would like to keep security as simple as possible and not expose additional functionality until it is needed. Nevertheless, you should be aware that such extended functionality exists in the security model.