Role-Based Access Control (RBAC)

Descope provides a structured Role-Based Access Control system, allowing for granular access control. Permissions are the foundation of this system, describing specific actions and functionality a user can take. Roles are collections of permissions that can be assigned to a user. For example, there could exist an “Admin” role with permissions to create, update, and delete other users.

Creating, updating, assigning, grouping, and deleting roles and permissions is done through Descope's UI, SDKs, or APIs, with specific instructions on how to do so in our Authorization Page.

Use Case Example

Now, to better understand how to implement RBAC with Descope, let's dive into a use case example.

Imagine running a SaaS company, providing a software-as-a-service platform to other businesses. This platform is designed to streamline e-commerce operations and amplify brand engagement.

The platform has thee main features including:

1. Digital Storefront: Assists businesses in crafting an online presence, cataloging products, and processing sales.
2. Customer Relations Manager (CRM): Designed to track customer interactions, purchases, and feedbac.
3. Brand Amplifier: Aids in crafting, scheduling, and distributing promotional content across various digital channels.

Recognizing the importance of granular access control, you integrate Descope into your solution. Without Role-Based Access Control (RBAC), employees across client businesses would have a free run of the platform, potentially complicating operations, especially in businesses where tasks are department-centric.

Digital Storefront

For the Digital Storefront module, permissions are created such as:

• read-product-details
• edit-product-pricing
• process-online-orders

To manage these permissions, the role “Digital Store Supervisor” is conceived.

CRM

Transitioning to the CRM module, we see permissions like:

• view-customer-history
• annotate-customer-feedback
• generate-sales-report

This brings forth the role of “Customer Insights Analyst.”

Brand Amplifier

Lastly, the Brand Amplifier module encapsulates permissions like:

• draft-promotional-content
• schedule-brand-campaign
• analyze-engagement-metrics

Consequently, a role named “Brand Strategist” emerges.

Assigning Roles to Users

Now, consider a scenario: A business onboarded to your platform designates Dylan to oversee their e-commerce wing. Dylan is provided the Digital Store Supervisor and Customer Insights Analyst roles, granting him a spectrum of permissions from the two modules. However, since marketing is not his forte, he isn't assigned the Brand Strategist role, ensuring he remains focused on his domain.

On the backend, when Dylan logs into your platform, Descope seamlessly authenticates and authorizes him, embedding the required permissions within the Access Token. Your software, by interpreting this token, ascertains which modules and features Dylan can access.

Conclusion

Thanks to Descope's efficient RBAC, your platform gains robustness without the need for internalizing authorization mechanics. As roles within client businesses evolve, permissions can be effortlessly realigned.

Moreover, to cater to growing clientele and diversifying roles, Descope's SDKs and API offers the potential of crafting a self-service portal. This in-platform feature could empower businesses to sculpt and manage their RBAC, further refining operational efficiency.