Role Based Access Control (RBAC)

OverviewCopied!

Eden implements a comprehensive Role-Based Access Control system that provides sophisticated, fine-grained control over all resources within the platform. Built on the principle of least privilege, Eden's RBAC system allows organizations to precisely define who can access which resources and what actions they can perform, reducing security risks while enabling effective collaboration.

Eden's RBAC system integrates seamlessly with the Identity and Access Management (IAM) system to create a complete access control solution that addresses the security and compliance needs of modern enterprises.

Access Control PhilosophyCopied!

Eden's RBAC model is designed around a hierarchical approach where:

• Access is explicitly granted, never implicitly assumed

• Permissions cascade from organizations down to specific resources

• More restrictive permissions always override less restrictive ones

• Every API call is evaluated against the permission model

• Actions are denied by default unless specifically permitted

This zero-trust approach ensures that users only have access to the resources they need to perform their job functions.

Access Levels ExplainedCopied!

Eden defines five distinct access levels, each with a specific set of capabilities:

SuperAdmin

• The highest privilege level with complete control

• Can modify organization state data and settings

• Can add and remove administrators at all levels

• Has unrestricted access to all resources and operations

• Typically limited to a small number of trusted users

• Responsible for critical security and governance decisions

Admin

• Organization-wide administrative capabilities

• Can add and remove users with Write and Read access

• Cannot modify SuperAdmin assignments

• Can create, modify, and delete most resources

• Responsible for day-to-day administration tasks

• Can configure organization-wide settings and policies

Write

• Operational-level access for active users

• Can create, modify, and execute resources (endpoints, templates, workflows)

• Cannot modify user permissions or organization settings

• Suitable for developers, integration specialists, and power users

• Can perform most day-to-day operations within the system

Read

• View-only access to resources

• Can see but not modify or execute resources

• Useful for stakeholders who need visibility without operational capabilities

• Appropriate for auditors, managers, and other oversight roles

• Can use reporting and monitoring features

None

• No access to the organization or its resources

• Default state for all users not explicitly assigned an access level

• Used to explicitly document revoked access

RBAC ResourcesCopied!

Eden's RBAC system applies to multiple resource types:

Organizations

• The top-level container for all resources

• Organization-level permissions cascade down to child resources

• Permissions at this level affect all resources within the organization

Endpoints

• Connections to external systems

• Endpoint permissions control who can connect to, modify, or use external integrations

• Granular controls for sensitive system connections

Templates

• Data transformation definitions

• Template permissions control who can create, modify, or use data transformations

• Critical for maintaining data integrity and business rules

Workflows

• Multi-step process definitions

• Workflow permissions control who can define, modify, or execute business processes

• Important for maintaining operational consistency

RBAC Implementation DetailsCopied!

The RBAC system works by evaluating three key factors for each API request:

1. Who is making the request (user identity)

2. What resource they're attempting to access

3. How they're trying to interact with it (operation type)

This evaluation happens in real-time for every API call, ensuring consistent enforcement of access policies even as resources and permissions change.

Authentication and RBACCopied!

Eden's RBAC system works in conjunction with the JWT-based authentication system:

1. Users authenticate via the /auth/login endpoint to obtain a JWT token

2. The JWT token contains encoded information about the user's identity

3. This identity is used by the RBAC system to determine access rights

4. Each API request is evaluated against RBAC policies using the user identity

RBAC API ReferenceCopied!

Eden provides a comprehensive set of API endpoints for managing RBAC permissions:

Organization RBAC

Endpoint RBAC

Template RBAC

Workflow RBAC

Subject Management

RBAC Request and Response ExamplesCopied!

Example 1: Adding a Subject to Endpoint RBAC

Request:

POST /iam/rbac/endpoints/subjects
Content-Type: application/json

{
  "access_level": "Read",
  "subject": "jane.doe@example.com",
  "endpoint_id": "endpoint-uuid"
}

Response:

{
  "message": "Subject successfully added to endpoint RBAC",
  "subject": "jane.doe@example.com",
  "accessLevel": "Read",
  "endpointId": "endpoint-uuid"
}

Example 2: Retrieving a Subject's Permissions

Request:

GET /iam/rbac/subjects/jane.doe@example.com

Response:

{
  "subject": "jane.doe@example.com",
  "organizations": {
    "org-id-123": "Admin"
  },
  "endpoints": {
    "endpoint-uuid-1": "Write",
    "endpoint-uuid-2": "Read"
  },
  "templates": {
    "template-uuid-1": "Write",
    "template-uuid-2": "Read"
  },
  "workflows": {
    "workflow-uuid-1": "Admin"
  }
}

Example 3: Adding a Subject to Organization RBAC

Request:

POST /iam/rbac/organizations/subjects
Content-Type: application/json

{
  "access_level": "Admin",
  "subject": "john.smith@example.com"
}

Response:

{
  "message": "Subject successfully added to organization RBAC",
  "subject": "john.smith@example.com",
  "accessLevel": "Admin",
  "organizationId": "org-id-123"
}

Example 4: Removing a Subject's Template Permissions

Request:

DELETE /iam/rbac/templates/subjects/sarah.jones@example.com?template_id=template-uuid-1

Response:

{
  "message": "Subject successfully removed from template RBAC",
  "subject": "sarah.jones@example.com",
  "templateId": "template-uuid-1"
}

Access Control PatternsCopied!

Role-Based Access Model

Eden's access control system is built on a role-based model that maps common job functions to appropriate permission levels:

Resource-Specific Permissions

