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 consequently have a flexible approach to service delivery (e.g., adding features to users when their feature bundle changes).
The Entitlements Engine is built atop the
isEntitledTo query, and is used to allow and/or limit user access across your app by granting them specific roles, permissions, feature access, and more. To understand the interplay between the different entitlements features, here's a quick recap that clarifies the relationship between them:
Roles: Roles are linked to Permissions. If a user has an Admin role, for example, the role will include permissions that frame the role-holder access. When the user receives a role, he automatically receives the role's associated Permissions (e.g., Read, Edit, Delete, etc.)
Permissions: Permissions frame what a user can or can't do in your app, e.g., Read, Write, Delete, etc. You can also link permissions to Features, and decide that a feature will include the desired permissions (e.g., read, write, delete, etc.).
Plans:Plans are built on Features. After creating features, you can add them to a feature plan.
Feature flags: Feature flags are associated with Features. There can only be one flag per feature, though. Flags are associated with attributes. This topic will cover all you need to know to set and customize feature flags.
The engine is divided into four distinctive areas that control a user's access to data:
- 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.
- 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.
- 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.
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 Protecting Backend APIs.
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.
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.
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.
Let’s assume that your code currently protects this feature with an
To create a user entitlement in the Frontegg portal you will need to perform the following actions:
- Create a permission with an
sso.readkey (check the Permissions guide for more information).
- Add an
sso.readpermission to an existing role or create a new role using that permission.
- Assign the role to user X.
- Add an
- Create a Feature. For the sake of the example, let’s call this feature User SSO. (check the Feature guide for more information)
- Link the
sso.readpermission to User SSO .
- Link the
- Create a Plan e.g., “Basic Bundle”, and add User SSO to it.
- Add the feature to the new bundle.
- Assign feature bundle to user X.
When a user tries to perform an
sso.read permission, Frontegg runs the following logic:
- Does the user have an
sso.readpermission? (this information is derived from the user’s Roles.
i. If ‘No’, the user will be denied.
ii. If ‘Yes’ —>
Frontegg will subsequently check for features linked to said permissions in the portal.
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.
Updated 22 days ago