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]

Thank you for the detailed response!

I understand the approach of using attributes like ownedOrgIds to define permissions, but my use case is slightly different. I'm trying to focus on the relationships between subjects themselves, rather than the user's ownership of attributes. This distinction becomes important when scaling the system to more complex hierarchies.

For example, consider the following scenario:

• An Organization can have child Repositories, and a Repository can have child Issues.
• If a user has admin permission on an Organization, that should inherently grant them create permission on its child Repositories and Issues without needing to explicitly define permissions for every layer in the hierarchy.

The idea is that the relationship between Organization -> Repository -> Issue dictates the cascading permissions. Here’s what I envision:

allow('admin', 'Organization', { id: orgId });
allow('create', 'Repository', { parent: can('admin', 'Organization') });
allow('create', 'Issue', { parent: can('create', 'Repository') });

This would allow permissions to flow naturally through the hierarchy without requiring user-specific attributes like ownedOrgIds or ownedRepoIds.

If we were to rely solely on attributes (e.g., ownedOrgIds), it wouldn't scale well in cases where:

1. The hierarchy becomes deeper or more complex (e.g., Organization -> Division -> Department -> Resource).
2. Users might need indirect permissions inferred from their access to parent entities.

In systems like Oso, this can be expressed via relationship-based access control (ReBAC) where permissions cascade based on relationships between entities.

So I have a feeling this is not possible in CASL?

I appreciate the suggestion to use ownedOrgIds, but I’d like to know if CASL can support relational policies directly or if there are alternative best practices for managing these types of hierarchical permissions.

Thanks again for your insights and help!

[stalniy]

There is no such thing in casl but you can get it with some restrictions (e.g., you won't be able to translate casl permissions into database query with built-in helpers). To do this, you can switch to lambda based permission definition or define custom $where operator.

So, the entities:

class Organization {
  constructor(ownerId) {
    this.ownerId = ownerId;
  }
}

class Issue {
  constructor(org) {
    this.org = org
  }
}

Lambda version:

const lambdaMatcher = (matchConditions) => matchConditions;

export default function defineAbilityFor(user) {
  const { can, build } = new AbilityBuilder(PureAbility);

  can('create', Organization, (org) => org.ownerId === user.id);
  can('create', Issue, (issue) => ability.can('create', issue.org));

  const ability = build({ conditionsMatcher: lambdaMatcher });

  return ability
}

The same with $where operator (compromise, allows to integrate lambda functions in permissions):

import {
  createMongoAbility,
  AbilityBuilder,
} from '@casl/ability';
import { $in, within, $eq, eq, createFactory, $where, where } from '@ucast/mongo2js';

const conditionsMatcher = createFactory({
  $in, $eq, $where,
}, {
  in: within, eq, where
});

function defineAbilityFor(user) {
  const { can, build } = new AbilityBuilder(createMongoAbility);

  can('create', Organization, { ownerId: user.id });
  can('create', Issue, { 
    $where() {
      return ability.can('create', this.org);  // `this` points to issue which we test permissions on
    }
  });

  const ability = build({ conditionsMatcher });

  return ability;
}

and the code to evaluate this thing:

const ability = defineAbilityFor({ id: 1 })

const ownOrg = new Organization(1);
const ownIssue = new Issue(ownOrg);

const anotherOrg = new Organization(2);
const anotherIssue = new Issue(anotherOrg);

console.log({
  canCreateOwnIssue: ability.can('create', ownIssue),
  canCreateAnotherIssue: ability.can('create', anotherIssue),
});

Full working example:

Example

import {
  createMongoAbility,
  AbilityBuilder,
  PureAbility,
} from '@casl/ability';
import { $in, within, $eq, eq, createFactory, $where, where } from '@ucast/mongo2js';

const conditionsMatcher = createFactory({
  $in, $eq, $where,
}, {
  in: within, eq, where
});

// function defineAbilityFor(user) {
//   const { can, build } = new AbilityBuilder(createMongoAbility);

//   can('create', Organization, { ownerId: user.id });
//   can('create', Issue, { 
//     $where() {
//       return ability.can('create', this.org); 
//     }
//   });

//   const ability = build({ conditionsMatcher });

//   return ability;
// }

const lambdaMatcher = (matchConditions) => matchConditions;

function defineAbilityFor(user) {
  const { can, build } = new AbilityBuilder(PureAbility);

  can('create', Organization, (org) => org.ownerId === user.id);
  can('create', Issue, (issue) => ability.can('create', issue.org));

  const ability = build({ conditionsMatcher: lambdaMatcher });

  return ability
}

class Organization {
  constructor(ownerId) {
    this.ownerId = ownerId;
  }
}

class Issue {
  constructor(org) {
    this.org = org
  }
}

const ability = defineAbilityFor({ id: 1 })

const ownOrg = new Organization(1);
const ownIssue = new Issue(ownOrg);

const anotherOrg = new Organization(2);
const anotherIssue = new Issue(anotherOrg);

console.log({
  canCreateOwnIssue: ability.can('create', ownIssue),
  canCreateAnotherIssue: ability.can('create', anotherIssue),
});

[stalniy]

Then you get same thing as in OSO but you loose some flexibility.

Still, I'd recommend to use tenant id because when your app will grow, you will want to shard/partition data. And in that case you will be just forced to add organizationId to every nested entity to ensure that they live on the same shard.

The additional benefit you will get is a possibility to fetch accessible records from db, basically translate permissions to db query and check them on db level

[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>;