I need help with the remote_json authorizer. I need to extract the role of the user from the metadata_admin column of the identity but there seems to no way doing that without a custom endpoint to trigger a request to the admin api. Any Idea how I can manage this? I know moving the role to the metadata_public would work but I was told that saving role information in the traits is not secure enough.

authorizers:
  allow:
    enabled: true
  remote_json:
    enabled: true
    config:
      remote: <http://keto:4466/relation-tuples/check|http://keto:4466/relation-tuples/check>
      payload: |
        {
          "namespace": "api_access",
          "object": "endpoints",
          "relation": "access",
          "subject_id": "{{ print .Extra.identity.metadata_admin.role }}"
        }

Hi @acoustic-shampoo-32095. I’ve gained a little bit of experience with Oathkeeper, kratos and keto. In order to use identity information in the authorizer, you need to have the authenticator resolve that information. I’m guessing the setup that you have is that you are using Kratos identites, which you resolve using the ‘cookie-session’ authenticator. If you’d have the identity id, you could query the

admin/identies/{id}

directly. But I guess that implies some redirection (resolving session, then getting the user’s roles). https://www.ory.sh/docs/kratos/manage-identities/managing-users-identities-metadata#metadata I noticed you mentioned a tenant id you’d want to retrieve, however there’s this note on multitenancy: https://www.ory.sh/docs/kratos/guides/multi-tenancy-multitenant -----

Hi @fancy-wall-65751 , thanks for the input. Multi-tenancy is solved by myself using the database with a column called e.g. tenantId where I use this id to in each query. So I solved it by creating the tenantId for each identity and passing it upstream with the id_token mutator. It works fine. So I have just one database with all the users but each user may or may not in another tenant. Requesting metadata_admin information from admin/identies/{id} works but I would need to create a custom authorizer or authenticator I think. I was looking for a way where oathkeeter can manage this on its own like when using the whoamI endpoint without me creating custom code. I am currently using the metadata_public and it works, but I do not know if it is secure enough since it can be seen. not edited though. The Permission is based on the role each user has. I thought about how to make it as easy as possible and since the users are permitted to request the apis based on their roles, I just figured to include the role in the metadata of the user and check for this metadata at each requested route. I do not know how to do the zanzibar style without to much overhead. creating the tuples for the roles and the access rules for oathkeeper is already painful enough.

So I solved it by creating the tenantId for each identity and passing it upstream with the id_token mutator. It works fine. So I have just one database with all the users but each user may or may not in another tenant.

Interesting choice to link identities to a specific tenant. This implies that an identity can never be part of multiple tenants. I think can be especially difficult when dealing with OPS/admin accounts

Requesting metadata_admin information from admin/identies/{id} works but I would need to create a custom authorizer or authenticator I think. I was looking for a way where oathkeeter can manage this on its own like when using the whoamI endpoint without me creating custom code.

I am currently using the metadata_public and it works, but I do not know if it is secure enough since it can be seen. not edited though.

The less information you can expose to a user, the better. Unless there is a good use case for users to know / see their roles, I’d leave it out as much as possible. A tenantId might be somewhat harmless, but roles are a bit more tricky. I’m interested in Ory’s take on this as well.

I do not know how to do the zanzibar style without to much overhead. creating the tuples for the roles and the access rules for oathkeeper is already painful enough.

I’m gonna take a guess and state that you have a mechanism to initially set the metadata of the user that happens during registration, and maybe you have a sync mechanism as well, to make sure changes to any user’s roles are reflected. Alternatively, in kratos, the source of truth is maintained, and you have an admin flow to mutate a user’s roles. Rather than saving this information in the user’s metadata, you cold opt for syncing this with Keto directly, which is only a matter of changing the api call to kratos to keto iiuc.

Interesting choice to link identities to a specific tenant. This implies that an identity can never be part of multiple tenants. I think can be especially difficult when dealing with OPS/admin accounts

Thats what I am aiming for as of now. Maybe I will think about another approach where the user may be added to multiple tenants. But it is no prio for me.

I’m gonna take a guess and state that you have a mechanism to initially set the metadata of the user that happens during registration, and maybe you have a sync mechanism as well, to make sure changes to any user’s roles are reflected. Alternatively, in kratos, the source of truth is maintained, and you have an admin flow to mutate a user’s roles. Rather than saving this information in the user’s metadata, you cold opt for syncing this with Keto directly, which is only a matter of changing the api call to kratos to keto iiuc.

Yep, I have my own user database where I add the roles based on registration and user information update e.g. changing roles etc. these changes are also applied to the kratos identity which is then used to access api endpoints. When oathkeeper evaluates the requests it checks the role of the user. this role is then passed to keto to check if the requested api can be accessed with the role information of the user. In addition to this I send the tenantId, the role and the userId in an id_token upstream to the service where a middleware decodes these claims and adds them into the context. the handler then passed theses values to the service.

This user - role relation is something that belongs to keto, looking at it from the ory ecosystem. This separates the concerns identity mgmt and authority mgmt between Kratos and Keto. Adding an additional layer of users to your permission model may not seem trivial at first, but is definitely something worth investing in. An increased understanding, might also help you deal with nested roles (e.g. write role implies having a read role too).

@magnificent-energy-493 do you have a solution at how to retrieve the metadata_admin without writing our own whoami endpoint?