Authorization and Permissions
This document covers the extensive and robust permissioning capabilities available within the Taloflow platform for customized access and control schemes.
Overview
Taloflow provides robust permission and security features, offering fine-grained permissions for implementing Role-Based Access Control (RBAC) and customized access and control schemes. The permissions and security components include user authentication through Auth0, centralized authentication verification via an Open Policy Agent (OPA) server, and separate authorization for every API request through OPA.
The system enforces the process using encrypted JWT tokens and a common library across the Taloflow codebase. External requests are first provided with an Auth0 token, which the system verifies. Then, an internal token with revised scopes is provided for the requested action. Services within the system use this internal token and their service identity to verify that the request is within the scope of permissions.
Taloflow's permission system is highly flexible, allowing for a wide range of permissioning structures, including placing users into groups, attaching permissions at both group and user levels, and restricting access at the resource level. Additionally, the system enables the implementation of data filtering when necessary and requires proper authorization tokens of the service and the user for any request authentication.
Permission System Implementation
The Taloflow permission system consists of the following components:
Policy Database: Policies are attached to principals and resources through their IDs. A policy contains:
An action (allow or deny)
A list of principals
A list of resources
A set of conditions
Rego Rules: Rules written in Rego enforce the policies.
OPA Server Implementation: The OPA server provides a fast and efficient way to analyze the rules database. It communicates with the rest of the system to obtain information about resources and principals.
Security Libraries: Libraries enforce security mechanisms at the server level, generally as transparent middleware to the developer, reducing the chance of developer error.
Key Points of the Permission System
User Data Security: User information is safely stored in Auth0. Taloflow does not use passwords, email addresses, or other personal information in the permissioning process.
Mandatory Authentication: All user requests on every server and to every API must be accompanied by a verifiable, encrypted token. While not technically "zero trust," the assumption is that no communication, even behind the firewall, can happen without some trust element in the request.
Centralized Authentication and Authorization: All decisions are centralized into a set of OPA servers. This ensures consistent permissions and minimizes timing differences and developer errors. Scopes are consistently granted, and the risk of a centralized failure is considered worth the benefit of consistent decision-making.
Flexible Rego Rules: Rego offers the ability to create flexible rules that can be easily updated. Centralized permissioning means services do not need to implement specific rules, as actions are impacted directly in OPA with ALLOW or DENY returns. This enables responsiveness to individual security needs.
Granular Authorization: Requests can be authorized at almost any level in the system. While most authorization currently happens at the API level, method-level or even within-method-level authorization can be easily implemented. This allows for restrictions on specific data entries or other low-level information if necessary.
Permissioning Logic Implications
Taloflow's permissions system is very flexible and allows for a wide range of permissioning structures:
User Groups: Users can be placed into groups. In addition to Taloflow's standard role groups, custom groups can be established. Permissions are attached to both groups and users, allowing limitations or grants at both levels. Taloflow offers Admin and Member role groups for workspaces and Owner, Editor, and Viewer roles for evaluations, supporting a traditional RBAC scheme.
Fine-grained Permissions: Every API call in the system is authorized through OPA, allowing for data filtering when needed.
Security Against Bad Actors: OPA authenticates any request it receives to verify that the sender is authorized. For any bad actor to succeed, the service and the user must have a proper authorization token.
Policy Evaluation Logic
Taloflow assumes that all requests are DENIED unless a rule allows them.
Steps in Policy Evaluation
Authentication: Taloflow first authenticates the principal, typically a registered user authenticated by Auth0. The system can also work with anonymous users and temporary credentials.
Policy Processing: Taloflow processes the requested information to determine applicable policies and boundaries. The result is a list of possible policies based on the principals and resources.
Evaluating Policies: Taloflow evaluates all policies. The order of evaluation does not impact the result, but all boundary policies are evaluated first for efficiency. It is denied if there is no ALLOW at some level for the request. All deny policies are then evaluated. If any policy denies the request, it is denied. Finally, the system looks for an ALLOW policy that grants access and accumulates the scopes in the "allow" policies.
Determining Request Outcome: Taloflow processes the policies against the request context to determine whether to allow or deny the request.
Processing the Request Context
Taloflow gathers the following information into a request context:
Actions (Operations): The actions or operations the principal wants to perform.
Resources: The Taloflow resource object on which the actions are performed.
Principal: The user, role, federated user, or application sending the request, including associated policies.
Environment Data: Information attached to the request, such as IP address, user agent, SSL status, GraphQL request details, or time of day.
Resource Data: Data related to the requested resource, such as evaluation ID or workspace ID.
Types of Policies
Taloflow evaluates policies based on the types that apply to the request context:
Identity-Based Policies: Attached to users, groups, or roles and grant permissions. Taloflow checks these policies for at least one Allow and no Denies.
Resource-Based Policies: Grant permissions to the principal specified in the policy. Taloflow checks resource- and identity-based policies for at least one "allow" and no "denied."
Permissions Boundaries: Set the maximum permissions an identity-based policy can grant. Both identity-based policies and permissions boundaries must allow the action.
Taloflow Organizations Control Policies (OCPs): These policies specify the maximum permissions for an organization or organizational unit (OU). OCPs, identity-based policies, and resource-based policies must all allow the action.
An explicit denial in any of these policies overrides the allow.
Evaluating Policies
Evaluating Identity-Based and Resource-Based Policies
Identity-based and resource-based policies grant permissions to the identities or resources to which they are attached. When an entity requests access to a resource within the same account, Taloflow evaluates all permissions granted by both policy types. The resulting permissions are the total of both types. An explicit denial in either policy overrides the allow.
Evaluating Identity-Based Policies with Permissions Boundaries
When evaluating identity-based policies and permissions boundaries for a user, the resulting permissions intersect with both categories. Adding a permissions boundary might reduce user actions while removing it might increase them. An explicit denial in either policy overrides the allow.
Evaluating Identity-Based Policies with Organizations SCPs
When a user belongs to an account that is a member of an organization, the resulting permissions are the intersection of the user's policies and the SCP. Both the identity-based policy and the SCP must allow the action. An explicit denial in either policy overrides the allow.
Determining Request Outcome Within an Account
Taloflow evaluates all applicable policies to decide whether to allow or deny a request:
By default, all requests are implicitly denied, except for those made by the Taloflow account root user, who has full access.
An explicit allow in an identity-based or resource-based policy overrides this default.
A permissions boundary, organization's OCP, or session policy might override the allow with an implicit deny.
An explicit denial in any policy overrides any allows.
Example of Permissions Allocated in the System
The system has many permissions set up. Here are examples of a few. More permissions are added as the system evolves.
Evaluation Permissions
Permission | Description |
evaluation.view | View evaluations |
evaluation.create | Create evaluations |
evaluation.edit | Edit evaluations |
evaluation.delete | Delete evaluations |
evaluation.archive | Archive evaluations |
evaluation.unarchive | Unarchive evaluations |
evaluation.export | Export evaluations |
evaluation.rename | Rename evaluations |
evaluation.move | Move evaluations |
evaluation.invite | Invite users to evaluations |
evaluation.uninvite | Uninvite users from evaluations |
Workspace Permissions
Permission | Description |
workspace.view | View workspaces |
workspace.create | Create workspaces |
workspace.edit | Edit workspaces |
workspace.delete | Delete workspaces |
workspace.rename | Rename workspaces |
workspace.move | Move workspaces |
workspace.invite | Invite users to workspaces |
Last updated
