Users and groups add a level of granular control and security within Otter. By associating users with a groups, and associating users and groups to external directories, organization are able to permit and restrict access to certain tasks with ease.
Managing users and groups is an Otter Enterprise feature.
A user directory is a collection of users and groups that Otter can query. Currently, Otter supports three types of user directories:
Directories are exclusive; meaning you can only use one at a time. For this reason, it’s important to make sure you will have sufficient administer permissions in Otter for the user directory you are switching to. If you do accidentally lock yourself out, don’t worry; you can easily run the Otter.Service.exe program, and select the reset to Built-In option.
Otter gives you the option to grant permissions and restrictions using the Built-In directory.
Four groups are initially configured in Otter’s Built’In directory: Administrators, Configurers, Orchestrators, and Viewers. These groups can be deleted and additional groups added as organizational structure demands.
Otter allows you to create and customizes as many tasks as needed. Tasks in Otter define the specific ability, access, and functions users or group are allowed to edit, create, and view. Otter comes built-in with four tasks out of the box: Administer, Configure Environment, Orchestrate, and View Environment. Built-in task can be edited and modified but it’s important to note that future updates may affect these built-In tasks.
Administrators can assign restrictions and permissions based on a group and individual users. It’s important to note that permissions are additive and restrictions override permission when they’re at the same level; the more specific personnel (One user vs. Group) or a more defined scope (integration vs. all environments) always override.
For example we have a user Rick who’s a member of the Configures group, all users in this group have been given the permission to “Configure Environment” for all environments except production. Rick however, is the only user with the permission to configure the Production environment. Because he’s part of the Configurers group and permission are additive, he has permission for all environments including production.
Whereas Carol is a member of the Viewers group meaning she only has access to view and not change; however, she has also been given the permission to configure the Integration Environment. Permission are additive so she has the permission to view environment AND Configure Integration environment.
Often times organizations have more than one group responsible for similar task but ultimately a member of a specific group has final control. In this example there are two groups of Users who have the ability to Configure Environments, ConfiguresA and ConfiguresB. However, only those in ConfigurersA are able to configure the production environment.
API Keys are designed to grant access to other tools and integrations. You can control which functionality a key may be used for, and delete keys that are not used.
Granting access to the Native API will effectively allow for full control of the instance
To assist with debugging API usage, the request/response is logged whenever an API endpoint is accessed with a key. These logs are not retained indefinitely, but are automatically purged.