All data that WiComply stores is protected by a rigorous multi-layer security architcture as outlined in diagram 1.0.
The system is designed with an authorisation scheme that is simple to apply out of the box, whilst being highly fliexible enabling customisation to adhere to existing roles and processes within your organisation.
Diagram 1.0.
Authentication takes place via username/password submitted through a form-based authentication layer (Point 1, Diagram 1.0). The connection between the browser and the application is encrypted using SSL (HTTPS connection). All user passwords are stored in the database in one-way encrypted formats making it virtually impossible for anyone to “decrypt” a user’s password even if they have access to the application database.
Optionally, authentication can be deferred to a “trusted” internal entity within your organization to achieve “Single Sign On”. This is possible only when the application is installed for a single customer, to integrate with their ActiveDirectory/LDAP server. In this configuration, the WiComply Server does not store any passwords but relies on the ActiveDirectory/LDAP server for verification of the user. In an enterprise, this has the advantage of Users being able to login with their usual network/desktop credentials.
The authorisation layer (Points 2, 3 & 4, Diagram 1.0) is a multi-layered system allowing you to fully control the three dimensions of authorisation:
- Who can access which parts of the system.
- What actions can they perform with the data they can access.
- On which objects can they perform the actions.
- As easy to use as possible - Out of the box, the system comes with predefined roles which handle all three dimensions of permissioning. This empowers the administrator to start with “same defaults” so at a most basic level, choosing the right hierarchy policy and assigning the right role to each user is all that you need to worry about.
- As complex as you need it to be - WiComply enables administrators to modify permissioning, customizing WiComply to fit their existing processes/roles. This is important so that the system does not dictate your business rules, but your business rules should dictate how the system behaves.
While it is important to have precise control over user’s privileges, it is equally important to establish a baseline policy across the organisation to decide default set of objects accessible to any user within your organization. This will ensure that any new user on the system can be setup with minimal administrative overhead.
This forms the lowest tier of the permissioning matrix and defines what every user can access as soon as their account is activated.
As an administrator you can decide what default permissions to grant to each user (Diagram 2.0):
- Allow access to all forms & documents within the user’s division
- Allow access to all forms & documents within the user’s location
- Allow access to all forms & documents within the user’s company
Diagram 2.0.
This maps to your organisation hierarchy and allows you to be as permissive or restrictive in your default permissions as needed.
Permission is limited to which objects are accessible to the user. It does not automatically determine what actions the user may perform on those objects. The actions allowed for each user are determined based on the user’s role assignment and user’s ssociations.
Your organization’s hierarchy policy can be set from the “Hierarchy Policy” menu under “Settings” (Diagram 3.0).
Diagram 3.0.
Roles determine what actions the user can take on objects of various types. As discussed above, the hierarchy policy determines which objects are accessible to the user. So when defining a role, it is sufficient to describe what actions the user can take for each object type, rather than a specific object.
Each user in the system must be assigned exactly one role during creation of the user. Therefore each user gets access to a set of actions on a set of objects as soon as their account is activated.
Role definitions play a key part in making user administration simpler and precise. Roles can be easily customized to suit your specific needs (Diagram 4.0). You can edit the actions associated with an existing role, as well as define your own roles.
Out-of-the-box roles within WiComply are arranged in a proper priority order. As an administrator if you define new roles, you must ensure that they have proper priorities.
You can adjust role priority by simply dragging and dropping it in the desired priority order slot. For example (Diagram 5.0), a user with the role “Snr Admin” cannot assign roles “Super User”, “Client Account” and “Admin” to other users, but can assign all the rest (shown in green).
Diagram 4.0.
You can assign roles to user’s either from the Edit User screen or through the Edit Role screen. Each user in the system has exactly one role. This makes it easy to map various types of users in real-life to their roles in the system.
While your organizational “Hierarchy Policy” gives you a great way to “automatically” grant access to the right data to the right user, there are always exceptional cases where a user needs access to additional documents and forms.
For example, if your organisation’s hierarchical access policy is set to allow access at “Division” level, meaning all users have access to all data at their division., but you would like to have a specific user to have access to other divisions, WiComply provides specific User Association modification capabilities that allow you to associate the user with additional companies / locations / divisions /form/categories so that the user can access data for all the associated hierarchy nodes.
This gives you flexibility and control in deciding what data each user can access.