Permission Pools

A permission pool is a collection of permissions that are pooled together to create the appropriate set of permissions for a specific user category. The authorisation mechanism is different depending on the pool type.

Not all permissions from the pool are necessarily granted to the qualifying user, they are there available for granting. Current Verne implementation uses permission pools in two ways:

In some cases users fully inherit the pool upon initiation of a session. For example, any user who has not logged in falls into a ‘Guest user’ category and therefore inherits all permissions from the ‘Guest user’ permission pool.
In other cases, there is a layer in between the permission pool and the user that determines the subset of a permission pool permissions that the user inherits. For example, an internal user inherits permissions from the permission groups they are a member of, whereas a permission group, in its turn, contains a subset of permissions from the ‘Internal user’ permission pool.

User management conceptual data model that can be found on this page User Management contains high-level details describing the connection between each permission pool, its corresponding user category and layers in between.

Permission pool attributes

Avatar
Code – a unique code for the permission, e.g. PP01
Name – name of the permission, e.g. Guest user
Description – descriptive text explaining the purpose of the permission pool
Set of permissions

Permission pool types

There are two types of permission pools:

‘user type’ permission pools
‘relationship type’ permission pools

‘User type’ permission pools

‘User type’ permission pools define possible permissions for the following user categories:

guest users (unauthenticated users)
external logged in individual users (users acting on behalf of themselves as customers of the Registry system)
external logged in organisational users (users acting on behalf of the professional organisations as customers of the Registry system)
internal users (uses who represent the Registry office staff)

Every Verne implementation must have the following four permission pools to match the user categories listed above:

PP01 Guest user permission pool	Guest user inherits permission U001 Guest user and therefore any access associated with it. Any user who inherited U001 Guest user permission also inherits this guest user permission pool and therefore any access associated with this pool.
PP02 External registered user permission pool	External logged in user inherits permission U002 External registered user and therefore any access associated with it. Any user who inherited U002 External registered user permission also inherits this external user permission pool and therefore any access associated with this pool. In addition to this pool, external registered user might inherit one or more relationship pools if they have active entity relationships.
PP03 Organisation access permission pool	This permission pool contains all permissions that an organisation members can potentially have. By default every new organisation created in the system will be granted all of these permissions excluding the ones with default status “Not granted”, such permissions must be manually added to the list of permissions of the selected organisation by an appropriately privileged internal user. Organisation administrators will use permissions granted to an organisation to create various access groups and determine what each member can access.
PP04 Internal user permission pool	Internal permission pool contains a collection of permissions that are available for granting to internal users via the permission groups. Internal logged in user inherits permission U003 Internal user as their user profile type is set to ‘Internal’, however there is no access associated with it. Any user who inherited U003 Internal user permission will be treated as internal and will be available in user management for adding into teams and permission groups. Adding internal users into permission groups is a way to grant them access.

For guest users and external individual users Verne determines if a user is eligible for a ‘user type’ permission pool when user session is created. For example, a guest user is granted a suite of permissions from the guest user permission pool that allows them access to public searches and viewing of companies, etc. Likewise, an external authenticated user is granted a suite of permissions from the external user permission pool that allows them access to public searches, view services as well as registration services.

Internal users do not inherit permissions from the associated pool in full, there is a layer in between the pool and the internal users called ‘Permission group’ that narrows down access of a specific internal user. More details about the permission groups can be found here Permission groups.

External organisational users do not inherit permissions from the associated pool in full, there is other layers in between the pool and the organisation member that narrow down access of a specific member. This is described here Organisations as organisation access management Level 1 and Level 2.

‘Relationship type’ permission pools

‘Relationship type’ permission pools contain permissions that allow a user to access data and services of a specific entity that a user has relationship with. “Entity” could be a user profile, a business service instance, an entity on the business register, etc. Each relationship type contains different permissions that reflect responsibilities associated with it. For example, relationship type ‘company director’ will be associated with its own permission pool that contains permissions to allow viewing of a company private data, filing entity documents and managing access of other users to this company.

Verne determines if a user is eligible for a ‘relationship type’ permission pool every time user starts a business service on a specific entity.

The following permission pools are used in Verne default product offering:

PP09 User profile owner permission pool	The permissions below are inherited by the logged on user within the scope of the specific user profile they have owner relationship with (either external or internal – it does not matter)
PP10 Owner of a professional permission pool	“Owner of a professional” relationship is when a natural person has a user profile that is linked with an entity that represents themselves (e.g. individual user is a registered professional). The permissions below are inherited by the relationship owner within the scope of a professional entity they have “Owner of a professional” relationship with
PP11 Acting on behalf of a professional permission pool	“Acting on behalf of a professional” relationship is when a natural person or an organisation have their user/org profile linked with a non-director role of an entity or in general with an entity bypassing any role association. The permissions below are inherited by the relationship owner within the scope of an entity they have “Agent of a professional” relationship with
PP12 Name reservation owner permission pool	“Name reservation owner” relationship is when a natural person or an organisation have their user/org profile linked with a name reservation that they initiated. The permissions below are inherited by the relationship owner within the scope of an entity they have this relationship with
PP13 Company director permission pool	“Company director” relationship is when a person has a user profile in Catalyst that is linked with a director registry role of an entity. The permissions below are inherited by the relationship owner within the scope of an entity they have this relationship with.
PP14 Company acting on behalf permissions pool	“Company acting on behalf” relationship is when a person or an organisation have their user/org profile linked with an Acting on behalf registry role. The permissions below are inherited by the relationship owner within the scope of an entity they have this relationship with.
PP15 Company secretary permission pool	“Company secretary” relationship is when a person or organisation has a profile in Verne that is linked with a secretary registry role of an entity. The permissions below are inherited by the relationship owner within the scope of an entity they have this relationship with.
PP16 Company other officer permission pool	“Other officer” relationship is when a person or organisation has a profile in Verne that is linked with an auditor, an accounting officer or a tax agent registry role of an entity. Note, secretaries have a different permission pool. The permissions below are inherited by the relationship owner within the scope of an entity they have this relationship with.

Permissions in the pools

Each Verne implementation will use a subset of Verne core permissions (prefixed with P***) and will define a number of their own registry template permissions. Therefore permission pools are primarily defined by the projects to suite their business requirements.

A ‘Default status’ must be specified for each permission when it is included into a permission pool. Permission that is included into a pool can be in one of the following three deafult statuses:

Inherited – such permission is always inherited from the permission pool and cannot be removed from a user who is eligible for this permission pool
Auto granted – such permission is by default inherited from the permission pool but can be revoked from a user who is eligible for this permission pool
Not granted – such permission is by default NOT inherited from the permission pool but can be granted to a user who is eligible for this permission pool

If a project is not going to use some of the Verne core permissions (prefixed with P***) then they should not include them into the permission pools. This will ensure that the functionality behind the permissions is never going to be used and that such permission cannot be granted to any user by mistake. For example, if a project does not use work queue and therefore teams, they should not include associated permissions into the internal user permission pool, so they won’t be available for granting. However they will be visible in the permissions search as read only.