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

The number of days from the last password reset after which the user password will expire automatically is set here. By default this field is empty. The user passwords will not expire automatically unless this field is filled.

If the number of days left to password auto-expiry is less than 7, then the user details page displays a message "Password expires in n days." in red color, next to the change password button.

For example, if password auto-expiry days is entered as "30", any user's password will expire automatically once 30 days have completed since their password was last reset. After this the user MUST reset password and login with a new password to access NEOSYS again.

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 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.

For mandatory authorisations, a blank locks field on a task means that the task is not authorised to anybody EXCEPT NEOSYS, not open to every user. Currently very few tasks are under mandatory authorisation, e.g. JOURNAL POSTING, access to particular records like COMPANY ACCESS 'X'.

The lock code "NEOSYS" locks all users out of a task without exception, the key "NEOSYS" should not be given to any user.

Ideally a lock code should be informative of its purpose.

Below is a list of all locks in the initial dataset and brief description. Detailed descriptions about these lock continue in the sections below.

Lock	Description	Module	Files
UCF	Update Client File	Agency	Clients
USF	Update Supplier File	Agency	Suppliers
UF	Update Files	Agency	Vehicles, Ratecards, Vehicle Costs, Market, Product Categories
AA0	Access Accounts Level 0	Finance	Limited Access
AA	Access Accounts	Finance	Finance Team only
AA2	Access Accounts Level 2	Finance	Trial Balances, Fin Reports, Aged Balances, Fin Statements
CA	Control Accounts	Finance	Setup Charts, Companies, Currencies
UA	Update Accounts	Finance	Post Journals, Create Accounts, Update Exchange Rates
UA2	Update Accounts Level 2	Finance	Currency, Post into Revenue accounts, Post into Rebate accounts
GS	Group Support	IT	Update Authorisation for higher groups and lower groups
LS	Local Support	IT	Create new users
AP0	Access Production Level 0	Jobs	Limited Access
AP	Access Production	Jobs	Job/Production Team only
AP2	Access Production Level 2	Jobs	Billing Analysis reports
API	Access Production Invoices	Jobs	See Invoices
UP	Update Production	Jobs	Create Jobs
UP2	Update Production Level 2	Jobs	Create Purchase Orders after Job is closed, Create Tasks
UPC	Update Production Cost	Jobs	Create Purchase Request/Order
UPI	Update Production Invoices	Jobs	Create Estimates
AM0	Access Media	Media	Limited Access
AM	Access Media	Media	Media Team only
AM2	Access Media Level 2	Media	Billing Analysis reports
AMC	Access Media Cost	Media	See Cost to Agency from Suppliers
AMI	Access Media Invoice	Media	See any information related to Billing to clients
CM	Control Media	Media	Setup Media Types
UM	Update Media	Media	Create Plans, Schedules, Booking Orders, Materials, Certificates
UM2	Update Media Level 2	Media	Updating Schedules after booking/invoicing
UMI	Update Media Invoices	Media	Create Invoices
MA	Menu Analysis	Menu
MF	Menu Finance	Menu
MJ	Menu Jobs	Menu
MM	Menu Media	Menu
MT	Menu Timesheets	Menu
TA	Timesheet Administration	Timesheets	Access Reports, Monitoring, Editing old Timesheets
TAR	Timesheet Avoid Reminder	Timesheets	Avoid Reminder emails
TAP	Timesheet Approval	Timesheets	Authorisation to approve Timesheets

Access/Update Locks

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:

XX = normal authorisation level
XX0 = below normal authorisation level
XX2 = above normal authorisation level
XX3 = even higher authorisation level 

XX0 is given to lower level users that can be thought of as "below" usual level of authorisation or "very limited" level of authorisation and XX2 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. For example, UA0 could be put on JOURNAL UPDATE for data entry staff who are not allowed JOURNAL POST as this is locked with key UA and given to all finance people EXCEPT pure data entry finance people ... who might not even be in finance department

Menu Locks

This enables giving/removing entire Menus for users. However, restricting access by menu MUST NOT be considered a real restriction in NEOSYS since it is easy to work around by knowing and typing the right URL. Actually this is by design, in order to be able to give people special rights in some rare cases without giving them full access to a menu. Therefore we have a general lock/key like Access Media (AM) or Access Production (AP) which is applied to most files within a module. You must restrict people from accessing files that they should not see using locks on the FILES and not the MENUS.

Versions of NEOSYS before 4/6/2010 used MENU CODE concept instead of the current LOCK/KEY concept. If no menu is locked in the Authorisation File then menu access is not determined by task authorisations. Instead it is determined by what MENU CODE they were given in the Authorisation File before the current tasks with lock-key concept replaced MENU CODE concept in later versions of NEOSYS. Wherever support staff sees this, they must implement “authorisation per menu” by adding appropriate locks to ALL menus otherwise it can cause unexpected errors especially when moving users from one group/department to the other. However, remember that any menu without a lock will become available to ALL users as soon as you put a lock on ANY menu task.

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

