Give All Users Access to a Resource

[snasphysicist]

I am wondering, what is the idiomatic/standard way to allow access to a certain resource to all users? For example, building on https://www.ory.sh/docs/keto/guides/userset-rewrites, suppose we want File keto/README.md to be accessible to any user (i.e. if we query relation view for File keto/README.md, we will get allowed: true for any subject_id or subject_set value). How should that be achieved?

I couldn't find any resources at all which suggest how to do this with the Google Zanzibar approach from a quick-ish Google.

I thought of the following approaches, which I don't think are actually a good idea or are not supported.

1. Assign the viewers permission for a User named public, then add checks like this.related.viewers.includes("public") - this is explicitly disallowed by the OPL specification (we can only put .includes(ctx.subject).

2. Add a Publics namespace, then add a related for these like related: { publicviewers: Public[] } and add checks like this.related.publicviewers.traverse((p) => p.permits.permit(ctx)), and in the Publics a permit something like permits: { permit: (ctx: Context): boolean => true} - this is not very scalable, adds a lot of boilerplate, and is allowed explicitly disallowed by the OPL specification

To be clear, I would like this to be able to work for both logged in users (who have a unique subject field) and not-logged-in users (who have a default or empty subject field).

So I'm at a bit of a loss - I don't see a clear way to achieve this relationally.

Thanks in advance for any help!

[istarkov]

I would make 2 checks. One for a user, another on Permission:public
i.e.

keto check Permission:public view File SomeFile
keto check User:AliceUUID view File SomeFile

1st check can be cached +-forever and be very fast.

[snasphysicist]

Thanks for the suggestion, that's not a bad approach. The only disadvantages I see are that it introduces an additional "permission" concept over and above the "permits", and that the client has to do 2 checks in place of one (not a huge problem, could be hidden away in a custom client library).

We'll take this into consideration as we continue to develop our permissions model. Thanks again!