Last updated

User management architecture

Frontegg is designed to simplify how businesses manage access to their applications, offering multiple authentication options with great flexibility and customizable features to meet various business needs. Frontegg's model consists of three key components that utilize its services: environments, accounts, and users. Let's explore each of these and their interplay.


Get to know the key personas

Before diving into each, here is a general overview of the main personas using Frontegg:

  • Environment: Environment tokens and users who have access to the environments in the Frontegg portal. Users with Admin and Backoffice roles have the highest level of access and can configure and implement advanced security and authentication features for their customers (i.e., their end users), across multiple environments (development, staging, QA, and production). Environments control advanced configurations and the visual interface of the accounts in each environment.
  • Account: Accounts (tenants) are end-user accounts. Accounts can add and manage users via their self-service portal. Account configurations are defined by the environment.
  • Sub-account: Sub-accounts are accounts within a hierarchical business model that allows for sub-account management. Note that sub-account capabilities must be enabled for the parent account. See Hierarchies (Sub-account Management) for more information.
  • User: Users are the end-customers of the environment and the direct users of accounts. In a hierarchical model, an admin user in tenant A, for example, may also be able to make changes in the sub-accounts of tenant A and their subset users. User Permission scope is defined by the user's Role.

architecture

Environments

Frontegg Environments refer to Frontegg's 'direct' customers. Frontegg portal users can configure settings in each environment, with the flexibility to add accounts, enable/disable features, and set advanced system configurations, such as JWT expiration, IP restriction, and more. Frontegg portal users can also enable/disable features for their account's usage, such as the ability to send user invitations, authenticate users via social login methods, generate user tokens, and more.


accounts

Accounts and sub-accounts

Important

Note that Tenants are equivalent to Accounts. A user must be a member of at least one account (tenant).


Frontegg Accounts are accounts nested under the environment in the Frontegg portal. Frontegg portal users add users to accounts (tenants) in each environment via Frontegg's management (in the Frontegg portal) or via APIs. Users can also add additional users to their account (tenant) via the self-service (Admin portal).

While users are the direct customers of Accounts, Frontegg portal users control both account configurations as well as the entire hierarchy, extending down to the farthest end users.

Sub-accounts

Sub-accounts are nested within existing accounts (tenants). Note that users can have admin capabilities to control sub-accounts and their users. While it may sound complicated initially, the goal is to provide maximum flexibility to control and adjust the model for various use cases. Sub-accounts refer to the third layer of accounts and beyond. Sub-tenancy can help complex business models manage multiple accounts and user layers. In this hierarchical business model, the environment, which sits at the top of all hierarchy layers, must enable the sub-tenancy capability for its tenants before they can add accounts under their scope. Learn more about facilitating sub-tenancy here.

Users

Users are the end-customers of the Frontegg environment and the direct users under accounts or sub-accounts. Since the tenancy 'model' is built hierarchically, an admin user of account A, for example, may also have permission to add or delete users nested under account A's sub-account. Users are defined by their Roles and associated Permissions.


Users belonging to multiple accounts

Users can be associated with different accounts nested within the same environment while still maintaining their user ID and information across all accounts.

Scopes of each persona

Environment capabilities

  • Designated APIs, which require creating an environment token to be used for these APIs.
  • Multiple environment access and control. Advanced configurations (security, authentication, authorization, and more) can be configured for each environment, ensuring utmost control.
  • Control over the entire cascade of accounts and users.

Account capabilities

  • Account scope is defined by the environment configuration.
  • Self-service portal configurations and user management.
  • Multiple actions can be performed via the Frontegg portal UI or via API.
  • Ability to assign user roles and permissions.
  • Ability to add sub-accounts as part of a multi-tenancy model (if enabled on the environment).
  • Account use API Tokens for performing API requests.

Sub-account scope

Sub-account capabilities are the same as those of accounts and are determined by the environment.

User capabilities

  • Users are authorized or restricted from performing actions in your app according to their designated Permissions and Roles.
  • User tokens are used when performing user-related API requests.

Frontegg's portal access by role

The following roles can be assigned to grant access to the Frontegg portal:

RoleDescription
AdminThe Admin role provides the highest level of access, including comprehensive read and write permissions to all resources within the Frontegg portal. This role empowers users to fully manage accounts, users, and advanced security settings across all environments.
Backoffice editorThe Backoffice Editor role enables users to perform user management tasks, such as creating, deleting, blocking, and managing all users and accounts.
Backoffice viewerThe Backoffice Viewer role offers read-only access to users, accounts, and logs, making it ideal for users who need to monitor and review information without the ability to make changes.
Entitlements editorThe Entitlements Editor role allows read and write access to roles, permissions, features, feature flags, plans, and API access control, while also including Backoffice Viewer capabilities but excluding access to security and authentication settings.
Entitlements viewerThe Entitlements Viewer role provides read-only access to roles, permissions, features, feature flags, plans, and API access control, along with all capabilities of the Backoffice Viewer role.
ImpersonatorThe Impersonator role allows users to impersonate others for troubleshooting or support purposes and must be combined with the Admin, Backoffice Editor, or Backoffice Viewer roles.