Use case: Granular admin portal access

The Entitlements Engine offers multiple ways to control user access to designated Features/content granularly. The engine allows you to control your user's access to various admin portal capabilities via your Frontegg Portal. You can limit which sections your users can see in their Admin Portal and their permissions within those sections— For instance, you can assign users with a Read Only or Edit permissions (table of permissions can be viewed here. By creating a Feature Bundle inclusive of the specific features you pick, you can create dedicated subscription plans, and also upsell features for current users.

🚧

Prerequisites

To use the functionality, make sure you have the following versions installed:

Nextjs v8.0.4
Vue v3.0.4
Angular v6.4.0
React v6.0.4

Entitling User Access to Specific Admin Portal Areas

To harness the power of this ability and assign your users access to specific Admin Portal areas, do the following:

Step 1: Enable Entitlements in your SDK

Your first step would be to enable the Entitlements Engine in your frontend Entitlement SDK. Choose your tech stack from the main menu under Frontend SDKs. Each SDK includes an Entitlement Integration SDK.

entitlementsOptions={{
    enabled: true }}

Step 2: Create Dedicated Features and Feature Bundles

  1. In your Frontegg Portal, go to your environment, choose the Entitlements tab, and then Features.
  2. Create Features for each section of the Admin portal you wish to protect. Should you wish to limit access to Single Sign On (SSO) for instance, do the following:
    1. Go to Add new feature give it a Key name and save it.
    2. Go to the Plans tab and create a new Plan. Add the feature you created previously to that bundle.
    3. Assign all the users that you wish to grant access to this feature. Click Save.
    4. Go back to the SSO feature and add the relevant permission to it (in this case - fe.secure.read.samlConfiguration). Check the Supported Permissions section below to see all supported permissions.

    5. Once this step is done, users who didn’t get access to the feature (via the Feature Bundle) will not be able to see this section in the Admin portal.

📘

Important note

Users that were entitled to write or delete SSO will still be able to do so via API, even if they are not assigned to this feature via the bundle and in that case it will not be visible to them in the Admin Portal.

Supported Permissions

The following chart lists the permissions that users can be assigned and their corresponding location in the Admin Portal.

Permission keyPermission descriptionAdmin portal section
fe.secure.read.accountSettingsRead account settings pageAccount details
fe.secure.write.accountSettingsWrite account settingsAccount details
fe.secure.read.tenantApiTokensRead Tenant API tokens pageAPI tokens
fe.secure.write.tenantApiTokensWrite Tenant TokenAPI tokens
fe.secure.read.groupsRead Groups pageGroups
fe.secure.write.groupsUsersWrite Groups permissionsGroups
fe.secure.delete.groupsUsersDelete Group usersGroups
fe.secure.delete.groupsDelete GroupsGroups
fe.secure.write.groupsWrite GroupsGroups
fe.secure.write.groupsRoleshasWritePermissionGroups
fe.account-hierarchy.write.subAccountWrite subaccountsMSP
fe.account-hierarchy.delete.subAccountDelete subaccountsMSP
fe.account-hierarchy.write.subAccountAccessWrite subaccounts detailsMSP
fe.secure.read.userApiTokensRead user API tokensPersonal tokens
fe.secure.delete.userApiTokensDelete user API tokensPersonal tokens
fe.secure.write.userApiTokensWrite user API tokensPersonal tokens
fe.secure.read.provisioningConfigurationRead provisioning configurationsProvisioning
fe.secure.write.provisioningConfigurationWrite provisioning configurationsProvisioning
fe.secure.delete.provisioningConfigurationDelete provisioning configurationsProvisioning
fe.secure.read.securityPolicyRead security and privacy and security pagesSecurity all
fe.secure.read.emailDomainRestrictionsRead email domain restrictionsSecurity - Email
fe.secure.write.emailDomainRestrictionsWrite email domain restrictionsSecurity - Email
fe.secure.delete.emailDomainRestrictionsDelete email domain restrictionsSecurity - Email
fe.secure.read.ipRestrictionsRead IP restrictionsSecurity - IP
fe.secure.write.ipRestrictionsWrite IP restrictionsSecurity - IP
fe.secure.delete.ipRestrictionsDelete IP restrictionsSecurity - IP
fe.secure.read.samlConfigurationRead SSO configurationsSSO
fe.secure.write.samlConfigurationWrite SSO configurationsSSO
fe.secure.delete.samlConfigurationDelete SSO configurationsSSO
fe.secure.read.samlDefaultRolesRead SSO default rolesSSO
fe.secure.write.samlDefaultRolesWrite SSO default rolesSSO
fe.secure.read.usersRead Users pageUsers
fe.secure.delete.usersDelete usersUsers
fe.secure.write.usersWrite usersUsers
fe.secure.write.updateUserWrite user updatesUsers
fe.secure.delete.usersRolesDelete user rolesUsers
fe.secure.read.rolesRead users rolesUsers
fe.secure.write.usersRolesWrite users rolesUsers
fe.secure.write.resendActivationEmailResend activation emailUsers
fe.secure.write.tenantInvitesCreate invitation linkUsers
fe.secure.*Secure generalUsers
fe.secure.write.enableDisableEnable/disable userUsers
fe.connectivity.read.webhooksRead webhooks pageWebhooks
fe.connectivity.write.webhookWrite webhooksWebhooks
fe.connectivity.delete.webhookDelete webhooksWebhooks
fe.secure.read.auditsRead auditsAudit logs

Entitling User Access Based on AuthorizedContent

In addition to user Entitlements - which grant users access to specific app Features, Feature flags , etc. - you can also control user access to specific areas in your app based on their role. To do so, the system will first check their login status (logged-in/out), redirect logged-out users back to the login page, and if the user is already logged in, it will check their designated Role against the content they're allowed to view and showcase that corresponding content.

🚧

Feature Support

The following feature is currently supported in React only.

To do so, you need to wrap the content you want to protect with an AuthorizedContent component. That component has a requiredRoles prop that you pass as an array of role-names into.

Before showing the user any content, the AuthorizedContent component checks the user's role against the list of required roles for the content you wrapped in advance, and subsequently, It will show the content associated with the role that user was entitled to.

import { AuthorizedContent, useAuthUser } from "@frontegg/react";

function App() {
  // This will redirect to login in case we are not logged in
  const user = useAuthUser();

  return (
    <div className="App">
      Logged in as {user?.name}

      <AuthorizedContent requiredRoles={['Admin']} >
          <div>
              Private area for admins
          </div>
      </AuthorizedContent>
    </div>
  );
}

export default App;

Redirecting Users to Login

When a user tries to access specific app areas, but the system identifies that they are not logged in, you can enact a useAuthUser hook that checks whether a user is logged in or not. In case the user is not logged in, the hook will redirect them back to the login page. If the user is logged in (as in the code sample below), the component will then display a Logged in as alongside the user's name instead of redirecting them.

import { useAuthUser } from "@frontegg/react";

function App() {
  // This will redirect to login in case we are not logged in
  const user = useAuthUser();

  return (
    <div className="App">
      Logged in as {user?.name}
    </div>
  );
}

export default App;