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.
Password auto-expiry days
By default this field is left blank and the system will not reset the password unless specified. User password will expire automatically if the number of days is mentioned and the user details page will show the number of days the password will expire in.
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
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
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. The various groups in Authorisation File like Admin, Management, Media, Finance, Production, Client Services, etc. are present in the STARTUP dataset and is configured further as per the clients requirement.
User groups are given "keys" which are short alphanumeric codes that correspond to the "locks" on the list of tasks. Possession of a particular key authorises the user to perform all the tasks that have the same lock code that matches the key code.
Users inherit all the keys of group users placed below and not vice versa.
Inserting a blank line between levels prevents the higher level from accessing the tasks allotted to the lower levels.
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 KEYS to the users in the "USERS" section against their name/level.
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
Subgroups can be created to further define access by hierarchy.
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".
- 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 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.
Rules for Customising the Authorisation Table
- 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. - If one or more members of a group or subgroup need an authorisation that other users in the same group MUST not have then you can split the group into two sub groups where one subgroup is "senior" to the other. eg MANAGEMENT could become SENIOR MANAGEMENT and MANAGEMENT subgroup by inserting a "group user" in the middle of the group and moving the users up and down until they are in the right new subgroup.
- Do not create user IDs like AUDITOR or MANAGMENT and grant special access to such users like read only access this breaks all security rules . Only create accounts with names and email addresses WITH NO EXCEPTIONS unless agreed by NEOSYS management.
Access restriction by IP No.
- Access to NEOSYS for users is by default restricted from the standard Local Area Network IP numbers i.e. 192.168.*, 10.* and 127.*.
- To restrict ALL users to login only from certain IP numbers or IP ranges, configure these IP numbers/ranges in the System Configuration file. See IP restriction in System Configuration File
- To restrict SPECIFIC users to login only from certain IP numbers or IP ranges, configure these IP numbers/ranges in the Authorisation File. Avoid per user restrictions. See Per User Authorisation
If allowed IP numbers/ranges are configured in the Authorisation File then it takes precedence over the configuration in System Configuration File
E.g.As shown below, enter the IP numbers/ranges in the Allowed IP Numbers field of Client Servicing User group to restrict access of DEMOUSER and allow access only from the specified IP number/range
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.
“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.
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 isn't available but might be later on.
Expired users will not be removed from Timesheet Summary as their usage details are recorded in it.
Giving Support access to User groups
By default Support keys are given to the IT group but it is a fact that NEOSYS is mostly used by the Finance and Media Managers. These users are the first and the most important point of contact in case of any issues and new requests. The IT group on the other hand rarely logs in to NEOSYS, which means the top people in Media/Finance have better understanding of how to use NEOSYS. So it is advisable to give the Support keys to them, this will help them to:
- Make "new Users/authorizations" requests as they will now see and understand per group authorizations hence easily answer questions by Support to mention other users who have same access for new user account requests.
- See backup logs in case of backup related issues.
