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

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.

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.

Configuring Access to Financial Reports

See Configuring Access to Financial Reports