Support for Relational Policies in CASL

[kenfdev]

Hi everyone,

I'm exploring CASL as part of a migration from Oso and encountered a challenge regarding relational (or hierarchical) policies. Specifically, I'm looking for a way to express policies where permissions on one subject imply permissions on a related subject.

For example, consider this use case:

• If a user can create on an Organization subject, they should also be able to create on an Issue subject related to that organization.

In Oso, this can be defined like this:
[Oso documentation on relationship-based access control](https://www.osohq.com/docs/modeling-in-polar/relationship-based-access-control-rebac/ownership#implement-the-logic)

However, IIUC, CASL does not natively support relational policies like the following pseudo-code:

allow('create', 'Organization', { conditions: { ownerId: user.id } });

allow('create', 'Issue', { conditions: can('create', 'Organization', { ownerId: user.id }) });

Questions

1. Is this possible in CASL? If not, are there any workarounds to achieve this?
2. How do others handle relational policies in CASL? For instance, how do you manage permissions when they are dependent on hierarchical or parent-child relationships between resources?

I'd love to hear your thoughts on how best to approach this with CASL or whether this is something that could be added as a feature.

Thank you for your input!

[stalniy]

Very often all tenant based application have tenant id over all tenant specific entities. For example, in your case very likely that Issue has relation to organization and basically has organizationId field.

If so, then your permissions are translated to this:

allow(create, Org, { owners: user.id})
allow(create, Issue, { orgId: { $in: user.ownedOrgIds }})

pseudocode above to show the idea of how it should be done in casl (user.ownedOrgIds is an array of all owned organizations ids by authenticated user)

[kenfdev]

This code looks fantastic! Thank you so much for taking the time to share such a detailed solution. It really aligns with what I’ve been trying to achieve, and I’ll definitely give it a try.

That said, as you pointed out, the restriction of not being able to translate CASL permissions into database queries using built-in helpers seems like a significant drawback for scalability. Here’s why it might be a concern for my use case.

Currently, I define my policies like this:

export function defineOrganizationAbilityFor({ user }: Input): Array<RawRuleOf<AppAbility>> {
  const rules: Array<RawRuleOf<AppAbility>> = [];

  rules.push( /* Whatever permission I want to add based on roles, etc. */ );

  return rules;
}

And then I build it all together like this:

export const defineAbilityFor = (user) => {
  const rules: Array<RawRuleOf<AppAbility>> = [];
  if (user.roles.includes("admin")) {
    rules.push({ subject: "all", action: "manage" });
  }

  const orgRules = defineOrganizationAbilityFor({ user });
  const repoRules = defineRepositoryAbilityFor({ user });
  const issueRules = defineIssueAbilityFor({ user });

  return createMongoAbility<AppAbility>([...rules, ...orgRules, ...repoRules, ...issueRules], {
    detectSubjectType: (item) => item.kind,
  });
};

If I understand correctly, using your proposed lambda-based approach (or the $where operator) would mean I can no longer use createMongoAbility. Is that right? If so, the flexibility I gain for defining relational policies would come at the cost of losing the ability to translate permissions into Mongo queries.

That’s a trade-off I was hoping to avoid, as the ability to query accessible records directly from the database is critical for larger applications. While I understand your point about adding tenant IDs for better partitioning and scaling, my goal was to keep the focus on subject relationships for now.

Remaining Questions

1. Would there be any way to manually build Mongo queries that replicate the permissions logic defined using PureAbility? For example, could I implement something custom to bridge this gap?
2. Is this limitation more by design, or is it something that could potentially be addressed in future CASL updates?

Thanks again for this incredible explanation and the examples. They’ve been super helpful in understanding how to approach this!

[stalniy]

You can still use createMongoAbility instead of PureAbility but this just has no any sense because createMongoAbility just creates PureAbility with default conditions matcher and field matcher. And if you are going to replace matcher, createMongoAbility will be just useless abstraction (ie., extra unneeded call) in your case.

Both approaches doesn't work with database query because on database level issue has no knowledge about organization at least very likely there won't be property organization which contains the full/partial info about organization. So, the restriction lives on data modeling layer.

Casl takes this simple, it won't try to solve complex querying requirements because it's just additional complexity. This is the reason I recommended to use tenant id (ie, orgId) based conditions instead of relying on hierarchy. I do not have plans to somehow integrate it to casl because there is an alternative via tenantId which is simpler in implementation and faster in execution. Though, it could be solved with aggregation pipeline joins, I've just checked that $lookup supports sharded collection from Mongo v5.1. So, this potentially opens door to improve this situation with permissions on related entities in mongo.

Also if you use Prisma, it can do "query magic" and for Prisma.js there is a separate package that allows to define permissions based on relations in Prisma, and then Prisma execs the query by itself in spite of its complexity.

[stalniy]

But even in case of aggregation pipeline, Mongo will need to join multiple collections together and then do filtering which for sure will be slower than tenantId approach.

There is no built-in way to replace part of permission conditions with something database will understand. But you can do it by using $where and with help of https://casl.js.org/v6/en/api/casl-ability-extra#rules-to-query . You will need to pass custom convert function which basically replicate built-in one. Something like this:

function customConvert(rule) {
  const conditions = rule.conditions.$where ? convertWhereToSmthDbUnderstands(rule.conditions) : rule.conditions;
  return rule.inverted ? { $nor: [conditions] } : conditions;
}

const query = rulesToQuery(ability, 'read', 'Issue', customConvert);
const result = query === null ? EMPTY_RESULT_QUERY : query as Record<string, unknown>;

[stalniy]

Code of built-in converter -> https://github.com/stalniy/casl/blob/master/packages/casl-mongoose/src/accessibleBy.ts#L4C1-L9
There you can find what EMPTY_RESULT_QUERY is

[kenfdev]

Thank you so much for the detailed sample code and explanation! The examples you provided are incredibly helpful for understanding how to approach this problem, and I really appreciate the time you took to share them.

That said, even with the solutions you outlined, it seems like a manual implementation is still necessary in cases where relational dependencies between subjects are required. Let me clarify my use case further:

Use Case

Suppose we have a Project subject and a ProjectWebsite subject, where ProjectWebsite has a parent-child relationship with Project (via projectId).

Permissions are as follows:
1. Any user can read a Project if it is public.
2. A logged-in user can read a Project if it is internal.
3. An admin user can read a Project regardless of its status.

Additionally:
• A user can read a ProjectWebsite if they can read the parent Project.

The key challenge here is managing the relational dependency between Project and ProjectWebsite. Specifically, the ability to read a ProjectWebsite depends on whether the user can read the associated Project.

Why Tenant ID (or Org ID) Isn’t Enough

In this case, the rule is based on the relationship between the subjects rather than attributes like tenantId or orgId. When checking if a user can read a ProjectWebsite, I need to verify whether they can read the parent Project.

However, I want to abstract this logic from the consumer of the API. Instead of requiring them to call can('read', 'Project', projectWebsite.project), they should only need to call can('read', 'ProjectWebsite', projectWebsite) without being aware of the parent-child relationship.

Manual Implementation Is Necessary

From what you’ve explained, the manual approach using $where and rulesToQuery seems mandatory for handling relational cases like this. I understand that rulesToQuery won’t automatically resolve these relationships, but being able to implement this logic manually is a powerful feature that sets CASL apart from other authorization libraries.

For example, the custom conversion function you provided is a great starting point for manual implementation.
This approach, while more manual, provides the flexibility needed for relational policies and makes it possible to implement these kinds of dependencies.

My Question (apologies about so many questions!)

Do you think I’m on the right track here? Or are there better approaches for handling relational dependencies between subjects? While I understand the performance trade-offs of relational policies, they seem unavoidable for use cases like this. I’d love to hear your thoughts or suggestions on alternatives!

Thanks again for the incredible examples and detailed explanations—they’ve been invaluable for my understanding of CASL!