Separation of Duties

Separation of duties (SoD) constraints prevent users from holding conflicting role combinations. This is a key security control for organizations that need to enforce compliance policies or reduce the risk of privilege abuse.

Constraint types

Static separation of duties

A static SoD constraint prevents a user from being assigned two specific roles simultaneously. The constraint is enforced at assignment time — if a user already holds one of the conflicting roles, attempting to assign the other will fail.

Example: A user cannot be both a "Privacy Request Approver" and a "Privacy Request Submitter", preventing someone from approving their own requests.

Cardinality constraints

A cardinality constraint limits how many users can hold a specific role. This is useful for restricting highly privileged roles.

Example: Limit the "Owner" role to no more than 3 users in the organization.

Managing constraints

Viewing constraints

From the API

curl https://your-fides-instance/api/v1/plus/rbac/constraints \
  -H "Authorization: Bearer $TOKEN"

Response:

[
  {
    "id": "constraint-uuid",
    "name": "Approver / Submitter SoD",
    "description": "Users cannot approve their own requests",
    "constraint_type": "static_sod",
    "role_id_1": "approver-role-uuid",
    "role_id_2": "submitter-role-uuid",
    "max_users": null,
    "is_active": true,
    "created_at": "2026-01-15T10:00:00Z"
  }
]

Creating a static SoD constraint

curl -X POST https://your-fides-instance/api/v1/plus/rbac/constraints \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Approver / Submitter SoD",
    "description": "Users cannot approve their own requests",
    "constraint_type": "static_sod",
    "role_id_1": "approver-role-uuid",
    "role_id_2": "submitter-role-uuid"
  }'

Once created, any attempt to assign role_id_2 to a user who already holds role_id_1 (or vice versa) will be rejected with an error explaining the constraint violation.

Creating a cardinality constraint

curl -X POST https://your-fides-instance/api/v1/plus/rbac/constraints \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Max 3 Owners",
    "description": "Limit the number of users with full system access",
    "constraint_type": "cardinality",
    "role_id_1": "owner-role-uuid",
    "max_users": 3
  }'

Deleting a constraint

Constraints are immutable after creation. To modify a constraint, delete it and create a new one.

curl -X DELETE https://your-fides-instance/api/v1/plus/rbac/constraints/{constraint_id} \
  -H "Authorization: Bearer $TOKEN"

Disabling constraint enforcement

If you need to temporarily bypass SoD enforcement (for example, during a migration), you can disable it:

FIDESPLUS__RBAC__ENFORCE_SOD_CONSTRAINTS=false

When disabled, SoD constraints remain in the database but are not checked during role assignment. Re-enable enforcement by setting the value back to true and restarting.

Best practices

• Start with key conflicts: Identify the most critical role conflicts in your organization (e.g., request creator vs. approver) and create SoD constraints for those first.
• Document your constraints: Use descriptive names and descriptions so the purpose of each constraint is clear to other administrators.
• Review before enabling: If you're adding constraints to an existing deployment, review current role assignments first to identify any existing violations.
• Use with role hierarchy: When designing role hierarchies, consider SoD implications. If Role A inherits from Role B, and you create an SoD constraint between Role B and Role C, users with Role A will also be blocked from holding Role C.