Web portal access security

Security context

The HelpMaster Web Portal has a slightly more complicated security context than the Desktop Edition.  Whereas in the Desktop staff can be assigned to security groups, all users are still staff and therefore have some degree of trust.  In the Web Module, users actually form two primary groups - Clients (end users) and Staff (technician or agent helping Clients).

The clients, being able to login, adds a whole new level to the issue of security, and this itself will depend very much on the Web Module and HelpMaster implementation of the organisation.  For instance, if HelpMaster is used only to support clients who are staff members of the organisation (those classified as internal for instance), then while there is a security risk, they are all part of the organisation and therefore should all have at least some level of trust.  However, if you are supporting a large group of external clients, then this becomes a different story as the client base could be made up of just about anybody - meaning that no trust can be taken for granted.  Then, there is also the option to allow for client self registration.  If allowed, literally anyone can register themselves as a client (that is, anybody who can get to the registration page).  All of these factors need to be taken into careful consideration when deciding how tightly you need to secure your HelpMaster Web Portal installation.

The other primary security context is that of the staff members.  Basically, this is implemented in much the same way as the Desktop edition, with staff security groups and their restrictions coming into play (for more information, see staff security setup.  Many of the options that apply to clients (for instance, allowing attachment download / upload) don’t apply to staff members as these exist in the system with a higher level of trust.

Client security

There are numerous ways to make the HelpMaster Web Portal more secure.  This article will consider some of these options.

- Restricting use of attachments / securing attachments

By default, attachments can be both uploaded and downloaded.  These options are both configurable through the global application settings for the Web Module.  If attachments have been allowed for upload, it should be ensured that sufficient disk space has been allocated to store all these attachments.  Also, it is extremely important that adequate virus scanning software has been installed on the server to ensure that if any malicious files are uploaded these will not do any damage.  If such protection is not available, it would be best to disallow client attachment upload.

- Restrict use of client self registration

Client self registration is a powerful feature of the application.  This way, the administrator or staff need not intervene when a new client wishes to log a support request but rather the client can enter their own details in the system, create a user id, and log the request themselves.  Unfortunately, there is also a down side to this in that anybody who has network access to the Web Module can create a client ID for themselves and log into the system.  The responsible party needs to decide how user names will be allocated to clients and whether their security framework allows clients to allocate their own IDs.  This will depend on factors such as the accessibility of the Web Module (if the Web Module can only be accessed over an intranet link, then technically only those who are internal should be able to gain access to the registration page; whereas if the Web Module is available over the internet, then anybody may sign up).

Disabling client self registration is simple.  Again, this is done from Web (toolbar) > Web Settings (icon) > Security (tab) where the Allow Self-Registration option needs to be unchecked.  By default, clients are able to self register to use the Web Module.  As an alternative, to register all existing clients for use with the Web Module, go to the client passwords screen, send these passwords to the relevant clients through email.  This is the simple way to license your existing clients in bulk.

- Linking clients to jobs

Only clients that are linked to a job will be able to view or update that job. The Primary client is usually the person who actually logged the job via the web portal. Additional clients can be linked to jobs and either granted or revoked access to the job.

- Site-wide job visibility

HelpMaster Administrators can also grant Site-wide viewing permissions to all jobs logged by the site and it’s linked client users. This will allow all clients linked to the site in question to view any jobs logged by or for the site’s users.

- Private action viewing

When a staff user adds an action to a job and marks it as a Private internal note, generally any linked client (and possibly even staff if only linked as client) users will not be able to see the action’s details or any linked attachments.

Staff Security

Most of the settings that control staff access levels are configured through the HelpMaster Desktop application.  For more information on how to set up staff security groups and how to grant / deny access these security groups, see the page on staff security setup.  Allocating Staff web licenses is done from the HelpMaster Desktop application under System Administration > Web Licensing.

See Also

Configuring web portal settings

Configuring staff security groups and settings

Issuing client licenses

Setting and resetting client passwords