Virtual ACL for `Pointer<_Role>` field via CLP

[stephannielsen]

New Feature / Enhancement Checklist

• I am not disclosing a vulnerability.
• I am not just asking a question.
• I have searched through existing issues.

Current Limitation

I am currently improving the authorization model of our application and researched in-depth what Parse offers and how I can leverage it in the best way. Our app basically provides a multi-tenant setup where users belong to a certain tenant and only have access to the data of that tenant. A user can have access data to multiple tenants. We plan on using a _Role for each tenant. This means, on each object we need to set the ACL for the object to that tenant role. That's fine and not a big deal, but I came across the virtual ACLs one can create by using a CLP for a Pointer<_User>. This kind of virtual ACL defined on CLP level is basically what we require - just not for a specific _User but for a specific _Role.

Feature / Enhancement Description

The idea for the enhancement would be to allow the pointer CLPs to either reference a _User (current state) or a _Role. Using a role pointer would then also create a virtual ACL for each object for that class.

Example Use Case

Apps with multi-tenant setup to separate data between tenants. Tenants can be represented as roles.

Alternatives / Workarounds

Use ACLs and set the ACL for a tenant _Role explicitly on each object for a class.

3rd Party References

No, but also have only limited experiences with other providers.

[parse-github-assistant]

Thanks for opening this issue!

• 🎉 We are excited about your ideas for improvement!

[Moumouls]

@stephannielsen I think the parse server already supports your use case.

You can create a Parse.Role with the name "admin", and then use it in your CLP like this.

create: {
    'role:admin': true,
},

Another example

	classLevelPermissions: {
		find: { '*': true },
		count: { requiresAuthentication: true },
		get: { '*': true },
		update: { 'role:Admin': true },
		create: {},
		delete: {},
		addField: {},
		protectedFields: {},
	},

[Moumouls]

@stephannielsen feel free to close this issue if my answer is correct and fulfill your use case 🙂

[stephannielsen]

@Moumouls thank you for the response but no, I don't think this covers our use case.

Using a role in CLP would allow all users with that role allow to perform the create/update action on this class, on any object in it. What we require is to limit access to a specific object within a class for one role.

The Pointer<User> as CLP acts as a virtual ACL. On CLP, you configure which field in the class points to a user - only allowing this user to perform the action defined in the CLP. The requested feature is to extend this functionality so the CLP can also point to a field which is of type Pointer<Role>. And then Parse validates access for this object against this role field.

[Moumouls]

Thanks @stephannielsen for additional details, could you provide an example of the CLP object that you have in mind with the virtual pointer on role ? ( Like the one that I provided above )

[stephannielsen]

Sure. I would expect it to look the same as it does for user pointer CLPs. Unfortunately, those are not documented to my knowledge with examples, but here is a PR for impoving the docs for them: parse-community/docs#700

Based on that it would look like this:

{
  "classLevelPermissions":
  {
    "get": {
      "pointerFields": ["owner", "subscribers"]  // Pointer<User>, Pointer<Role> or Array<Pointer<..>>
    },
    "find": {
      "pointerFields": ["owner", "subscribers"]
    },
    "create":{
      "*": true
    },
    "update": {
      "pointerFields": ["owner"]
    },
    "delete": {
      "pointerFields": ["owner"]
    }
  }
}

Or grouped:

{
  ...,
  "classLevelPermissions":
  {
    "create":{
      "*": true
    },
    // notice these are root level properties:
    "readUserFields": ["owner", "subscribers"],
    "writeUserFields": ["owner"]
  },
}

To be honest - I have not used CLP pointers yet and I even just failed to configure a pointer CLP on a test class via the dashboard.