Opérational Parameters - Rights and Security Management
Introduction
This article describes the use of rights and security in NCS.
In the first part of the document, we will describe the logical structure and organization related to rights handling. This will give enough background for you to understand how rights must be used in order to successfully structure and configure your contact center.
The second part of the document will provide more practical example, mainly with screenshots. This will allow you to make the link between the theoretical aspects of the first section and the operational tasks needed to be applied in the administration tool.
Logical organization
Definitions
A few concepts must be defined when talking about rights. It is important to precisely describe every concept in order to agree on the vocabulary we are using.
Objects
When we talk about objects in this document, we refer to the items allowing a user to specify a contact center configuration in NCS. Objects types include campaigns, activities, users, phones, locations, etc.
Users
A user is obviously someone using the NCS platform. A user specifies multiple properties and is often identified by an account and a name. A user is obviously an object.
Actions
We define actions as something that can be performed by a user in the context of rights and security management. For example, an action can be starting an application or deleting some object in the administration interface.
Functionalities
Functionalities are the range of operations that can be run on the NCS platform. Typical functionalities are supervision, administration, reporting...
Rights
We define rights as sets of allowed and denied user actions related to functionalities in the context of an object. The concept seems complex but is easily understood with an example: the user “John Doe” can read administration data on campaign “JH Sales”. In this example, reading is the action while the functionality is the administration.
Roles
Roles are groups of users sharing the same rights and often the same purpose in the contact center. For example, “John Doe” has both administrator and supervisor roles. A role is an object, appearing in the administration interface.
Security contexts
Security contexts are administered objects allowing to associate rights to other objects. A security context can be shared between multiple objects.
We will now describe in detail the basic concepts we have just introduced.
Actions
The following actions are available in the administration interface:
- List: listing of administration objects (read objects description)
- Open: read object details, open an application
- Modify: update object details (update object)
- Create: create new objects
- Delete: delete objects
The actions, when combined in rights are allowed, denied or unspecified. Denying an action always has priority over allowing the action. For example, if a user can administrate queues by default, a queue with an explicit “Deny” will not be administrable.
To summarize, in order to allow an action, at least one “Allow” and no “Deny” must be related to the object. Whatever the number of “Allow” related to an object, if one “Deny” exists, it is enough to deny the action on the specific object.
To complete the behavior, a role defines a special attribute modifying the rights evaluation. This attribute is the “Not allowed means denied” option. When selected, this option makes any unspecified value interpreted as an explicit “Deny”.
Special case: the Power and Full flags
In additions to the actions listed in the previous paragraph, we introduce two flags: “Power” and “Full”. They appear in the same list as the one used for actions.
“Power” and “Full” flags are used by policies to fine tune rights. No detailed description is provided here as this is highly customizable and potentially quite complex. Policies are not yet administrable and are currently provided by Nixxis in order to fulfill logical behavior from an operational point of view. For example, standard policy defines that a power flag on supervision related to an activity allows the user to pause and start an outbound activity (even if “modify” is not allowed on administration).
Functionalities
The actions are related to the following functionalities:
- Administration
- Agent desktop
- Recording tool
- Reporting
- Supervision
Moreover, functionalities details are available for default actions related to the administration. These details are:
- Administration: activities
- Administration: campaigns
- Administration: queues
- Administration: teams
- Administration: users
- Administration: others
“Administration: others” includes all objects except activities, campaigns, queues, teams and users. For example, it includes phones, resources and locations.
Every combination of action and functionality is not allowed. For example, the “List” action is only applicable to administration functionality (and related details). The following matrix describes the meaning and availability of actions in relation with functionalities.
/ means that an action has no meaning with the corresponding functionality
The blue highlighted zone in the matrix specifies combinations available only when defining default rights. For example, a role can specify that, by default, its members are not allowed to delete activities. This right is obviously not available when specifying the security on a team or even on an activity.
Rights
As said, what we call “rights” are sets of allowed and denied actions related to some functionality, applied on some object for some user. For example, “Agent John Doe” can read admin data related to “Campaign ACME”.
Administration allows defining default rights, inherited by all objects.
Specific rights are managed object per object for only some kind of objects as seen on the drawing.
Objects accepting right management directly are teams, queues, campaigns, activities and security contexts.
The security context concept has been introduced in order to allow applying rights on group of logically related objects. A security context can be associated only to objects of some types (the most important ones from an operational point of view): teams, queues, campaigns and activities.
One remark must be done about users. Rights management cannot be done on users one by one but only through the teams they belong to. Also, users are not directly related to security contexts (except from their team).
Roles
Instead of giving explicit rights to every single user, rights are associated to roles and users are members of roles. The system defines some default roles but users are free to create their own roles. Objects needing rights management define action being eligible for each role. The following drawing illustrates that. Users are represented by the green boxes on the left side. Red and orange boxes in the middle are the roles themselves. Obviously, the links between users and roles describe the users’ membership. For example, “John Doe” has roles “Administrator”, “Operator”, “Recording”, “Reporter” and “Supervisor”. “Maria Bianca” has only the role “J & H Admin+”. Red colored roles are default roles while orange ones are user-defined. On the right side of the drawing, three sample objects are visible: the default object “Default”, the campaign “JH Sales” and the security context “NKZ Consulting”. These three objects rights are described by the combination of functionalities and actions sketched by the links between roles and functionalities. From the example, we can see that “Mike Vince” can list and read administration data related to security context “NKZ Consulting”. In the same way, “Mike Vince” is not allowed to delete any object related to security context “NKZ Consulting”.
Extra considerations
The NCS default user (initially created with account 100) is a particular case as it bypasses all security considerations and is always able to administrate objects even without being assigned to any role.
Another aspect to take into consideration when evaluating rights is the ownership of objects: an object is always visible and fully editable by its owner. That ensures that a newly created object stays visible by the user who has created it. Of course, ownership can be taken by eligible users.
When filtering administration data using rights, it is quite easy to reach a situation where a user can see some objects without being able to see some related objects. For example, a user can have the right to read an outbound activity without being able to see locations. As an outbound activity is related to a location, the view on the activity will be partial. Depending on settings, the related objects (the location in the example) can be partially visible (“List” allowed) or totally hidden (no right allowed).
In the same way, a user can have the right to create new objects without being able to specify some settings related to linked object. When this occurs, the system uses default system objects to complete the settings related to the inaccessible objects. We can extend the previous example by considering the creation of an outbound activity: if a user cannot see locations, the default location will be used instead.
Rights in the GUI
The scenario
The screenshots have been taken in an environment described by the following drawing. The context is a contact center company (named “Contact Center Excellence” or CCE) allowing two important customers to manage their activities and users themselves. These two customers are “NKZ Consulting” and “Jones & Hammer”. They both have their own users, teams, queues and campaigns.
Two security contexts are created for each of the customers. Every object is associated to its related security context. Two roles are created: one for each company. These roles does not provide any default rights (except creation, to allow roles members to create new objects).but they give full control on their corresponding security context. This setup ensures that users from one company can only access their own objects.
From the “CCE” perspective, the users that are members of the default “Administrator” role will be able to administer both companies by default. This setup also allows some teams of CCE to handle calls from the queues of “Jones & Hammer”, for example. “Jones & Hamer” administrators (same mechanism is applicable to supervisors) will not be able to see “CCE” teams and their users while they still can participate in contact handling for them.
Roles
The menu entry to access the Roles window:
Role general settings including description, administration grouping and Not allowed means denied options:
(This screenshot is related to “zone 1” of the drawing in section “Relations with logical organization”)
The Members tab shows the list of users and their membership to the selected role. The screenshot shows that agent with account “100” is member of role “Administrator”.
(This screenshot is related to “zone 2” of the drawing in section “Relations with logical organization”)
Another view of the same relationship is available when looking at the Users window: there, the Roles tab provides the list of roles related to the selected agent.
(This screenshot is related to “zone 2” of the drawing in section “Relations with logical organization”)
The Default rights tab shows default rights related to the selected role. The settings in the screenshot suggest that the “Administrator” role allows all actions on “Administration” while actions on other functionalities are unspecified.
(This screenshot is related to “zone 3” of the drawing in section “Relations with logical organization”)
The Objects tab lists specific objects for which specific rights have been defined in the context of the selected role. For example, the “NKZ admin+” role defines explicit rights on security context “NKZ Consulting”. The information is read only from this pane; going to the definition of the objet itself allows nevertheless editing the rights.
(This screenshot is related to “zone 4” of the drawing in section “Relations with logical organization”)
Security contexts
The menu entry to access the Security contexts window:
The General tab allows edition of the description and administration group key.
The Objects tab shows the objects related to the selected “Security context”.
The Rights tab displays the roles and their associated rights relative to the various actions and functionalities.
(This screenshot is related to “zone 4” of the drawing in section “Relations with logical organization”)
Secured objects
We have chosen queues as example of objects having direct rights management. The exact same mechanism exists for teams, activities and campaigns.
The Security context related to the queue can be selected using the highlighted dropdown list.
The Rights tab allows defining rights relate to the selected queue. In the screenshot, we can see that the role “NKZ admin+” has explicit “Deny” on all actions and functionalities for the queue “JH Insurance”.
Other considerations
The following screenshot shows campaigns related settings. It includes various important aspects not yet described.
On the bottom of the picture, in the information zone, you can see the link used to take ownership of an object. Note that the current owner cannot be displayed as the logged in user has insufficient rights to see it.
This same remark is valid for other concepts in the same screen. For example, as current user cannot administer locations and carriers, the actual values for those settings cannot be displayed: a pictogram is displayed instead to indicate that.
Another approach in that situation would have been to allow “List” action on “Administration: others” in order to give the user the right to select locations and carriers without being able to see their details.
Relations with logical organization
This drawing shows relations between the previous screenshots and the logical structure.
- Roles window
- Members tab of selected role - Roles tab of selected user
- Default rights of selected role
- Objects tab of selected role - Rights tab of selected security context
See previous screenshots for details.
Conclusion
We have seen that rights, roles and security contexts allow you to control precisely which actions are allowed for specific users.
The roles are used to group users having similar rights. While there are some default roles, custom roles can be added to match your particular needs.
Even if rights can be assigned objects by objects, they can be associated to a security context in order to affect multiple objects in one shot. This greatly simplifies day to day management of the system by allowing you to group together objects that are linked from an operational perspective.
To conclude, using NCS allows a customer’s contact center to outsource a part of its activity by smartly filtering the data available for the outsourcer. The reverse is obviously also true: an outsourcer running NCS can easily give a partial access to its customers.
Related Articles
Custom Roles - See only specific affectations
Introduction This article aim to describe how to create custom roles to see specific affectations. Creating role Create a new role. In this example, it is named "Reporter_Custom" In NCS Admin, go to Operational Parameters -> Roles Create a new role ...Operational Parameters - CallBack Rules
Introduction This articles intends to describe how to configure callback rules. Accessing Callback Rules The callback rules management interface can be accessed by clicking on the icon in the 'advanced' toolbar. Callback rules are evaluated one by ...Technical Parameters - Answering Machine Detection
Introduction This article provides an overview of the AMD (Answering Machine Detection) settings in Nixxis Contact Suite. It explores the technical parameters and customisation options available for optimising AMD settings based on specific ...Operational Parameters - Creation of an Address Book
Introduction This article aims to describe the steps to follow for creating an address book. The address book is accessible in the agent module and can contain: Entries/contacts (agent, team agent, queue, or external contact) These entries are ...Operational Parameters - Auto Ready Settings
Introduction Auto ready relates to setting an agent in ready after its wrap-up time instead of leaving it in not ready (default). This can be set at the level of global settings, activities, teams, qualifications and agents. Auto ready is active if ...