Roles

System Roles

Netography offers four default roles, which any user or API key can be assigned. These roles are:

• System Administrator admin
  This role has full management privileges for all aspects of the portal and API. For resellers, this role can masquerade as a System Administrator in a sub account.
• Operational Manager operational_manager
  This role has management privileges for all aspects of the portal and API, except Account and Security based settings. Meaning they are an admin for everything except creating roles, users, SSO config and API Keys. For resellers, this role can masquerade as an Operational Manager in a sub account.
• Report User report_user
  This role has management access to dashboards, but can not edit any other aspects of the portal nor API (threat models, devices, integrations, users, API Keys, etc.). For resellers, this role can masquerade as a Report User in a sub account.
• Read-only User readonly
  This role only has view/get privileges for all aspects of the portal and API. For resellers, this role can masquerade as a Read-only user in a sub account.
• NetoFlow User neto_flow
  Role specifically for the NetoFlow Connector. It has no other portal nor API permissions, other than to send the flow to Netography.

❗️

You must have at least one user with the System Administrator role at all times.

Custom Roles

In addition to the predefined system roles, custom roles can be created which give admins the ability to override default access settings, providing granular control over which capabilities a user or API key can manage in the portal and API.

Access controls can either be set per class of objects in the portal and can either be readonly, or a combination of management criteria: create, update and/or delete(checkboxes for these options appear when you toggle a permission from read-only to manage).

🚧

When using SSO, be sure to add these custom roles to the SAML Attribute role mappers.

For accounts with sub-account management enabled, custom roles can also enable or disable masquerading into the sub-accounts.  However, any user that is assigned a custom role, and masquerades to a sub-account, will assume the admin role for the sub-account.

Note that the current Fusion roles provide read-only access to all aspects of the system for all users. In an upcoming release, you will be able to remove read access from each permission as well to enable full CRUD role-based access control.