Role-Based Access Control (RBAC)

Fiscus provides an advanced Role-Based Access Control (RBAC) system that allows developers to define detailed roles and policies for managing user access to APIs and specific operations. With Fiscus RBAC, enterprises can implement highly granular permission models, ensuring that users only have access to the appropriate APIs and functions. This system supports dynamic evaluation of conditions, providing a flexible way to control permissions based on context, user roles, and policies.

Core Concepts of RBAC in Fiscus

• Roles: Roles define the level of access a user has in your system. Examples include "admin," "user," or "guest," but they can be fully customized.
• Policies: Policies dictate what APIs (connectors) and specific operations (functions) a user can perform. Policies can be linked to roles and include conditions based on the user context.
• Conditions: Custom conditions can be dynamically evaluated at runtime, ensuring that permission checks consider the current context, such as user-specific preferences or session details.
• Connectors: These are the APIs or external services (e.g., Gmail, Salesforce) a user can interact with.
• Operations: The specific functions a user can perform within a connector (e.g., sending an email, creating a contact).

Assigning Roles and Policies

To manage access effectively, roles and policies must be assigned to users. This allows for a structured approach where users are categorized based on their roles, and policies define what each role can do.

Python

Example: Assigning Roles to a User

You can assign a role to a user with the following method:

user.assign_role('admin') 

• Roles:
  • Roles are used to group users by access level. For example, an "admin" role might have full access to all connectors and operations, while a "guest" role might only have read-only access to certain data.
  • Users can have multiple roles, allowing you to layer access levels. This is useful when you want to combine certain permissions from different roles.

Example: Assigning Multiple Roles

user.assign_role('admin')  
user.assign_role('editor')

• This would assign both admin and editor permissions to the user.

 

Defining and Adding Policies

Policies define what a user or a role can do within specific APIs or operations. Fiscus allows for a highly customizable policy structure, where you can define not only what connectors and operations a user can access but also under what conditions they can access them.

Example: Defining a Policy

Policies are a central part of RBAC. Here’s how you define a policy to control what specific APIs (connectors) and operations a user can access.

Define a policy for an 'admin' role

policy = {
    'roles': ['admin'],  # Applies to users with the 'admin' role.
    'connectors': ['Gmail', 'Salesforce'],  # APIs the user can access.
    'operations': ['send_email', 'create_contact'],  # Operations the user can perform.
    'conditions': lambda user, context: user.user_id == 'admin_user'  # Optional conditions for additional control.
}

# Add the policy to the user
user.add_policy(policy)

• Connectors: In this example, the user can access Gmail and Salesforce.
• Operations: The user is allowed to send emails and create contacts. You can further restrict or expand the operations based on the connector.
• Conditions: This is where Fiscus shines, allowing you to define dynamic conditions, such as checking user context (e.g., checking if the user is an admin). You can customize the logic to fit any complex scenario.

 

Dynamic Role and Policy Evaluation

Fiscus evaluates policies at runtime, taking into account the user's current context. This allows you to enforce different permissions dynamically. For example, based on the time of day, location, or specific session data, different permissions can be granted or revoked.

Example: Dynamic Conditions in Policies

Suppose you want to create a policy that allows an admin to create contacts in Salesforce only if they are in a specific department or region. You can use a condition to check for this in real-time.

Define a policy with a dynamic condition

policy = {
    'roles': ['admin'],  # Applies to 'admin' users.
    'connectors': ['Salesforce'],
    'operations': ['create_contact'],
    'conditions': lambda user, context: user.get_context('region') == 'NorthAmerica'  # Only allow if the user is in North America.
}

# Add policy to the user
user.add_policy(policy)

In this case, Fiscus checks the user’s context to see if the "region" key is set to "NorthAmerica." If this condition is met, the user is allowed to create a contact in Salesforce. If not, permission is denied.

 

Implementing Permission-Based API Access

The key advantage of Fiscus's RBAC system is the ability to check permissions before executing any API operation. This ensures that users can only access the connectors and perform the operations for which they have permission.

Example: Checking User Permissions Before Performing an Action

Before executing any API operation, you can check if the user has the necessary permissions for a specific connector and operation.

if user.has_permission('Gmail', 'send_email'):
    # Proceed with sending the email
    email_params = {'to': 'john@example.com', 'subject': 'Meeting', 'body': 'Let’s meet at 2 PM'}
    client.execute('Gmail', 'send_email', email_params, user=user)
else:
    print("Permission denied for sending an email on Gmail.")

In this example:

• The has_permission method checks if the user is allowed to send an email through Gmail. If permission is granted, the email is sent.
• If the permission check fails, the operation is denied, and an appropriate message is logged.

 

Advanced Policy and Role Management Features

In addition to basic role and policy assignment, Fiscus provides advanced features for more sophisticated access control models. These include the ability to update roles dynamically, apply multiple policies, and manage cross-connector permissions.

Managing Multiple Policies

Users can have multiple policies, and Fiscus evaluates all of them to determine if the user has permission to perform an operation.

Example: Adding Multiple Policies for a User

policy1 = {
    'roles': ['editor'],
    'connectors': ['Gmail'],
    'operations': ['send_email'],
}

policy2 = {
    'roles': ['admin'],
    'connectors': ['Salesforce'],
    'operations': ['create_contact'],
}

user.add_policy(policy1)
user.add_policy(policy2)

In this scenario:

• Policy 1 allows the user to send emails if they have the "editor" role.
• Policy 2 allows the user to create contacts in Salesforce if they are an "admin."

Combining Role and Policy-Based Access

Fiscus supports combining roles and policies for highly flexible permission management. For example, you can define that only users with both "manager" and "admin" roles can access certain APIs or perform specific operations.

policy = {
    'roles': ['manager', 'admin'],  # User must have both roles.
    'connectors': ['HubSpot'],
    'operations': ['create_deal', 'update_contact'],
}

user.add_policy(policy)

• Multiple Role Requirements: In this case, the user must have both the "manager" and "admin" roles to create or update deals in HubSpot.

 

Changing User IDs and Their Impact on Access

Fiscus also allows changing user IDs dynamically, which can be useful in scenarios where user accounts need to be reassigned or updated. Changing a user ID will automatically propagate across the entire system, including roles, policies, and permissions.

Example: Changing a User ID

user.set_user_id('new_user_id')

This method updates the user ID for the user. Fiscus will continue to apply the user’s roles and policies to the new user ID.

Auditing and Logging Access Decisions

Fiscus provides comprehensive audit logging features to track permission checks, role assignments, and policy evaluations. These logs are invaluable for security audits and debugging access control issues.

Example: Enabling Audit Logs for Role and Policy Changes

Audit trails can be enabled for tracking changes in user roles and policies. Every time a role is assigned or a policy is updated, it is logged.

user.assign_role('admin')  
# Audit log: "Assigned role 'admin' to user 'user_id'"

user.add_policy(policy)  
# Audit log: "Added policy to user 'user_id': {...}"

These logs ensure that you have full visibility into how roles and permissions are being managed across your system.

 

Conclusion

Fiscus's RBAC system provides a flexible and dynamic approach to access control. By combining roles, policies, and conditions, developers can create highly tailored permission models that adapt to the user's current context. Fiscus simplifies permission-based API access while offering advanced features such as dynamic evaluation, multiple policy support, and comprehensive audit logging, ensuring your system remains secure and scalable as it grows.

Key benefits of using Fiscus RBAC:

• Granular control over API and operation access.
• Dynamic permission evaluation based on real-time user context.
• Support for multiple roles and policies per user.
• Full audit trail of access decisions and role changes.