Last updated

User management architecture

Frontegg is designed to simplify how businesses handle access to their applications, offering multiple authentication options with great flexibility and customizable features to meet various business needs. Frontegg's model is built with three key players that utilize its services: environments, accounts, and users. Let's get to know each and the interplay within them.


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, i.e users with Admin and Backoffice roles have highest level of access and can configure and devise advanced security and authentication aspects for their customers (i.e., their end users), and do so in 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 view. Account configurations are devised by the environment.
  • Sub-account: Sub-accounts are accounts that are part of 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 end-customers on the environment and the direct users of accounts. When working 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 every environment, have the flexibility to add accounts, enable/disable features, set advanced system configuration e.g., JWT expiration, IP restriction, and more. Frontegg portal users can also enable/disable features for their account's usage, e.g., their account's ability to send user invitations, authenticate their users via social login methods, generate user tokens, etc.


accounts

Accounts and sub-accounts

Important

Note that Tenants equal Accounts. A User must be a member of at least one account (tenant).


Frontegg Accountsare accounts nested under the environemnt in the Frontegg portal. Frontegg portal users add users to accounts (tenants) on each environment via Frontegg's management (in the Frontegg portal) or via APIs. Users can 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 configuration as well as the entire hierarchy, 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 idea is to have the utmost flexibility to control and adjust the model to various use cases. Sub-accounts refer to the third layer of accounts and onwards. Sub-tenancy can help intricate business models manage multiple accounts and user layers. In this hierarchical business model, the environment, which stands atop 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 Frontegg environment and the direct users under of 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/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 accross all accounts.

Scopes of each persona

Environment capabilities

  • Designated APIs, dependent on creating a environment token that must be used for these APIs.
  • Multiple environment access and control. Advanced configurations (security, authentication, authorization, and more) can be configured for each environment for utmost control.
  • Control over the entire cascade of accounts and users.

Account capabilities

  • Account scope is defined by 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 identical to account's, and are defined by the environment.

User capabilities

  • Users are authorized or devoided 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.