Access to data should be precisely limited so that sensitive information and the ability to make important changes to a system are only available to roles and personnel that should have the appropriate access. Here, we discuss the permissions granted to various user roles and how to assign roles according to Airkit's best practices.

Basic Roles - Permissions by Platform Access

Airkit comes out of the box with three user roles: Admin, Developer, and Agent. These roles are defined primarily by what elements of the Airkit platform they allow access to.

Admin: The Admin role provides full access to the Airkit platform. This includes both the Studio, which is where Journeys are constructed, and the Console, which is where Org-level settings are stored and edited. Additionally, the Admin is the only role that provides the permissions required to change the roles of other users and invite new users into the Organization. The Admin role is reserved for specific roles that need to make changes at the Org-level.

Developer: The Developer role grants permission to access the Studio and all other tools required for app creation, but not to make any changes to the Organization itself. Developers will have access to all information associated with their app build, including both data saved to Airkit's internal record system as well as any information pulled from external APIs. The Developer role is given to teammates who will be using Airkit primarily for app creation.

Agent: The Agent role is the most limited role within Airkit. It is primarily given to teammates who need interact with data gathered by Airkit applications, though the data exposed to them is not raw. Agents will only be able to access data once it has been deliberately exported into another system for their use. Agents do not have any access to the Studio and do not have permission to build or edit applications. The Agent role is given to teammates who only need to access information after it has been structured and curated by developers.

For more on precisely what each of these roles has permission to access, see Managing User Roles.

As pre-configured, these roles do not limit permissions by deployment environment. Limiting permissions by environment requires creating a custom role.

Custom Roles - Role Based Access Control (RBAC)

📘

Enterprise Feature

This feature requires an ENTERPRISE license. If you would like to enable this feature for your Airkit Organization, please contact your Airkit representative or contact [email protected].

Custom Roles are created in the Console, under Settings > Roles. A new Custom Role can be created by clicking on the Create new button on the top right:

This will open an interface to define a new Custom Role in the Inspector.

Customizing Role Functionality

Base roles (Admin, Developer, and Agent) are have associated functions. Once a base role is selected, functionality can be removed to ensure the custom role only has permission to access the functionality that is required for the role.

Functionality can only be removed from a base role, not added to it. If a custom role requires functionality only available to a particular base role, then that is the base that must be used to create the custom role.

Here is the functionality that is available for each role by default. Each listed functionality has the option to be removed from the base role to create a custom role:

Customizing Environment Access

Environments provide the capability to isolate data, integrations, resources, APIs, tokens, and deployments within an Organization. Each Organization comes pre-configured with three deployment environments:

• Development
• QA
• Production

Development, QA, and Production environments are each used during their respective phases of the development cycle. This allows resources and data between them to remain isolated. If an application is meant to upload important information to an external API, for instance, it is important to be able to distinguish between dummy information sent during QA and real information collected once the application is live in Production.

Creating and managing custom roles allow you to limit builder access to specific environments. When it comes to assigning these roles, a builder should only have access to the environments and the resources associated to perform their role.

When working with a role that blocks access to an environment, the Airkit platform will behave as though that environment does not exist. For instance, resources tied to that environment will never appear for selection, and Datastores associated with that environment will be unavailable to do display in AirData Builder.

The details what environments any individual user might need to access throughout their workflow depends on the structure of their organization and the nature of their project. Builders should always have access to the environments required to get their work done – and no others.

Creating and Managing Custom Role Properties

Custom Roles are created and managed in the Console, under Settings > Roles. In addition to defining the individual permissions of the Custom Role, creating or managing a Custom Role requires defining the following properties:

• Extend Role (type: string) - the base role that will be modified to create a Custom Role. Permissions can only be removed from the base role, not added to it.
• Display Name (type: string) - designates the name of the Custom Role.
• Key (type: string) - the internal designation of the Custom Role. Must be able to be referenced in code and so cannot contain spaces.
• Rank (type: integer) - the unique rank within the Org. If a rank has been assigned to an existing Custom Role, it cannot be reused. Lower numbers have higher priority in the case of multi-role conflict.

Removing Permissions

Upon the selection of a base role, the out-of-the-box permissions will become available to modify. Some common Permissions are defined as follows:

Examples

A single custom role can be granted individualized permissions based on both environment and function. Combined, this forms a permission matrix, where a custom role might grant or deny permissions for any potential combination of function and environment. To better understand how this matrix is conceptualized, here are a few common examples.

Limited Developer

A Limited Developer has no access to the production environment and no ability to make Org-level changes. The permission matrix for a Limited Developer would look as follows:

Integration Manager

An Integration Manager is in charge of an Organization's credentials. They do not need to access the studio or edit apps, but they do need to keep track of integrations and other resources in the Console. The permission matrix for an Integration Manager would look as follows:

Inviting New Builders

New builders are added to an Org through the Console, under Invites > Create New. For a more detailed discussion on adding new users, see Adding Users to Airkit.

Assigning User Roles

New users must be assigned a role upon creation. While creating a new role, under Role, select the relevant role for the new user from the associated dropdown menu. Any custom roles that have been created will also be available for selection. For instance, in the following example, the roles for selection include the three basic user roles ("Agent", "Developer", and "Admin") as well as a custom role ("Developer Limited"), which grants Developer permissions in only the Development and QA environments:

Authenticating Builders

Airkit provides three ways to authenticate builders:

• Google SSO - requires Builder have Gmail address
• SAML - requires manual SAML configuration (defined under Console > Settings > Organization > Authentication)
• Username/password

The authentication method is selected as part of sending a new invite to join the Org. Select an authentication method based on your security requirements.