Firestore data structure and rules for multi organisation, multi user setup with variable roles

I'm quite new to NoSQL and Firebase/firestore in general (I have a strong background in traditional SQL however), so whilst I'm understanding most of the basics regarding options for data structure and how to create rules to manage read/write permissions etc, I'm having a hard time coming up with an 'elegant' solution to this in regards to data structure and simplicity of the client-side rules I'll be using. A key point is I'm trying to negate the need for any get() reads in the rules, which due to financial implications, I'm trying to avoid...

I'm writing an e-commerce related SaaS products where...

The app will have multiple private 'organisations' that are only visible to users that have these organisations assosiated with them.
The app will have multiple users, who can, in turn have access varying levels of access to multiple organisations. For e.g, a user may be a 'user' on one organisation and an 'admin' of another.
Each user will have a variable number of 'roles', in the form of such things as 'products.read', 'products.write', 'orders.read', 'order.write' etc etc

I started with a hierachy of products etc that all fall under a root 'organisation' collection and I have custom claims added to each user in the format of {"orgs": ["12345"]}... but I'm stuck on the permissions/roles side. I figured I could add a 'permissions' or 'access' collection to the organisation top level where the UID is the key and each role that a user may have would be under this ID... but that gave me only one option when it comes to the rules side of things. I'd have to use the get() function and thus I'd have to double spend for each access check as that would trigger another read.

Does anybody have any insight into a possible solution to this that doesn't require an inner get()? I'm sure this is a common pattern/problem, but I've come up short when googling and I guess my head is not in the right place at the moment so figured I'd reach out

Many thanks

As you have identified, storing relevant roles in a organisation-based user document (such as /organisations/{orgId}/privateUserData/{userId}) will offer one of the best solutions.

At the time of writing, Firestore pricing is $0.06c (USD) per 100,000 document reads (above the 50k/day free quota). Securing your data using one get() call in your rules, with all the relevant data needed being in /organisations/{orgId}/privateUserData/{userId}, would make the rate $0.06c (USD) per 50,000 secured document reads at worst.

What do you mean "at worst"? As long as you aren't reading documents 1-by-1 (e.g. directly by their id), you won't actually pay for these secured document reads at a 1:1 rate. If your query returns 100 documents in one go, you only pay for the 1 get() call as the result of that call is cached and reused for all validations in that query.

To apply that with an example, let's assume you are using a document optimized for ease of use that looks like:

/organisations/{orgId}/privateUserData/{userId}: {
  uid: "<userId>", // for collection group queries targetting a particular user
  orgId: "<orgId>", // for collection group queries targetting a particular organisation
  disabled: false, // for suspending users,
  roles: {
    "products.read": true,
    "products.write": false, // can also omit, as rules will assume false
    // ...
  },
  userProfile: { // duplication of data in NoSQL databases is common
    img: "https://...",
    displayName: "Example User",
    username: "exampleuser"
  }
}

We can then wire it up with these rules:

service cloud.firestore {
  // note: this is not JavaScript - it is Security Rules Language

  // True if the user is signed in, they exist in the organisation, and are not marked disabled
  function isActiveOrgMember(orgId) {
    return request.auth.uid != null
      && get(/databases/$(database)/documents/organisations/$(orgId)/privateUserData/$(request.auth.uid)).data.get("disabled", false) != true;
  }
  
  // True if the signed in user has the named role for the given organisation,
  // expected to be called after isActiveOrgMember(orgId) has returned true.
  function hasOrgRole(orgId, permission) {
    return get(/databases/$(database)/documents/organisations/$(orgId)/privateUserData/$(request.auth.uid)).data.roles.get(permission, false)
  }
 
  match /databases/{database}/documents {
    match /organisations/{orgId} {
      // Any member can read the org details
      allow read: if isActiveOrgMember(orgId);

      // Only admins can update org details
      allow write: if isActiveOrgMember(orgId) && hasOrgRole(orgId, "orgadmin");

      match /privateUserData/{userId} {
        // Only the named user (along with org admins) can read their own data
        allow read: if isActiveOrgMember(orgId)
                    && (request.auth.uid == userId
                    || hasOrgRole(orgId, "orgadmin"));

        // Only org admins can update a user's data (the Admin SDKs
        // can also make changes because they bypass security rules)
        // TODO: Add data validation (e.g. admins should not be able
        // edit userProfile data)
        allow write: if isActiveOrgMember(orgId)
                     && hasOrgRole(orgId, "orgadmin");
      }

      match /products/{productId} {
        // Any active member can read products documents if they have
        // the appropriate roles
        allow read: if isActiveOrgMember(orgId)
                    && (hasOrgRole(orgId, "products.read")
                    || hasOrgRole(orgId, "orgadmin"));
        // Any active member can write to products documents if they
        // have the appropriate roles
        // TODO: Add data validation (e.g. certain keys should be present)
        allow write: if isActiveOrgMember(orgId)
                    && (hasOrgRole(orgId, "products.write") || hasOrgRole(orgId, "orgadmin"));
      }
    }
  }
}

With the above setup:

• a read of /organisations/{orgId}/privateUserData/{userId} directly will incur a document read cost of 1. This is because the get() call is checking the same document being read and thus just returns the document as-is.
• a read of /organisations/{orgId} directly will incur a document read cost of 2. This is because the get() call needs to fetch the user's document.
• a read of /organisations/{orgId}/products/{productId} directly will also incur a document read cost of 2. This is because the get() call still needs to fetch the user's document.
• a list query of the top 100 products under /organisations/{orgId}/products will incur a document read cost of up to 101. At best, it will only cost 1 document read for the roles check that it uses to fail the query. At worst, it will cost 101 document reads - 1 for the roles check and 1 for each returned document.