Authorisation File
The Authorisation Table
The NEOSYS authorisation system uses a concept of users, user groups, tasks, locks and keys.
The Authorisation File is on the Support Menu which is not available to everybody.
Tasks and Locks
The various tasks that users may be authorised to do are listed and have a single code (lock) next to them. The same code (lock) may be placed on many tasks, allowing the bulk authorisation of groups of tasks according to need. The grouping of tasks can be seen by sorting the tasks in order of their lock codes by clicking on the column heading titled "Locks".
Often to do accomplish some function in NEOSYS you need to be authorised to do more than one task in the authorisation table. For example to update a media schedule you need to be authorised to both access the schedule file and to update it.
Access to individual records may be restricted by appending the record key in quotes for example placing a lock on a task called ACCESS COMPANY "X" would restrict access to that company. To restrict access generally to a file but allow access to specific records, place a lock on the file eg ACCESS COMPANY but specifically enable access (place a lock) to specific records eg ACCESS COMPANY "X".
Access to particular datasets may also be restricted by placing a lock on a task called DATASET ACCESS "XXXX" and this would restrict access to users to that particular dataset.
NEOSYS authorisation table is not restricted to controlling access to files. Many tasks are very specific, for example one may or may not be allowed to book coincident ads.
A typical lock code might be AA (mneumonic for "access accounts") which would be placed on all general accounting tasks except those requiring further limitations. The AA key would only be given to accountants, thereby placing a convenient blank restriction on the ability of non-accountants from accessing accounting functions.
The lock code "NEOSYS" locks all users out of a task without exception, the key "NEOSYS" should not be given to any user.
Two of the basic functionalities of locks used in the NEOSYS AUTHORIZATION TABLE are:
- Access
- Update
Depending on the system being used, the lock can be:
- Access Media / Update Media for Media System (AM & UM)
- Access Job / Update Job for Job System (AP & UP)
- Access Accounts / Update Accounts for Finance System (AA & UA)
Every organization has some sort of hierarchy and hence the permissions to be given to the various users depends on the level that they belong to.
The Access Media permission is given to users who may want (and are authorized) to keep tabs on what the media personnel are working on. Typically, this includes Higher Management or people in supervisory roles. People with Access Media Rights can view the various schedules/plans but cannot make any changes to them. Media Personnel who have Update Media rights should also be given Access Media rights since, in NEOSYS, these two permissions have been kept separate deliberately.
Similarly, General Management may have Access Accounts (AA) but only the Finance Team would have Update Accounts (UA) permission since they are responsible for accounting in the organization.
Each lock can have levels (eg. AM0, AM, AM2) to differentiate the tasks at each user level. AM0 is given to lower level users like Junior level and AM2 can be assigned to General Management who may have more detailed Access rights than other users. No lock should be assigned the level 1 (eg. AM1) because a lock without a number indicates level 1 itself.
Ideally a lock code should be informative of its purpose.
Users and Keys
Users are listed in groups for easy comprehension. Each group is separated by a blank line. The last user name in the group is an imaginary user and is used the name of the group.
Any user can be given "keys" which are short alphanumeric codes that correspond to the "locks" on the list of tasks. Users possess all the keys of any users lower in the group including the group user, so keys are typically added and removed to the group user. Possession of a particular key enables (authorises) the user to perform all the tasks that have the same lock code that matches the key code.
Before giving a user a "key", consider sorting/filtering tasks to see what access the key grants to the user. Do not grant keys without fully appreciating what they lock.
Subgroups
In the following example, Joe and John are senior accountants and have all the keys placed on the SENIOR ACCOUNTANT and all the keys placed on the ACCOUNTS "user" whereas Joan and Joseph only have the keys placed on the ACCOUNTS "user". It is a matter of hierarchy.
- JOE
- JOHN
- SENIOR ACCOUNTANTS
- JOAN
- JOSEPH
- ACCOUNTS
- blank line separating the next group
Within a group it is convenient to define users that represent subgroups like SENIOR ACCOUNTANTS. The users above (listed before) this "subgroup user" will have all the keys placed on this subgroup user. All of the users are still in the department ACCOUNTS since that is the last line of the group.
Access restriction by IP No.
1. Access to NEOSYS is by default restricted to users from the standard Local Area Network IP numbers i.e. 192.168.*, 10.* and 127.*.
2. Users may also be restricted to login only from certain IP numbers or IP ranges.
For Example: Assigning the IP address 192.*, 10.* in the System Configuration File would restrict users to logging in only from the local area network.
We can do that as follows:
a) Navigate to the System Configuration File:
Menu >> Support >> System Configuration File
b) Enter the IP Address ranges in the restrictions field
3. If a user is permitted to access NEOSYS from an external IP address, we need to assign that external IP address along with the IP address of the Local Area Network to the level of the user in the Authorisation Table.
We can do that as follows:
a) Navigate to the Authorisation File:
Menu >> Support >> Authorisation File
b) Enter the IP Address in the Allowed IP Numbers field
Access restriction for user: NEOSYS
- The user NEOSYS has been restricted to login only from Private LAN, NEOSYS Office/VPN IP addresses and configured static IP addresses.
Ordinary users may or may not be authorised to login from dynamic IP addresses outside the office, but the user NEOSYS cannot. - To prevent NEOSYS access from WAN (public internet) via a NAT router with a private LAN IP, we list the full IP of the NAT Router in the System Configuration File.
How the Authorisation Table works
It consists of mainly two sections :
(a) Users, and
(b) Tasks
The "USERS" section lists all the NEOSYS users licensed to use the software in their respective levels in the organisation.
This section allows support staff to do the following :
- Add/Delete users
- Disable existing users by entering an "Expiry" date
- Generate a password for a user or a level
- Set the number of days for the password to auto-expire
- Enter/change the user domain
- Monitor the users last login date, time and IP
- Add/Remove/Edit tasks for a user / level
- Specify allowed IP Numbers
A user can only access a particular task/function in NEOSYS once the task is allocated to him/her by an authorized person or by NEOSYS support staff
The "TASKS" Section consists of a list of all the tasks that users need authorisation to access in NEOSYS. Authorisation is provided to users by assigning a "LOCK" for each task in the "TASKS" section and allotting the respective LOCKS to the users in the "USERS" section against their name/level.
Customising the Authorisation Table
- The various levels in Authorisation File like Admin, Management, Media, Finance, Production, Client Services, etc. are created as per the clients requirement.
- Each level is allocated locks which enable the users above the level to have access to the corresponding tasks.
- Inserting a blank line between levels prevents the higher level from accessing the tasks allotted to the lower levels.
- Removing the blank line enables the higher levels to access tasks assigned to the lower levels,however, lower levels cannot access tasks in levels above them.
Key Points to Remember:
- Do not enter USERNAMEs for group “user” lines i.e. Departments
Department names/levels need not have any USERNAME specified as these are not real users. Also you should not specify an email address on the same, as these department names/levels are only to identify the user groups. You may login using these for testing purposes. - Do not assign keys to individual users. Assign them to a group “user” i.e. Department instead
If you feel the need to assign keys to a user, feel free to insert a new group user under them and assign the keys to that group user. This will enable us to manage the authorisation table i.e. add / delete users based on what Department they belong to, so that they get all required authorisations.
“Per User” Authorisations
Sometimes there are requests to provide very fine grained “per user” authorisations. However it is very hard to manage “per user” authorisations in the long term since there are a huge array of tasks that need to be decided per user.
Consequently is very important to maintain the VERY MINIMUM number of user groups and subgroups and NOT create additional special groups unless it is absolutely necessary.
Support staff are NOT helping the long term quality of experience of the system to the end users if they “try and be helpful” by providing many special groups and/or private authorisations for individuals. They will create a “rats nest” of incomprehensible unmaintainable authorisations. Worse, it is likely that accidental authorisations will be granted because it is impossible to reliably audit a long and complex set of “per user” authorisations.
Good support is doing the right thing for the long term success of the system. Bad support is doing whatever is asked by anybody chaotically and adding no value. Good support is not taking the easy short term way out. A system succeeds by its long term benefit to the client.
Expired Users
Users who no longer use NEOSYS should be entered as expired. It is probably best to put the current date as the expiry date so that you have a record of when the expiry was entered into the system. You could also backdate the expiry date if you find that more informative.
If you put an expiry date in the future then the user can continue using the system up to, but not including, that date. This is useful if staff are working out a notice period for example.
An expiry will have immediate effect and prevent the user from further access to NEOSYS even if they are currently logged in and working. Following general security principles, expired users are not informed of any reason why they cannot login.
Note: Do not remove/delete the users from the Authorisation Table. An expiry date is sufficient to prevent them accessing NEOSYS or receiving email notifications from NEOSYS.
The expired users can be moved to the bottom of the same authorisation group but should not be either deleted or moved to another location or section in the Authorisation Table otherwise it becomes virtually impossible to answer historical questions about expired users activity or expiration. An option to hide/show expired users isnt available but might be later on.
Expired users will not be removed from Timesheet Summary as their usage details are recorded in it.
