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:

LevelDescription
ReadView and query resources
WriteRead permissions plus modify data
AdminWrite permissions plus manage users and configurations
SuperAdminFull control including other admin management

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

Resource Types

RBAC applies to these resource types:

ResourceDescription
OrganizationsTop-level access control for the entire organization
EndpointsDatabase and service connections
TemplatesReusable query templates
WorkflowsAutomated multi-step operations

Managing Endpoint Permissions

Get Endpoint Permissions

View all subjects and their access levels for an endpoint:

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

Response:

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

Set Subject Access on Endpoint

Set the exact control-plane grant for one subject:

bash
curl http://{host}:8000/api/v1/iam/control/endpoints/my_database/subjects/john@company.com \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $TOKEN" \
  -X PUT \
  -d '{"perms":"R"}'

Get Specific User's Permission

Check a user's access level for an endpoint:

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

Response:

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

Get Your Own Access

Users can check their resolved control-plane and data-plane access without Admin access:

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

Response:

json
{
  "status": "success",
  "data_plane": {
    "mode": "shared_rbac",
    "shared_perms": "r",
    "els_assignment": null
  }
}

Remove User from Endpoint

Revoke a user's access:

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

Response:

json
{
  "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):

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

Managing Organization Permissions

Get Organization Permissions

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

Response:

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

Set Subject Access on Organization

bash
curl http://{host}:8000/api/v1/iam/control/organizations/subjects/newadmin@company.com \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $TOKEN" \
  -X PUT \
  -d '{"perms":"RCPGA"}'

Get User's All Permissions

View all resources a user has access to:

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

Response:

json
{
  "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

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

Permission Requirements

To manage RBAC permissions, you need sufficient access:

OperationRequired Access
View RBAC InfoAdmin
Add SubjectsEqual to or higher than the level being granted
Remove SubjectsEqual to or higher than the level being removed
Delete All PermissionsSuperAdmin

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

Exact-State PUT Format

When setting a control-plane or data-plane grant, use this format:

json
{
  "perms": "PERMS1"
}

Examples

Single User:

json
{
  "perms": "R"
}

Endpoint Data-Plane Grant:

json
{
  "perms": "rw"
}

Use one PUT request per subject and use DELETE to revoke the exact grant.

Mixed Subject Identifiers:

json
{
  "perms": "RCA"
}

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

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

Subject Not Found

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

Endpoint Not Found

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

Invalid Access Level

json
{
  "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
Last updated: October 20, 2018
Size: 8.13 KB
    Eden