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 require access. Here, we discuss the permissions granted to various user roles, how Custom Roles can be used to ensure each user has access only to what they need, 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 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].

In addition to providing out-of-the-box roles, Airkit also provides the tools to make Custom Roles. This allows access to data and editing permissions to be granted precisely and only to the people that require access to them. Here, we discuss how Custom Roles can be used to keep your Organization secure. For a more technical discussion on how Custom Roles are created and managed, see Working with Custom Roles.

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.

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 two ways to authenticate builders:

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

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.