Authorization - The Second A in the Triple AAA’s of Security [series]

When a user logs in to a system, the first action that system will take will be to Authenticate or identify that user.  As discussed in the first article of this series, Authentication to systems and applications s often done by means of a unique userid and password. Once authenticated, the next step is to determine what the user is authorized to perform.

The authorization process actually begins before a user ever logs in or even has a login to a system. One of the most useful methods for defining and managing authorization is an employee’s job description. Formal job descriptions should not only explain the role and function of the position, but should also document the facilities, systems, and applications that position must have access to, and the nature and level of access.

Terminology that describes level of access will often vary between companies, but common naming conventions include terms such as ‘ADMIN’, ‘MANAGER’, ‘SUPERVISOR’ or ‘LEVEL 1’ or ‘LEVEL 2’.  Job descriptions must be reviewed by the hiring manager and appropriate persons to assess whether the identified access is appropriate for the role and function of that position. Often times these access controls are referred to as ‘Roles Based’ access, where the permission levels authorized will vary depending on the role and function of the position.

Best practice also recommends the creation of a ticket or case to create the new userid and password and within this case, access and permission levels will be specified according to the users job description. Finally, businesses should carefully assess jobs and roles to ensure the creation of proper separation of duties. Best practice dictates that care be taken in allowing too much authority or permission to reside in the hands of a single person or process. This creates opportunity for unmanaged, unsupervised and possibly unauthorized actions on the part of a single individual.

The inContact ACD solution provides a flexible roles based permission model allowing businesses to create their own granular custom security profiles, enforcing separation of duties using unique permission for unique roles. Within the ‘Manage’ functions of IC Central, discrete security profiles can be created. These profiles control access to features, functions and data.  For example, you can have two teams, Team A and Team B, each requiring similar permissions, but restricting Team A to only Team A data and Team B to only Team B data.

One important practice related to separation of duties is to control the ability for users to create copies of themselves. By using the ‘Assignable Profiles’  under the ‘Restrict Data’ section of ‘Security Profiles’, you can create a ‘Supervisor’ role that could create agents but could not create other supervisors. Another example, Team A Manager can be allowed to create Team A Supervisors and Agents, but not allowed to create Team B Supervisors and Agents.

The inContact ACD  security profiles enable businesses to manage their authorized permissions in a granular roles based fashion.