While access levels provide a baseline, Eden also supports more granular permissions at the resource level:

Organization: Acme Corp
├── User: Jane (Admin)
│   └── Full access to all resources by default
├── User: Bob (Write)
│   ├── Default write access to most resources
│   ├── Elevated Admin access to specific Templates
│   └── Restricted Read-only access to Production Workflows
├── User: Alice (Read)
│   ├── Default read access to most resources
│   └── No access to sensitive customer data

Permission Inheritance and Overrides

Eden implements a hierarchical permission model where:

• Organization-level access provides the baseline

• Resource-specific permissions can override the baseline

• Explicit denials take precedence over any granted permissions

• Time-bound or conditional access can further restrict operations

Implementing RBACCopied!

To implement RBAC in your Eden application:

1. Plan your access control strategy

• Identify resources that need access control

• Define roles based on job functions

• Map access levels to roles

• Document your RBAC strategy

2. Configure organization-level permissions

• Set up organization administrators

• Define organization access for user groups

• Establish baseline permissions

3. Set up resource-specific permissions

• Configure access to endpoints, templates, and workflows

• Assign appropriate access levels to subjects

• Create exceptions for special cases

4. Verify access control

• Test permissions by accessing resources with different user accounts

• Ensure proper access level escalation and de-escalation

• Validate that denied actions are properly blocked

5. Document and maintain

• Document all access control decisions

• Regularly review and update permissions

• Maintain an audit trail of permission changes

Common RBAC ScenariosCopied!

Development, Testing, and Production Environments

A typical pattern involves different access levels for different environments:

Organization: Acme Corp Development
├── Development Team (Write)
├── QA Team (Read)
├── Operations (Read)

Organization: Acme Corp Testing
├── Development Team (Read)
├── QA Team (Write)
├── Operations (Write)

Organization: Acme Corp Production
├── Development Team (None)
├── QA Team (Read)
├── Operations (Write)
├── Support Team (Read)

Cross-Functional Teams

For projects involving multiple teams:

Project: Customer Portal
├── Backend Team
│   ├── API Endpoints (Write)
│   ├── Integration Workflows (Write)
│   ├── UI Templates (Read)
├── Frontend Team
│   ├── API Endpoints (Read)
│   ├── Integration Workflows (Read)
│   ├── UI Templates (Write)
├── QA Team
│   ├── All Resources (Read)
│   ├── Test Workflows (Write)
├── Project Manager
│   ├── All Resources (Read)
│   ├── Reporting Dashboards (Write)

Best Practices for RBACCopied!

Follow the principle of least privilege

• Assign the minimum access level needed for each user's function

• Regularly review and adjust permissions as roles change

• Start with restrictive permissions and gradually add access as needed

• Remove permissions when no longer needed

Implement separation of duties

• Divide critical functions among different users

• Ensure no single user (except SuperAdmin) can control entire processes

• Create control points requiring multiple approvers for sensitive operations

• Separate development, testing, and production access

Establish clear user management processes

• Document procedures for onboarding, role changes, and offboarding

• Create regular review cycles for access permissions

• Implement formal approval workflows for privileged access

• Maintain an audit trail of permission changes

Use granular permissions for sensitive operations

• Limit SuperAdmin access to only those who absolutely require it

• Consider creating custom roles for specialized functions

• Implement additional safeguards for destructive operations

• Apply stricter controls to production environments

Implement comprehensive logging and monitoring

• Track all permission changes and access attempts

• Set up alerts for suspicious activity

• Regularly audit access control effectiveness

• Review logs for unauthorized access attempts

RBAC GovernanceCopied!

Effective governance of your RBAC implementation requires:

Regular Access Reviews

• Conduct quarterly reviews of all permission assignments

• Verify that access levels match current job responsibilities

• Identify and remove unused or excessive permissions

• Document review findings and actions taken

Permission Change Management

• Require formal requests for permission changes

• Implement approval processes for elevated access

• Document the business justification for access changes

• Maintain a historical record of permission changes

RBAC Metrics and Reporting

• Track key metrics like:

  • Number of users at each access level

  • Frequency of permission changes

  • Failed access attempts

  • Permission exceptions

• Generate regular reports for security reviews

• Identify trends and potential issues

Compliance and Audit Support

• Document how your RBAC implementation supports compliance requirements

• Prepare evidence for audit requirements

• Maintain historical access records

• Track privileged access usage

Troubleshooting RBAC IssuesCopied!

Common issues and their resolutions:

Access Denied Unexpectedly

• Verify the user's assigned access level

• Check for explicit denials that override permissions

• Confirm that the resource exists and is accessible

• Validate JWT token expiration and claims

Permissions Not Taking Effect

• Ensure permissions have been properly assigned

• Check for conflicting permission definitions

• Verify that the user is authenticated correctly

• Check for resource-specific overrides

Unable to Modify Permissions

• Verify your own access level (Admin or SuperAdmin required)

• Check for organization-level restrictions

• Ensure the subject exists and is valid

• Validate that the resource exists and is under your control

Missing Resources in Access Lists

• Confirm that resources have been created correctly

• Check for filtering or visibility restrictions

• Verify permission inheritance from parent resources

• Ensure consistent organization context

ConclusionCopied!

Eden's RBAC system provides a powerful, flexible framework for implementing precise access control across your organization's resources. By following the principles and best practices outlined in this documentation, you can create a secure, manageable permission structure that balances security needs with operational efficiency.

For additional assistance with RBAC implementation, refer to Eden's support resources or contact technical support.