How Permissions Work
Overview
Moveworks evaluates content access using a Relationship-Based Access Control (ReBAC) model. Your gateway provides the identity and access graph; Moveworks resolves whether a specific user can view a specific file at query time.
What your gateway provides
Three sets of records together define access:
The id values in permission entries and group memberships are external IDs in your system. They must match the corresponding id fields returned by /users and /groups.
How access is resolved
When evaluating whether a user can view a specific file, Moveworks:
- Reads the file’s permission entries from
/files/{id}/permissions. - For each entry, checks whether the requesting user satisfies it:
- A
USERentry matches if the user’s external ID equals the entry’sid. - A
GROUPentry matches if the user is a member of that group, directly or through any chain of nested groups.
- A
- The user can view the file if at least one permission entry matches.
Group membership traversal is handled entirely by Moveworks. Your /groups/{groupId}/members endpoint must return only the direct members of each group. Moveworks follows the chain itself. If group A contains group B which contains user U, the response for group A returns [{"type": "GROUP", "id": "B"}], not [{"type": "USER", "id": "U"}].
Wildcards (public content)
To grant access to all users in your organization, return a permission entry of the form {"type": "GROUP", "id": "*", "action": "VIEW"}. This specific shape (a GROUP type with * id) is what Moveworks interprets as “any user.” Other variants such as {"type": "USER", "id": "*"} will not behave as a wildcard and should not be used.
Supported action
The action field on permission entries must be "VIEW". Other action values are not evaluated and will be rejected by the schema validator.
Related
- Common Pitfalls: mistakes to avoid when implementing the permission model
- Verifying Your Build: validate your permission responses with the schema validator