Overview

How Entitlements Work

Entitlements management is a critical aspect of identity and access management (IAM) that involves defining, allocating, monitoring, and updating user access rights within an organization. This process ensures that the right individuals have access to the right resources at the right times for the right reasons, enhancing security, compliance, and operational efficiency. In Frontegg, those are divided to the following core capabilities:

What are Frontegg's Entitlements?

Frontegg Entitlements are based on IAM (Identity and Access Management) concepts, which usually encompass a broader framework of policies, processes, and technologies that manage digital identities and control access to resources within an organization. IAM systems ensure that the right individuals have the appropriate access to technology resources, enhancing security and operational efficiency.

Entitlements are part of the Access management part of IAM, which allows the control of users' access to specific features or functionalities based on the access to resources you allocate for them.

The Agent and Policy Decision Point (PDP)

The Entitlements Agent is a Policy Decision Point (PDP), a microservice designed to efficiently handle entitlement queries. It evaluates policies quickly and receives real-time updates with the latest configurations, eliminating the need for code changes or redeployments. This approach decouples the scaling of policy logic from your application code, allowing you to scale the Entitlements Agent independently as needed.

The PDP is responsible for making authorization decisions based on attributes from the input request, external data sources, and the policy itself. This combination results in an authorization decision, such as permit or deny, which is enforced by the Policy Enforcement Point (PEP). The Entitlements Agent ensures that these decisions are made efficiently, minimizing the impact on the application's memory or CPU performance.

In summary, the Entitlements Agent and its role as a PDP contribute to efficient handling of entitlement queries and real-time updates.

Scope of access

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:

Role-Based Access Control (RBAC) is a part of the engine that allows you to assign user access rights based on their roles within the organization. This method simplifies the management of user privileges, especially in large organizations, by grouping permissions into roles that can be easily assigned and managed. RBAC cover Permissions and Roles.

Plan Management involves defining different subscription plans or tiers, each with specific access rights and features. Plans are built atop Features. After creating features, you can add them to a feature plan.

Feature Flags allows you to dynamically enable or disable Features for specific users or groups, providing flexibility in managing access to new or experimental features.

API Access Control protects API endpoints by managing which users or systems can access specific routes. This method reduces the need for developers to manually protect each route in the application code and can be fully achieved by creating policies.

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.)

Entitlements Engine Features

The engine is divided into four distinctive areas that control a user's access to data:

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 Protecting Backend APIs.

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 Plans). Based on your use case, you can customize and tailor them to your needs.
• Plans: Plans 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 brings together the different variables to makes an informed decision on 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 plan. Refer to the use cases below to learn more.

Use Case: Protect Your Application's SSO Connection

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 Plan e.g., and add User SSO to it.
4. Add the feature to the new plan.
5. Assign feature plan 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 Plan. 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.