wiki:Developer/KHIS2/SecurityModelDeveloper

KHIS 2.0 Security Model

The security model can be broken into two areas:

Data Security
Securing access to the core data, including read, write and summary access permissions.

Functionality Security
Securing access to functionality aspects of the application.

These areas are independant of each other, but in use may be both relevant to any permissions check. For example, access to update a company would rely on sufficient data access rights to that company in particular, and also sufficient functionality access rights to be able to modify companies in general.

Data Security

Each entity (company, project, contact, etc.) will have multiple access rights associated with it, each naming a data security object and an access level.

Possible data security objects linked to access rights are:

Security Object Description
Contact An individual user is explicitly given rights to access the entity.
Project All members of a named project team are given rights to access the entity.
Security Group All members of a named security group are given rights to access the entity.
Global This default level applies to all users.

Possible access levels are:

Access Level Description
Summary The user has rights to know of the existence of the entity and read it's core details, including the owner. They cannot access any history or attributes.
Read The user can has full access to read an entity's data, including the history and attributes. They cannot update any data.
Write The user has full access to modify an entity's core data, attributes and access rights.

Whenever an operation is performed on an entity, the access rights are checked to ensure that the current user has a corresponding access right defined, either directly or through an aggregate security object. The entity owner is assumed to have full write access to the entity, to avoid siutations where excessive access rights are removed.

Implementation

The data security needs to be implemented at the database level. This ensures that the same rules will apply to reporting users.

Each entity will have a table to store their access rights within the access schema. e.g. Contact access rights will be stored in access.contact_rights.

Whenever a new entity is created, it's rights will be populated with the default values defined in access.user_default_access_rights.

Each entity will have a scalar valued function that takes the entity reference as a parameter, along with the current user reference, and the required security level to check against. This will return a boolean informing of whether the user has this access level or not. e.g. Contact access rights can be checked using contact.fnCheckAccessRight(@pContactID, @pMyContact, @pSecurityLevel).

Each entity will also have a table valued function that takes the current user reference and a required security level, and will return a list of entity references that meet this restriction. This can be joined to any search results to ensure that only results that meet the restriction can be displayed. e.g. A list of accessible contact can be retrieved using access.fnGetContacts(@pMyContact, @pSecurityLevel).

These two security functions should be sufficient for most purposes. Any stored proc accessing entity data should use them where appropriate.

Functionality Security

Functionality Security can be implemented at the application level.

Last modified 2 years ago Last modified on 17 Sep 2015 10:07:22