Permissions versions


Versions 1 & 2

BriteCore offers two types of permission schemes:  Non-Restrictive – V1 and Restrictive – V2.  The information on this page describes the two approaches. To change from Version 1 to Version 2, contact BriteCore Support to consult. The information below describes the differences. 

Permissions V1 – non-restrictive

When you add users as contacts into BriteCore under this scheme, they have access to all parts of the system until they are restricted. (This is part of the setup during implementation.) Restrictions are built from rules that pertain to specific parts of the system.

Restriction types

  • By URL – Users can be restricted from webpages via URLs. For example, restrict a user from the Claims module via britecore/claims.
  • Front-end Functions – Users can be restricted from functions, which appear as camelCased verbs. For example, restrict an agent from submitting an application via agent/policies/submitQuote.
  • Back-end Functions – Functions can be restricted server-side.
  • UI Elements – Users can be restricted from using specific buttons.

Permissions V2 – restrictive

With BriteCore Permissions Version 2, you add users as contacts to the system and then assign roles. Roles contain the permissions to access features and functions. (Roles are set up during implementation of this permissions approach.)

This scheme is totally restrictive – users are restricted from accessing any part of BriteCore until you grant each user permission individually.

Benefits of the restrictive approach

Auditors and security professionals generally prefer the restrictive method because it is clear what each role is actually accessing and who is assigned to those roles. Also, the chance of unassigned contacts unwittingly allowed access is eliminated as all contacts, all users, must be explicitly identified and assigned permission manually through roles.

Note the following characteristics that apply: 

  • All Permissions Levels must be established with a set of allowable URLs appropriate for various contact levels at your company. 
  • All role permissions must have a default permission level assigned.
  • Each role must have a set of default permissions (including rules for access). There must be one role for each type of contact in the system. For example, there could be a role for a claims adjuster.  All the access rules that pertain to work an adjuster performs is added to the claims adjuster role.
  • Assign roles to your contacts. Each contact in the system must be associated to a role to access the system. Any contact who performs the function represented by a particular role must be associated with that role in the system.
  • Contacts may have more than one role assigned if they need to log in and perform multiple roles within your company.

To begin the process of switching to Version 2, contact Support and ask about switching to Permissions Version 2.  

To enable version 2 permissions, change advanced setting engine-version to v2.