Overview User governance in Bedrock follows a hierarchical Role-Based Access Control (RBAC) model. Users are added to scopes via memberships, assigned roles, and inherit permissions from those roles. This guide covers common patterns for managing user access.
Core Concepts
Subjects Users are registered as subjects with type: "user"
Memberships Memberships connect users to scopes
Roles Roles group permissions together
Permissions Permissions define specific actions
Example: Enterprise Organization Let’s set up a typical enterprise structure with organizations, departments, and teams.
1. Define the Hierarchy # Create all scope types at once curl -X POST 'https://api.example.com/scope-types/batch' \ -H 'Content-Type: application/json' \ -d '[ {"id": "type_org", "name": "Organization", "config": {"permissionMode": "define"}}, {"id": "type_dept", "name": "Department", "config": {"permissionMode": "inherit"}}, {"id": "type_team", "name": "Team", "config": {"permissionMode": "inherit"}} ]' # Define hierarchy: Org → Department → Team curl -X POST 'https://api.example.com/scope-type-hierarchy' \ -d '{"parentTypeId": "type_org", "childTypeId": "type_dept"}' curl -X POST 'https://api.example.com/scope-type-hierarchy' \ -d '{"parentTypeId": "type_dept", "childTypeId": "type_team"}'
2. Create Scopes # Create all scopes at once curl -X POST 'https://api.example.com/scopes/batch' \ -H 'Content-Type: application/json' \ -d '[ {"id": "scope_acme", "name": "Acme Corp", "typeId": "type_org"}, {"id": "scope_engineering", "name": "Engineering", "typeId": "type_dept"}, {"id": "scope_marketing", "name": "Marketing", "typeId": "type_dept"}, {"id": "scope_platform", "name": "Platform Team", "typeId": "type_team"}, {"id": "scope_frontend", "name": "Frontend Team", "typeId": "type_team"} ]' # Link hierarchy curl -X POST 'https://api.example.com/scope-hierarchy/batch' \ -H 'Content-Type: application/json' \ -d '[ {"parentScopeId": "scope_acme", "childScopeId": "scope_engineering"}, {"parentScopeId": "scope_acme", "childScopeId": "scope_marketing"}, {"parentScopeId": "scope_engineering", "childScopeId": "scope_platform"}, {"parentScopeId": "scope_engineering", "childScopeId": "scope_frontend"} ]'
3. Define Roles at Different Levels Roles can be defined at any scope level and inherited by child scopes:
# Create all roles at once curl -X POST 'https://api.example.com/roles/batch' \ -H 'Content-Type: application/json' \ -d '[ {"id": "role_org_admin", "name": "Org Admin", "description": "Full organization access", "scopeId": "scope_acme"}, {"id": "role_org_member", "name": "Org Member", "description": "Basic organization access", "scopeId": "scope_acme"}, {"id": "role_dept_manager", "name": "Dept Manager", "description": "Department management access", "scopeId": "scope_engineering"}, {"id": "role_team_lead", "name": "Team Lead", "description": "Team leadership access", "scopeId": "scope_platform"} ]'
4. Add Users with Different Access Levels # Create all users at once with inline memberships and role assignments curl -X POST 'https://api.example.com/subjects/batch' \ -H 'Content-Type: application/json' \ -d '[ { "id": "sub_john", "subjectType": "user", "externalId": "ceo-john", "displayName": "John CEO", "memberships": [ {"scopeId": "scope_acme", "roleIds": ["role_org_admin"]} ] }, { "id": "sub_sarah", "subjectType": "user", "externalId": "eng-manager-sarah", "displayName": "Sarah", "memberships": [ {"scopeId": "scope_engineering", "roleIds": ["role_dept_manager"]} ] }, { "id": "sub_mike", "subjectType": "user", "externalId": "dev-mike", "displayName": "Mike", "memberships": [ {"scopeId": "scope_platform", "roleIds": ["role_org_member"]} ] } ]'
Inline Memberships : When creating subjects, you can include memberships with roleIds to create the subject, membership, and role assignments in a single request.
Common Patterns Pattern 1: Multiple Team Membership Users can belong to multiple teams with different roles:
# Mike is also on the Frontend team with a different role curl -X POST 'https://api.example.com/memberships' \ -d '{"subjectId": "sub_mike", "scopeId": "scope_frontend"}' curl -X POST 'https://api.example.com/role-assignments' \ -d '{"roleId": "role_team_lead", "membershipId": "mem_mike_frontend"}'
Pattern 2: Restricting Inherited Permissions Use scope overrides to restrict permissions at child scopes:
# Disable delete permission for the Platform team curl -X POST 'https://api.example.com/scope-overrides/permissions' \ -d '{ "childScopeId": "scope_platform", "permissionId": "perm_delete", "state": "disabled" }'
Pattern 3: Temporary Elevated Access Assign additional roles for temporary access:
# Give Mike temporary admin access curl -X POST 'https://api.example.com/role-assignments' \ -d '{"roleId": "role_team_lead", "membershipId": "mem_mike_platform"}' # Later, remove the elevated access curl -X DELETE 'https://api.example.com/role-assignments/role_team_lead/mem_mike_platform'
Permission Inheritance Permissions flow down the scope hierarchy:
Organization (Org Admin, Org Member roles) ↓ inherits Department (Dept Manager role) ↓ inherits Team (Team Lead role)
Users at a parent scope can access child scopes based on their role permissions. Use scope overrides to restrict this inheritance when needed.
Best Practices
Use descriptive role names
Name roles based on their function, not the person. Use “Engineering Manager” instead of “Sarah’s Role”.
Define permissions at the highest applicable level
Create permissions at the organization level if they apply across the organization. This makes them available to all child scopes.
Use scope overrides sparingly
Overrides add complexity. Design your role structure to minimize the need for overrides.
Periodically review memberships and role assignments to ensure they’re still appropriate.
Next Steps 
