Role-Based Access Control (RBAC)

Eden-MDBS provides fine-grained access control for resources like endpoints, templates, workflows, and organizations. RBAC allows you to control who can access what resources and what operations they can perform.

Access Levels

Eden uses a four-tier hierarchical access level system:

Each level includes all permissions from lower levels. For example, Write includes Read permissions.

Resource Types

RBAC applies to these resource types:

Managing Endpoint Permissions

Get Endpoint Permissions

View all subjects and their access levels for an endpoint:

curl http://{host}:8000/api/v1/iam/rbac/endpoints/my_database \
  -H "Authorization: Bearer $TOKEN"

Response:

{
  "status": "success",
  "data": {
    "users": {
      "user1@company.com": "Read",
      "user2@company.com": "Write",
      "admin@company.com": "Admin"
    }
  }
}

Add Subjects to Endpoint

Grant access to multiple users:

curl http://{host}:8000/api/v1/iam/rbac/endpoints/subjects \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $TOKEN" \
  -d '{
    "subjects": [
      ["john@company.com", "Read"],
      ["jane@company.com", "Write"],
      ["admin@company.com", "Admin"]
    ]
  }'

Response:

{
  "status": "success",
  "message": "added rbac rule for endpoint"
}

Get Specific User's Permission

Check a user's access level for an endpoint:

curl http://{host}:8000/api/v1/iam/rbac/endpoints/my_database/subjects/john@company.com \
  -H "Authorization: Bearer $TOKEN"

Response:

{
  "status": "success",
  "data": "Read"
}

Get Your Own Permission

Users can check their own permissions without Admin access:

curl http://{host}:8000/api/v1/iam/rbac/endpoints/my_database/subjects \
  -H "Authorization: Bearer $TOKEN"

Response:

{
  "status": "success",
  "data": "Write"
}

Remove User from Endpoint

Revoke a user's access:

curl http://{host}:8000/api/v1/iam/rbac/endpoints/my_database/subjects/john@company.com \
  -H "Authorization: Bearer $TOKEN" \
  -X DELETE

Response:

{
  "status": "success",
  "data": "Read"
}

The response shows the access level that was removed.

Remove All Endpoint Permissions

Remove all permissions for an endpoint (SuperAdmin only):

curl http://{host}:8000/api/v1/iam/rbac/endpoints/my_database \
  -H "Authorization: Bearer $TOKEN" \
  -X DELETE

Managing Organization Permissions

Get Organization Permissions

curl http://{host}:8000/api/v1/iam/rbac/organizations \
  -H "Authorization: Bearer $TOKEN"

Response:

{
  "status": "success",
  "data": {
    "users": {
      "admin@company.com": "SuperAdmin",
      "manager@company.com": "Admin",
      "developer@company.com": "Write",
      "viewer@company.com": "Read"
    }
  }
}

Add Subjects to Organization

curl http://{host}:8000/api/v1/iam/rbac/organizations/subjects \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $TOKEN" \
  -d '{
    "subjects": [
      ["newadmin@company.com", "Admin"],
      ["newdev@company.com", "Write"],
      ["contractor@company.com", "Read"]
    ]
  }'

Get User's All Permissions

View all resources a user has access to:

curl http://{host}:8000/api/v1/iam/rbac/organizations/subjects/john@company.com \
  -H "Authorization: Bearer $TOKEN"

Response:

{
  "status": "success",
  "data": {
    "organizations": {
      "550e8400-e29b-41d4-a716-446655440000": "Admin"
    },
    "endpoints": {
      "550e8400-e29b-41d4-a716-446655440001": "Write",
      "550e8400-e29b-41d4-a716-446655440002": "Read"
    },
    "templates": {
      "550e8400-e29b-41d4-a716-446655440003": "Admin"
    },
    "workflows": {}
  }
}

Remove User from Organization

curl http://{host}:8000/api/v1/iam/rbac/organizations/subjects/john@company.com \
  -H "Authorization: Bearer $TOKEN" \
  -X DELETE

Permission Requirements

To manage RBAC permissions, you need sufficient access:

Example Permission Logic

• An Admin can grant Read or Write access
• An Admin cannot grant Admin or SuperAdmin access
• A SuperAdmin can grant any access level
• A Write user cannot manage RBAC at all

Subject Input Format

When adding subjects, use this format:

{
  "subjects": [
    ["username1", "AccessLevel1"],
    ["username2", "AccessLevel2"]
  ]
}

Examples

Single User:

{
  "subjects": [["john@company.com", "Read"]]
}

Multiple Users with Different Access:

{
  "subjects": [
    ["developer@company.com", "Read"],
    ["teamlead@company.com", "Write"],
    ["manager@company.com", "Admin"]
  ]
}

Mixed User Types (email and UUID):

{
  "subjects": [
    ["john@company.com", "Write"],
    ["550e8400-e29b-41d4-a716-446655440000", "Admin"]
  ]
}

Permission Hierarchy

Organization vs Resource Permissions

Organization-level permissions provide base access, while resource-specific permissions can override them:

1. Resource-Specific Permission: If user has explicit permission on resource, use that
2. Organization Permission: If no resource-specific permission, use organization level
3. No Access: If no permissions found, deny access

Example

A user with organization-level Write access:

• Has Write access to all endpoints by default
• Can have Admin on specific endpoints (higher than org level)
• Can have Read on specific endpoints (lower than org level)

Error Handling

Insufficient Permissions

{
  "error": "Forbidden",
  "message": "Insufficient access level to grant Admin permissions"
}

Subject Not Found

{
  "error": "Not Found",
  "message": "User john@company.com not found in organization"
}

Endpoint Not Found

{
  "error": "Not Found",
  "message": "Endpoint my_database not found"
}

Invalid Access Level

{
  "error": "Bad Request",
  "message": "Invalid access level: InvalidLevel"
}

Best Practices

Permission Design

• Principle of Least Privilege: Grant minimum necessary access
• Regular Reviews: Audit permissions periodically
• Role-Based Assignment: Group users by function rather than individual grants

Access Level Management

• Start Small: Begin with Read access and escalate as needed
• Admin Hierarchy: Clearly define who can manage whom
• SuperAdmin Restrictions: Limit SuperAdmin to essential personnel

Operational Procedures

• Onboarding: Standardize permission assignment for new users
• Offboarding: Immediately revoke all access when users leave
• Role Changes: Update permissions when job responsibilities change

Monitoring

• Access Logs: Monitor who accesses what resources
• Permission Changes: Log all RBAC modifications
• Unusual Activity: Alert on unexpected permission usage

Related

• Organizations - Organization management
• Endpoints - Database connections
• Authentication - Login and tokens
• Users - User management