Modeling permissions with roles

OmniFi provides a very flexible group system, where groups are containers for users, permissions, data source mappings and other groups. Because of this flexibility, groups can be used to model roles.

The purpose of modeling roles is to make the setup transparent and auditable by distinguishing collections of permissions (roles) from collections of users (user groups).

Rules of thumb

You can model a very flexible permission system that is transparent, auditable, and easy to maintain by following a few rules of thumb.

User groups

User groups should be spelled title case, e.g. Front Office Group to separate them from roles and users.
User groups should only contain either Users or User groups, not both, and never roles.

Roles

Roles should be capitalized, e.g. DATA-QUERYfor easy identification.
Permissions should be assigned to roles, never users or user groups.
Roles can have User and User group members, but not other roles.
Data source mappings should be with roles, unless they map to individual accounts.

Users

Users are assigned to User groups and optionally Roles.
Permissions can never be assigned directly to users.

(The OmniFi Administration allows you to assign permissions directly to users, the User Administration page in the web portal does not).

Defining roles

Roles are modeled using groups that contain permissions, extension permissions and data source mappings. As user groups are assigned to roles, the roles will also contain user groups.

The purpose of defining roles is to model only what the role has access to ion what data provider, not who does it, with enough granularity to authorize users to perform only the tasks they need to. By this definition, Accountant isn't a role. Accountants can, however, be a user group that has the role READ-ACCOUNTING-DATA.

Roles are typically modeled at least per data provider and action within that provider. Data providers include any system that you will connect to using built-in connectors, extension packages, custom extensions and direct database connections. Actions include READ and WRITE in a simplistic case, but can be much more granular depending on how user identity is handled. If you use individual accounts to connect to a data provider, authorization for different data sets is often handled by the underlying system and simple READ WRITE roles are sufficient.

If you map to aggregated accounts (map several users to the same account in the data provider), you may want to configure separate roles per data segment. As a very simplistic example, assume you use an extension package for an accounting system including queries to read and write accounting setup, like ledgers, accounts and accounting periods, as well as the actual accounting entries. Access to the actual accounting entries is likely more exclusive than reading the accounting setup, so your roles should reflect this:

ACC-SETUP-READ
ACC-SETUP-WRITE
ACC-DATA-READ
ACC-DATA-WRITE

This allows you to map access to different parts of the extension package to different roles.

Note that role permissions shouldn't overlap. ACC-DATA-WRITE shouldn't imply ACC-DATA-READ, users and groups need to both read and write accounting data should have both roles.

In addition to this, you need to model administrative roles and roles for the various OmniFi modules, e.g.

OMNIFI-USERS-ADMIN
OMNIFI-DATAMART-ADMIN
OMNIFI-API-ADMIN
OMNIFI-WEB-ADMIN

Note that it is a good practice to place all roles in a separate group for easy identification:

ROLES
- ACC-SETUP-READ
- ACC-SETUP-WRITE
- ACC-DATA-READ
- ACC-DATA-WRITE
- OMNIFI-USERS-ADMIN
- OMNIFI-DATAMART-ADMIN
- OMNIFI-API-ADMIN
- OMNIFI-WEB-ADMIN

Lastly, assign the correct permissions and mappings to each role. In this example the accounting system connector is via an extension package, so the permission Query/Extension/Enabledis required for the READ roles, whereas Automation/Extension/Enabled is required for the WRITE operations. Each role also has to be assigned permission, and optionally account mapping, to the appropriate extensions in the Extension Permissions tab of OmniFi Administration.

Defining user groups

Modeling with roles makes defining user groups more straight forward, because user groups have less impact on the permission structure.

You can for example start with your organizational chart. Note that it is a good idea to implement a root user group representing the whole organization. For a sample organization, we could for example start with:

Company Name
- Front Office
- Middle Office
- Back Office

Continuing our example, we use an accounting system and a bank connection for initializing payments, that should only be accessible to Accountants and Accounts Payable respectively. We have modeled these systems using roles, so we can add the user groups Accounts Payable and Accountants, both as part of the Back Office department and having the appropriate roles.

Company Name
- Front Office
- Middle Office
- Back Office
  - Accounts Payable
  - Accountants
ROLES
- ACC-DATA-READ
  - Accountants
- ACC-DATA-WRITE
  - Accountants
- BANK-DATA-READ
  - Accounts Payable
- BANK-DATA-WRITE
  - Accounts Payable

Note that permissions are inherited down the tree. Users further down the tree have more permissions than users higher up the tree. You need to take that into account when adding users with more than one, more senior or management roles.

When modeling with roles, it is fine to assign roles directly to users, so to handle the odd superuser, you can give them the roles required directly. Since roles are distinct, it is easy to spot that the superuser has certain roles assigned, fulfilling the transparency requirement.

ROLES
- ACC-DATA-READ
  - superuser
  - Accountants
- ACC-DATA-WRITE
  - superuser
  - Accountants
- BANK-DATA-READ
  - superuser
  - Accounts Payable
- BANK-DATA-WRITE
  - superuser
  - Accounts Payable

Note, however, that the purpose of modeling with roles is to also ease of maintenance. Adding another superuser requires assigning all the same roles to the new user, and most likely your list of roles is much longer than in this simplistic example.

In more complex scenarios, you can model functional user groups, for example Senior Back Office , and assign users and roles to the functional user group.

Company Name
- Front Office
- Middle Office
- Back Office
  - Accounts Payable
  - Accountants
  - Senior Back Office
    - superuser
ROLES
- ACC-DATA-READ
  - Senior Back Office
  - Accountants
- ACC-DATA-WRITE
  - Senior Back Office
  - Accountants
- BANK-DATA-READ
  - Senior Back Office
  - Accounts Payable
- BANK-DATA-WRITE
  - Senior Back Office
  - Accounts Payable

Yet another tempting solution is to add superuser to both Accountants and Accounts Payable. This also works technically, but for transparency your user groups should mainly reflect how you view your organization. Imagine how you would add the Head of Treasury that should have access to everything in this setup. Are they really Front Office -> FX Trader and Back Office -> Accountant etc.?