Invantive EstateThis chapter contains information about the functions that are used to establish the access rights of users. These functions are normally used by the person appointed within the organization to ensure that the provided functionality is set up in such a way that it fits best the requirements and the needs of the user.
Invantive Estate is an application that stores information that may not be publicly accessible. For this reason a user first has to log in via the screen Start up and Login to get access. The check that a user is who he claims to be is called ‘authentication’.
Authentication
Authentication consists of validating the identity of the user of the application. A familiar example is making a withdrawal at an ATM. which requires a piece of knowledge (PIN-code) and a piece of possession (bank card). Another example is entering your own house. which requires solely a piece of possession (the key to the house). Invantive Estate belongs to the category of applications that (by default) solely uses knowledge to identify the user. The user gets access to the application with a password.
The authentication data of a user can be stored via the screen Persons.
Authentication by LDAP or Microsoft Active Directory
You can perform authentication through an LDAP directory or Microsoft Active Directory. In order to do this, you need to upload the following settings in the file site.properties, see Site.properties.
Authorisation for projects
The application contains a structure to grant certain groups of users access to only certain projects.
A project within Invantive Estate consists of an extensive amount of data, like budgets, processes, adjustments, invoices, orders and revenues. Access to all data related to a project is secured. To give a user access to the data of a given project, explicit rights should be granted to the user (the so-called UBAC, User Based Access). This can be done with the screen Project Authorisations. The rights can be read-only or write/read. Moreover, you can grant certain users read and/or write access to all projects. This will usually be the case for the application administrator. Also the person who uploads new projects will get complete access to all projects, in order to prevent the creation of a chicken egg problem (you can only grant rights to a project if it exists).
If a user has no rights to add, change or delete data in a screen, the buttons ‘Add’, ‘Change’ and ‘Delete’ will not appear in that screen when the user opens it.
The rights of a user on projects can be registered with the screens Settings, Roles, User Roles and Project Authorisations.
Authorization for screens, reports and documents
The application contains a structure to grant certain groups of people access to only certain parts of the application. This is called the authorisation structure. Most privileges are granted based upon the role of a user (so-called RBAC, Role Based Access). A user can have multiple roles at the same time. In that case the total rights of the user are the sum of the rights attached to the roles given to the user.
The rights of a user on screens, reports and documents can be registered with the screens Roles, Role Authorisations and User Roles.
For example, if you would like to see the contents of documents in the screen Budgets, the function ‘Access to documents of Budget’ in Role Authorisations should be assigned to you.
If you want to change a document and then upload it, also editing rights need to be assigned to you in the screen Role Authorisations.
