Usually you have that role up to a

platform

object with an admin role on it. You still have to have some relationship on every resource, but not for every admin. https://authzed.com/blog/schema-language-patterns/

Great, It will work! Can I ignore the platform ID?

yes

I found this in the docs: > SpiceDB supports an optional prefix for Object Types that can be used for logically separating types when multiple tenants are using the same deployment. https://authzed.com/docs/reference/glossary#notable-differences Where can I found more about it (tenant)?

its mostly a convention

Ok, I got know ...

you'd generally have a different relation for the organization and the user

I didn't understand ... I can have for example, the same system with the same schema running in different namespaces, and each namespace being accessed by a different client. MySystem1 -> Company1 MySystem2 -> Company2 Both have the same schema (because are the same system) in spicedb. With this I will have 2 admins tuples. Do I need to do that to reach this using the same spicedb instance?

mysystem1/resource { ... }

mysystem2/resource { ... }

> and each namespace being accessed by a different client. there is only one schema

What I'm trying is to have something like a tenant. MySystem1 (bussines db1) -> Company1 MySystem2 (bussines db2) -> Company2 Both are the same system, but running with its own database, they have the same schema and resource types. Do I need two instances of spicedb? One for each MySystem instance.

if you want them to be completely isolated, yes

In my case I don't need it, doesn't make sense to create a new spicedb replica for each new client/system instance. I understand that I can have a

platform:1#admin#user:1

and

platform:2#admin#user:2

But if I use the schema below, I will have resources from

platform:1

and

platform:2

in the database. For example,

resource:1

is from

platform1

and

resource:2

is from

platform2

So, if I check

resource:1#admin#user:1

I will get true (its ok,

user:1

and

resource:1

are from the same platform) But if I check

resource:2#admin#user:1

I will get true (its not ok,

user:1

is from the

platform:1

and

resource:2

is from

platform:2

)

definition user {}
definition platform {
    relation administrator: user
    permission super_admin = administrator
}
definition organization {
    relation platform: platform
    permission admin = platform->super_admin
}
definition resource {
    relation owner: user | organization
    permission admin = owner + owner->admin
}

that's only true if you link the resources' parent organization(s) both to the same platform

Hi @erickhgm - just wanted to make sure you got the answers you're looking for here?

Yes, I'm a little busier this week, so I didn't took the channel...