Skip to main content
Korint provides a comprehensive and flexible permissions system based on the role-based access control (RBAC) security model to ensure that users can only access and perform actions relevant to who they are. The system is built on two fixed building blocks that ship with the platform:
  • Actions — the individual operations that can be performed on Korint, such as GET_POLICY (view a policy), QUOTE_POLICY (quote a policy), STOP_POLICY (terminate a policy), or CREATE_DISTRIBUTION_REQUEST (request to distribute a product). There is a fixed catalogue of roughly 150 granular actions.
  • Built-in roles — each role bundles a set of related actions. There is a fixed catalogue of around 60 built-in roles, for example POLICY_ADMIN, POLICY_VIEWER, POLICY_QUOTER, CLAIMS_VIEWER, or DISTRIBUTION_REQUEST_CREATOR.
You do not create roles or actions from scratch — the catalogue is the same across the platform. What you configure per product is how these built-in roles are bundled into named business roles that make sense for your distribution model.

​
Business roles

A business role is a named bundle you define for a product. It combines:
  • Roles — the built-in roles it grants (for example a retail broker business role might combine POLICY_VIEWER, POLICY_QUOTER, and POLICY_SIGNER).
  • Forbidden roles — an optional subtractive list that removes specific built-in roles even when they would otherwise be granted. This lets you start from a broad bundle and carve out what a given business role must not do.
  • Customer role — a flag marking the business role as an end-customer (beneficiary) role rather than a broker role.
Because business roles are configured per product, the same product can offer, for example, a retail broker role that can quote and a support role that can only view — and a different product can be set up entirely differently. For example, you could define the following business roles for a product:
  • Retail broker: POLICY_VIEWER, POLICY_QUOTER, POLICY_SIGNER, CUSTOMER_VIEWER, PAYMENTS_EDITOR
  • Wholesale broker: everything the retail broker has, plus BROKER_ADMIN and DISTRIBUTION_REQUEST_HANDLER for distribution and network management
  • Beneficiary (customer role): POLICY_VIEWER, CUSTOMER_VIEWER

​
How access is granted to users

A user does not see every resource in the platform — only the ones they are linked to. Access flows to a user in one of two ways:
  • Directly — a relation links the user to a specific customer, for example a beneficiary who can access their own policies.
  • Through their brokerage firm — the user is linked to a brokerage firm, and inherits access to the resources that firm manages. A broker can therefore see every policy managed by their firm. Parent firms in a distribution network also see the resources of their child firms.
A connected user can perform an action only when their business role grants it and the resource is one they are linked to. This is what keeps a retail broker from seeing another firm’s policies, or a beneficiary from acting on anyone’s contract but their own.