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

• Get Top management approval when Customising Authorisation file. Refer link Handling Requests that require Approval from Higher Authority
• 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.
• When creating a new department, use only standard department names already in use in NEOSYS. Refer other clients authorization files for department names. Do not use non-standard department names, e.g. "LINE HEADS".
• 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.*.

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

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