Entitlements overview

Overview

The Frontegg Entitlements Engine allows businesses to control their users' access to specific features or functionalities based on their designated user entitlements. Thanks to the engine, you can control accounts and levels of data-access and thus have a flexible approach to service delivery (e.g., adding features to users when their feature bundle changes, for instance).

Main use cases for Entitlements Management:

1. User Entitlements: User entitlements define the level of access a user has based on their subscription plan or specific permissions granted. Entitlements can range from basic feature(s) access, handpicked set of features to full feature access.
2. Subscription Plans: Subscription plans in B2B SaaS platforms are typically tiered, offering different levels of service to customers. Frontegg's Entitlements Engine can help you ensure your users gain access only to specific features included in their subscription plan.
3. Feature Availability: The availability of features can also be controlled via the Entitlements Engine— i.e., which features are open to higher-tiered subscription plans, and which are accessible to all users— simply by enabling or disabling them for specific customers or user groups.

Utilizing the Entitlements Engine vs. Traditional RBAC

While basic RBAC provides a framework to access control and should be used, the Entitlements feature management increases access granularity, personalization, revenue optimization, and agility. All of these can empower SaaS platforms to offer tailored user experiences, monetize their offers more effectively, and maintain strong security.

📘

Maintaining RBAC approach

You can always maintain the RBAC approach using. Learn more about protecting your backend routes here.

The Entitlements Engine API

The Entitlement flow is based on a single API call that checks whether a user is entitled to perform a specific action within your application, or denied from doing so. The response is a boolean that subsequently affects the continuation of the flow.

The simplicity of the flow means that the developer is only required to set the feature-access functionality within the application, while the rest can be managed via the Frontegg portal by different stakeholders in your business, i.e., Product, CS, or Sales departments. Ongoing management doesn't require knowledge of code.

The Engine's Core Components

The Entitlements Engine is built on four core components:

• User Roles: such as Admin, Editor, etc. Each role entails specific permissions.
• Permissions: read, edit, access to specific areas, etc. Permissions affect the usability of the app by your users.
• Feature: features are resources in your app that you’d like to protect or grant access to certain users (via feature bundles). Based on your use case, you can customize and tailor them to your needs.
• Feature bundles: feature bundles can include a stack of features or a single feature, and can be assigned to specific users/accounts. Subscription plans are an excellent example of such usage.

Granting Users with Feature Access

Based on the four concepts above, the Entitlements Engine gathers the different variables to makes a decision whether a user is entitled to access a feature, or not:

Users can receive access based on their role, and this access can be limited by the features they are can access if they are associated with a feature bundle. Refer to the use cases below to learn more.

Use Cases

Protecting SSO Connection in your Application

To clarify the flow, let’s take an example where a user wants to set up a new SSO connection (i.e., a feature ) in your SAAS application.

Your End

Let’s assume that your code currently protects this feature with an sso.read permission.

To create a user entitlement in the Frontegg portal you will need to perform the following actions:

1. Create a permission with an sso.read key (check the Permissions guide for more information).
   1. Add an sso.read permission to an existing role or create a new role using that permission.
   2. Assign the role to user X.
2. Create a Feature. For the sake of the example, let’s call this feature User SSO. (check the Feature guide for more information)
   1. Link the sso.read permission to User SSO .
3. Create a Feature Bundles, e.g., “Basic Bundle”, and add User SSO to it.
4. Add the feature to the new bundle.
5. Assign feature bundle to user X.

Frontegg's End

When a user tries to perform an sso.read permission, Frontegg runs the following logic:

1. Does the user have an sso.read permission? (this information is derived from the user’s Roles)

i. If ‘No’, the user will be denied.

ii. If ‘Yes’ —>

1. Frontegg will subsequently check for features linked to said permissions in the portal.

2. Frontegg will check if the user is granted to feature-access as a part of a Feature Bundles. If ‘yes’, the user will be entitled to access the_ User SSO _feature. (see note)

📘

Linking between permissions and features

While permissions can be linked to one or more feature(s), if a user is granted access to at least one feature, they will be granted with the permission as well.