The following terms form a security model in QueWeb 3.0
1. | Permissions – define QueWeb objects’ access rights and other privileges. |
There are two types of Permissions: Object Access Right permissions and Application Specific functional permissions.
2. | Object Access Right permissions can be applied to the following QueWeb objects: |
3. | The following objects can be granted Permissions: |
• | Security Role – specifies the business domain of the Users. Examples are: Call Takers, Email Handlers, Email Administrators, QueWeb System Administrators. Basically, Security Role is defined as a set or collection of Permissions which combines Access Rights and GUI elements on a set that can be assigned to Workgroups or individuals. |
Security Roles can be further assigned to:
o | User accounts – individual Users’ accounts that can access QueWeb. All employee and customer Users should have a QueWeb account in order to access the system. |
o | Workgroups – used for grouping individual Users. |
The following diagram shows relationships between all objects in the QueWeb’s security architecture:

Permissions are assigned to Roles. Roles can be assigned to Workgroups (recommended) or to individual User accounts (in rare cases). Individual User accounts can be organized into Workgroups.
If a User belongs to several Workgroups or has several Roles assigned to his/her individual User account, the system will combine the effective permissions from all Roles, Workgroups and individual account permissions into a single set of Permissions. In this set the “allow” will take prevalence over “deny”. This effective set of permissions will be used ONLY for the current session; at each login the set of permissions will be created for the duration of each session. If User’s permissions change at any level (Role, WG or Account) the User will have to logout and log back in to allow the system to generate a new set of active Permissions.
In order to determine User’s Rights during the login process the QueWeb System creates a set of active permissions for the session. In order to create this set it first combines all Permissions for each Object level (Roles and Workgroup levels) that are linked to an individual account and after that will narrow down Permissions from Roles level to the Account level so that Permissions on the level closer to Account will override those above.
In order to make complex security architecture easily manageable in QueWeb there is no option to explicitly deny permissions for the objects. If the Permission is not defined for security object (Role, WG or Account) – a default state – it means that the corresponding permission is denied. So if, for example, an individual User must be denied access to a Form while other Users in his/her Workgroup must have access – in order to accomplish this you must remove the User from a current Workgroup, create a new Role and explicitly assign the User to this Role.
The best practices procedure is to create security Access Rights in terms of Roles and defining them on a per-User activity basis. E.g. Call Takers Role, Email Handlers, Email Administrators. The goal for Security Administrator should be creating Roles for a specific set of User activities and avoiding overlaps between such activities as much as possible.
Several Roles can be assigned to workgroups or individual accounts and this will allow even more flexible management of access to different modules of the application. Such approach allows building solid and comprehensive access control list where Users are assigned to Permissions through Roles and such Roles are created based on business needs and typical User responsibilities.
All available Permissions can be divided into two categories:
1. | Access Rights – define access permissions for QueWeb UI objects: Focuses, Sub-focuses, Tabs and Forms. |
2. | Functional Permissions – define what actions in the application Users are allowed to do. E.g. assign cases, become owners of the cases, approve change requests, etc. |
|