Designing permissions for collaborative applications

Build collaborative permissions around explicit relationships between people, groups, and resources. Derive actions such as reading, editing, and managing sharing from those relationships, and enforce each decision in trusted application services. Keep signing in separate from deciding whether someone may access a particular document.

Ory Keto is one option for modeling these permissions. Its Ory Network documentation describes fine-grained resource relationships and permission inheritance through groups, roles, and hierarchies. Use those capabilities to express the collaboration policy; plan application enforcement separately. Ory Keto documentation

Separate relationships from permitted actions

Start with concrete questions: Who may read this document? Who may change it? Who may invite another reader?

A relationship records a fact, such as “this user is an editor of this document.” A permission expresses what that fact allows. Keto’s introductory example makes this distinction explicit: documents have editor and viewer relationships; write follows from editor membership, while read follows from either write permission or viewer membership. Ory documents its configuration language, Ory Permission Language, as a subset of TypeScript. Keto’s permission-language example

For a collaborative document application, consider this proposed policy:

Action	Access paths that permit it
Read	Edit permission, a direct viewer grant, membership in a group granted reader access to the document, or read permission inherited from an approved parent
Edit	A direct editor grant or membership in a group granted editor access to the document
Manage sharing	An explicit sharing-manager relationship on the document

This is an application-design proposal, not a complete Keto model. It makes editing imply reading—including for group-based editors—but keeps sharing administration separate. Group membership contributes access only when that group has the corresponding grant on the document. If sharing managers should also be able to read the document, encode that rule explicitly.

Likewise, define whether a workspace role applies to every resource or only to workspace administration. Avoid giving a global label such as member more authority than the product intends. If workspace boundaries restrict access, express those restrictions as explicit constraints.

Make inheritance and overlapping grants deliberate

Represent direct sharing, group membership, and parent-child resource relationships explicitly. Keto documents permission inheritance through groups, roles, and hierarchies; the application must choose which actions should inherit. Ory Keto documentation

For this example, choose a narrow rule: read permission on an approved parent folder confers document reading, but not editing or sharing administration. Other applications may need different rules; write those rules down before implementing them.

Consider a document that is readable through both a direct invitation and membership in the Design group, which also has a reader grant on the document. Under this additive policy, removing the invitation leaves group access intact. Revoking one relationship is not the same operation as eliminating every path to a permission.

Design the sharing interface around that distinction. When removing a grant, explain any remaining access paths the application can establish. Prefer wording such as “remove direct invitation” when the operation does not eliminate all access.

Treat resource moves as permission changes too. Under the proposed policy, moving a document between folders can change inherited access. Define who may move it, which destination is allowed, and what access should remain afterward. Test moves alongside invitations and removals, not merely as content-management operations.

Keep identity, delegated access, and resource authorization distinct

Ory’s documentation describes distinct responsibilities for its Ory Network services:

• Kratos-based identity management covers account flows. The documentation describes API-first identity management, including login, registration, recovery, and account management, with support for custom interfaces. Ory Kratos documentation
• The Hydra-based service provides OAuth 2.0 and OpenID Connect. Ory describes it as a headless API that can work with an existing user-management system. Ory Hydra documentation
• Keto covers resource permissions. Its permission-language example derives document-specific read and write decisions from relationships. Ory Keto documentation

In an architecture using these components, establish the caller’s identity, validate the requirements of any delegated API access, and then check the requested action on the specific resource. Do not treat a successful login or possession of a token as sufficient permission to read every document.

Use this separation to assign responsibilities, not as a checklist requiring all three products in every application.

Enforce permissions wherever data is returned or changed

Use trusted application services as enforcement points. A practical request-handling design is:

1. Establish the caller from validated authentication context, not a client-supplied user identifier.
2. Resolve the target resource and relevant workspace or parent metadata from trusted state.
3. Check the exact action on that resource, alongside applicable workspace constraints and API-access requirements.
4. Return protected content or perform the mutation only after an explicit allow decision.

Apply that design beyond the main document endpoint:

• Lists and search: authorize returned resources and any protected snippets or metadata.
• Exports: define checks for job creation, execution, and result download, including what happens when access changes between those stages.
• Real-time collaboration: authorize room admission, edits, and protected event delivery; define how active connections respond to revocation.
• Sharing changes: authorize relationship mutations themselves. Under the proposed policy, edit permission alone must not allow a caller to change sharing through another application route.

These are application enforcement recommendations, not claims that a permission service implements those checks for you. Assign an enforcement point to each protected operation.

Test permission changes, not just initial access

Use tests that exercise transitions and competing access paths. For the proposed policy, a useful starting matrix is:

Change or condition	Expected policy outcome
Remove the only direct viewer grant, with no other access path	Reading is denied
Remove a direct viewer grant while access through a reader group remains	Reading remains allowed
Remove group membership when it is the only access path	Reading is denied
Grant access through an editor group	Editing and reading are allowed; sharing administration is not
Move a document away from a folder that supplied inherited access	The old folder no longer supplies that inherited path; any other paths must be evaluated
Attempt access across a workspace boundary prohibited by policy	Access is denied
Attempt sharing changes with edit permission alone	The sharing change is denied
Authorization cannot produce a usable decision	Protected data and mutations are withheld

These are intended policy outcomes, not propagation-time guarantees. Exercise them through actual read, edit, export, and collaboration paths—not only through isolated permission checks.

If the application caches decisions or keeps long-lived connections, include those mechanisms in revocation tests. Set an application-level revocation target and measure the interval between a permission change and its enforcement across each protected path in the chosen deployment. Do not assume that defining the permission model also establishes enforcement timing.

A useful permissions design should make three things clear: why access exists, what changes remove it, and where the application enforces the resulting decision.