One problem you avoid by centralizing is replicating the business logic to determine whether an entity should be able to access an object everywhere you want to access that object.

We are working on a feature for our commercial offerings that offers downscoping of access tokens to limit writing relationships and checking permissions to a subset, per caller.

From what I have read, AirBnB and Google are the most well known companies using this sort of approach. Facebook on the other hand, (who have a very complex permissions model) build this into the domain model, so any user/service accessing data, is guaranteed to only get data they have permission to view. No need for every service to check, and impossible for them to not check, or apply the permissions incorrectly even after checking. This seems to be a common approach from other smaller companies I have discussed with. Each service is responsible for its own permissions. And when data is propagated between services (e.g. via RPC), permissions should be applied at this time.

With the Facebook model it would be very hard to do the “some recipients don’t have access to a document linked in this email” use case that exists between gmail and google docs.

As it stands, yes, you are right. It would require trying to load the document for each recipient user and checking the result. That seems mostly a performance concern though, although there may be others such as creating a valid auth context for each recipient. But would you not be able to expose the 'can user x view post y in the service API if this was really needed? You are essentially doing this anyway with your common auth service. Maybe it would be an organisational bottleneck if you implement this differently per service? But I'm not sure reading permissions without data is common/general enough of a problem in most businesses to justify a general system for it.

The system you're describing for facebook (of which I have no prior knowledge) which makes it impossible to load data that you shouldn't have access to, should also make it impossible to impersonate another user, no? Wouldn't getting access to unauthorized data as a caller just be as simple as saying: "give me all of the posts as zuck"? where zuck is obviously just a root user of some sort.

I believe you are now talking about identify management (Authentication). That would fall into the caveat I mentioned 'creating a valid auth context for each recipient'. It would be somewhat system dependent whether this would/should be possible. e.g. 'Is Gmail trusted to get Docs for any user?'. Is permissions here about business rules or security? If it's about security then it doesn't really make sense to separate data and permissions because I could just bypass the permissions, ignore the result, or even worse, apply it to the data/logic incorrectly. In this case where we want to view permissions, and also apply them as security, then essentially the permissions have become a separate (related) resource to the data, in which case, a separate endpoint/method to access permissions makes sense. But that doesn't directly imply a generalised implementation across verticals?

Will this feature be available in on-prem enterprise license ?

Yessir!

That's great! We have raised in our org for on-prem, any plan to have tool for Schema Parsing ?

yes, we have issues filed for a reflection API and we have thoughts of adding the output to

zed

as well potentially

Hi Team - Is there a grpc function exist to find all type in the schema and all the relation & permission associated with the type in a structured format. or parsing the schema file is the solution in this case?

hello. when i try to create a bunch of new relationships using

zed

, at some point, i start getting failures. the commands are something like:

zed relationship create event:1 organization organization:1
zed relationship create event:2 organization organization:1
...
zed relationship create event:27 organization organization:1

it creates maybe 15 or 20 relationships, and stops - everything after that fails. if i re-run the failed commands one-at-a-time, relationships are created. this is with v1.12.0 server.

@Igor.Shmukler anything visible in the logs? Are you using PSQL datastore? You can batch writes with

zed

, that should help. A complete overhaul of PSQL datastore is now in

main

though not yet released. We are confident that write throughput is greatly improved with the new design.

@Prchowdh unfortunately not, see the comments above - this is part of the "Reflection API". I don't think we have a tracking issue for that, @Joey mind opening one? 🙏🏻

I see the below:

{
  "level": "error",
  "module": "pgx",
  "args": [],
  "err": "timeout: context canceled",
  "pid": 9556,
  "sql": "rollback",
  "time": "2022-10-06T01:04:00Z",
  "message": "Exec"
}

and similar errors, like:

{
  "level": "error",
  "module": "pgx",
  "args": [],
  "err": "timeout: context already done: context canceled",
  "pid": 17230,
  "sql": "rollback",
  "time": "2022-10-06T01:04:28Z",
  "message": "Exec"
}

and

{
  "level": "error",
  "requestID": "2d4033346ccea3928525804283ec7f8e",
  "error": "timeout: context already done: context canceled",
  "time": "2022-10-06T01:04:28Z",
  "message": "error running transaction cleanup function"
}

is the

complete overhaul of PSQL datastore

planned for v1.14.0 or what release? what sort of a timeframe do you estimate for it to make a release?

Yes v1.14.0, and we are working very hard on finalizing the migration strategy. If you are starting fresh or doing isolated testing, I would see if what is in main right now solves your issue.

@Jake when you talk about "migration strategy", are you talking about the migrations in https://github.com/authzed/spicedb/tree/main/internal/datastore/postgres/migrations ? I've just tried running them on a copy of our production database to anticipate a future upgrade: the migration 9 would lock our

relation_tuple

table for >1h30 (it's still running as I'm writing this) 😬

Yeah, that's a good datapoint, i'll probably need to change that pure SQL migration to one that runs incrementally and is managed by code

It just finished:

backfillTupleXIDColumns

took 98min on a database with no traffic and 10M rows.

backfillTransactionXids

took 11s which is already pretty blocking!

I was afraid that was part of v1.13.0 and I couldn't upgrade 😅

how many

relation_tuple_transaction

rows do you have?

@john.conti structured errors have been merged and should go out with the next SpiceDB release https://github.com/authzed/spicedb/pull/858. Errors are documented here: https://buf.build/authzed/api/docs/main:authzed.api.v1#authzed.api.v1.ErrorReason

new to SpiceDB and running a POC - I just used the helm operator to install the basic CRD from the example. I am able to use the zed cli to write schema/relationships, but unable to check permissions. When I do, I get a

transport: Error while dialing dial tcp 10.30.59.76:50053: connect: connection refused

- I have both 50051/50053 port-forwarded locally. Any help would be appreciated!

you're using the operator or...?

We are using spicedb v1.9.0 - this version works fine. When we call probe

kubectl exec svc/spicedb -ti -- grpc_health_probe -v -addr=localhost:50051

It returns

> addr=localhost:50051 conn_timeout=1s rpc_timeout=1s
> tls=false
> spiffe=false
establishing connection
connection established (took 2.104947ms)
time elapsed: connect=2.104947ms rpc=2.228704ms
status: SERVING

But when we switch to version v1.10.0 and higher, the probe tells us that it does not serve, but it is not true. The spicedb works fine.

> addr=localhost:50051 conn_timeout=1s rpc_timeout=1s
> tls=false
> alts=false
> spiffe=false
establishing connection
connection established (took 1.46186ms)
service unhealthy (responded with "NOT_SERVING")
command terminated with exit code 4

Do we need to make special configuration adjustments when upgrading to version 10 or higher?

check the logs from startup - one of more of the health checks is likely failing

Maybe this is the reason?

datastore health context was canceled