RBAC Overview

Role-Based Access Control (RBAC) is a method of managing and controlling access to resources based on the roles and responsibilities of users or entities within an application. Access permissions are tied to roles, and those roles are assigned to users or entities. This ensures that only authorized users or entities have access to sensitive information and helps to prevent unauthorized access. Application or tenant administrators can manage access to resources in a centralized yet flexible manner from the Wristband dashboard.

Types of Authorization Checks

💡

When it comes to validating access to your application's resources, the authorization decision should be made within your own application's code.

You have two options for determining whether a user or entity is granted access to a resource: role-based authorization and permission-based authorization.

In practice, many applications use a combination of both roles and permissions to strike a balance between ease of management and fine-grained control. Roles can provide a high-level organizational structure for access control, while permissions offer flexibility for specific actions and use cases.

Role-Based Authorization

When conducting authorization checks, your application will examine the roles assigned to a user or entity engaging with the application and ensure that the necessary role or set of roles is present for a successful access request. Individual permissions, if any, associated with those roles will not be individually scrutinized.

📘

Optional Permissions

In Wristband, the association of permissions with roles is discretionary. For straightforward security needs, it is possible to establish roles for your Wristband application without any associated permissions.

Permission-Based Authorization

When conducting authorization checks based on permissions, the emphasis is on individual permissions that define the actions permitted on resources. This method provides greater granularity and flexibility, allowing precise definition of access rights at the individual action level. In Wristband, users or entities may not be directly linked to permissions. Therefore, your application must retrieve all permissions assigned to their roles before performing the authorization check. To ensure authorized access, your application must verify that each expected permission for a particular resource is associated with the user or entity at that specific moment.

Where to Perform Authorization Checks

Security requirements vary from one application to another. Authorization checks are typically conducted in two key areas: your frontend user interface (UI) and the API layer.

UI Authorization

Before rendering any part of your application's frontend UI, it is crucial to determine whether the end user attempting to interact with the application should have visibility to the content. This practice typically involves either concealing entire sections of the interface or displaying partial sections accompanied by informative messages to prevent the user from inadvertently attempting actions that their level of authorization restricts.

API Authorization

UI authorization by itself is often not adequate for protecting application resources. If the application exposes backend APIs, then the APIs can be accessed directly, bypassing any authorization checks in the UI layer. Therefore, if external APIs are exposed, authorization checks must also be performed by the APIs themselves.

If your application determines that API access is unauthorized, the standard response it should provide to the API caller is an HTTP 403 error code.

Accessing Roles and Permissions During Authorization

Since authorization checks need to happen in real-time within your application, you will need a place to store roles and/or permissions in your application for efficient access.

Roles

For end users that authenticate via the Authorization Code Flow, you can specify the roles scope during the authorization request to Wristband. This tells Wristband to return the roles claim within the ID token that gets returned from the Token Endpoint. The user's roles can then be stored in your application's session store for the duration of that user's application session.

You also have the option of calling Wristband's APIs to retrieve roles assigned to a user or Machine-to-Machine OAuth Client at any time.

• For end users, you can call the Get Roles Assigned to a User API
• For M2M clients, you can call the Get Roles Assigned to a Client API

There are tradeoffs for each of those two approaches, and determining the best approach for your application is context-dependent. Some applications may want changes to role assignments to be immediately reflected in the application once the change is made. In this case, the application should call APIs at the time of any authorization checks. The drawback of this approach is the potential for increased network communication, which may result in a performance impact on the application. Conversely, when prioritizing performance, it is advisable to cache roles, even if it means that the application might not always reflect the most up-to-date role state.

Permissions

Wristband does not support the ability to add permissions into the claims of an ID token. Best practices suggest that ID tokens should be compact and efficient. Including a large number of permissions in a token can increase its size, leading to performance issues, longer response times, and potential issues with token transmission over the network.

Instead of storing all permissions in tokens, Wristband takes the more scalable and secure approach by providing a reference or identifier (e.g. userId, clientId, or roles) in the token that can be used by your application to request information about the user's permissions from Wristband when needed. For that, your application or service can call the Get Permission Info for Subject API. Once fetched, the permissions could be cached in your application or service.

Like roles, there are tradeoffs on which approach to take when storing and accessing permissions, and determining the best approach for your application is context-dependent. Some applications may want changes to permission assignments to be immediately reflected in the application once the change is made. In this case, the application should call APIs at the time of any authorization checks. The drawback of this approach is the potential for increased network communication, which may result in a performance impact on the application. Conversely, when prioritizing performance, it is advisable to cache permissions, even if it means that the application might not always reflect the most up-to-date permission state.