1. Get approval from higher authority when customising Authorisation file or granting authorisation to all "ACCESS" tasks. Refer link Handling Requests that require Approval from Higher Authority
2. When creating a new department, use only standard department names already in use in NEOSYS like MEDIA/MEDIA2/MEDIA3 or CLIENT SERVICE1/CLIENT SERVICE2 etc. Refer to the initial dataset (STARTUP1) for standard department names. You must NOT use double digit numbering as it says nothing about the level or type of seniority. You must NOT use non-standard group names like "MEDIA A" or "MEDIA COMPANY A" or "LINE HEADS" etc as this will create problems especially for Timesheet users (For more information, see Setting up Activities for Timesheets).
3. If separate departments are present for each company in the dataset, the company name of the department should be entered as the User Name of the Department id. This is done so that it is easy to identify which company the department belong to, at one quick glance. (See below section for more information on this)
4. Other than the above case, 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 log in using these for testing purposes.
5. Do not create new locks for new or existing tasks for convenience. Existing keys must be reused where ever possible. Good support is doing the right thing for the long-term success of the system. Refer to allowed tasks and locks, also refer to STARTUP database for any new tasks and locks
6. 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. Also refer to Per user Authorisation
7. 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 subgroups 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.
8. Do not create user IDs like AUDITOR or MANAGMENT and grant special access to such users like read-only access as this breaks all security rules. Only create accounts with names and email addresses WITH NO EXCEPTIONS unless agreed by NEOSYS management.

How to set up departments or user groups in Authorisation File for multiple companies in the same dataset

(Note: This section only talks about how to set up USER GROUPS. For setting up TASKS/LOCKS, see Tasks and Locks)

Let's say there are two companies: company A (Art Company) and company B (Bat Company).

Both these companies are in the same dataset with separate operations teams. You want to set up user groups in the authorisation file such that users of company A should not have access to company B and vice-versa.

Set the department USERID as a standard department name and set its USERNAME as the company name. Refer to the rules from above section: Rule 2 (about using standard department names) and Rule 3 (about entering company name as User Name of department "user" id)

In the below example:-

Setting userid as MEDIA and MEDIA3 adheres to rule 2.

Setting username as Art Company and Bat company adheres to rule 3.

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.*, 172.16.*, 10.* and 127.*.

• Top Management approval required for HTTPS access from any IP or range of IPs

• From versions starting 4 Feb 2016, the Internet IP Numbers from which a user is authorised to login from are now the first found in the following locations

1. the ipnos given for the user
2. the ipnos given for the user's department,
3. the ipnos in the System Configuration File - which can be per database/installation or server
4. Standard LAN ipnos 192.168.* 172.16.* 10.* 127.*

It is no longer the case that users with no ip nos specified in 1. can login from the ipnos of any user below them in the hierarchy. This allows individual users to be limited to particular ipnos without having any effect on other users. This is particularly useful when temporarily granting wide access to individual users for some reason. This facility should not be abused and become the main way of authorising access to users and which would therefore require changes to all users when some minor change in network becomes necessary. For ease of long term support and maintenance, the order of preference for configuration is 3, 2, 1.

However if IP numbers are specified in 3 or 2 or 1 , then lan ip nos will not be given automatically to everybody or department or user respectively since it may not be that simple for future clients who might have segmented lans ie media on 192.168.1.0 and finance on 192.168.2.0. So if ip numbers are specified anywhere, then lan ip no.s (if required) also must be specified. NEOSYS mentality at the moment is that if you are going to specify ipnos then you have to specify all .. including LAN ipnos.

The below example shows show to restrict access of CLIENT SERVICING department to a specific 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.

CIDR notation

Classless Inter-Domain Routing, or CIDR, is a notation where you can add a specification in the IP address itself as to the number of significant bits that make up the routing or networking portion.

For example, we could express the idea that the IP address 192.168.0.15 is associated with the netmask 255.255.255.0 by using the CIDR notation of 192.168.0.15/24. This means that the first 24 bits of the IP address given are considered significant for the network routing. Each octet consists of 8 bits. Therefore if only first 24 bits of the IP address given are considered significant for the network routing, it means that only the first 3 octets are considered as significant. This is equivalent to 192.168.0.* in NEOSYS format.

“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 it 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.

Get management approval to expire users

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 Senior Finance/Media groups access to Support Menu

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.

For giving access to Support Menu, we have to provide keys for the respective tasks. The first one is the 'MS' key for the 'Menu Support' task to see the Support menu and access the sub menu options e.g System Configuration File/List of Database processes etc. Then LS and GS keys for the tasks Local and General Support respectively are given to access the authorization file. The GS key allows to view the whole authorization file whereas with the LS key user can view only the group to which they belong.

For other Support related tasks e.g looking at the Backup logs the key 'AF2' for the 'Log Access' task should be given. There are some tasks like "Dataset Backup" or "Dataset Copy" for which key MUST be given to NEOSYS Support only. This is because Clients are not the best decision makers when it comes to handling DATA Backups because only NEOSYS Support knows when to do Backups and the proper procedures to be followed. This is necessary for protecting their DATA from getting lost or over written by the dummy Test DATA.

Configuring Access to Financial Reports

See Configuring Access to Financial Reports

How access to a file works in combination with access to specific records of the same file

When tasks for a file in general and it's specific record are locked, then users who have the key for a specific record can access that record without having a key for the file in general. e.g "media types file" and record for "newspaper" in the media types file.

Lets discuss the NEOSYS ledger to see how the authorisations work. See examples below that state all the possible combinations of a user with/without a set of locks.

Example 1: If there is a task "ledger access" with lock=AA and there is one more task for a specific ledger "X" (lock=AAX), then:

1. User with "AA" will be able to access all the ledgers except for "X".
2. User with both "AA" and "AAX" will be able to access all ledgers including "X".
3. User with only "AAX" will be able to access only ledger "X" and no other ledger
4. User with none of the two keys will not be able to see any ledger

Example 2: If "ledger access" task is open to all and there is a lock only for ledger "X", then

1. User with "AAX" can access all ledgers including "X"
2. User with no "AAX" can access all ledgers except "X"