Authorisation

Authorisation in an application is needed in order to safeguard resources or functionalities against unwanted access. This is implemented by a system of rules which determine if a user is allowed to access a functionality or resource.

In the GRC Suite, authorisation is based on roles and role extensions which can be assigned to users, as summarized in section Roles and Role Extensions.

For any role which the user needs he or she always needs the respective container role extension in addition for the container which the user interface belongs to.

With regard to the Custom UI, there are three types of resources worthy of protection:

We differentiate between the last two types, because it should be possible that a certain group of users may be granted access to a certain user interface at all, but that only a sub group of them may be granted access to certain functions or elements within that user interface, depending on the underlying resources.

The access rules for a configuration area are explained in section Enter A Configuration Area and those for a user interface in section Enter A User Interface.

The authorisation of those functions or elements which expose TrackingOne functionality are determined by those rules which apply in TrackingOne, see section Workflow Start and Report.

For a Special Widget or a Table Editor the authorisation is customisable, see Special Widget and Table Editor.

The other elements are not safeguarded on a per-element basis.

Last but not least: We have to say something about how a selected element is safeguarded, i.e. what is the effect if the user has access to the user interface but not to the element: Authorisation and Visibility.