Using custom fields from JWT for Multi-Tenancy

1

It is seen from the configuration for JWT is that we can only extract the user and roles from the token. Use of dynamic variables can allow us to map a single role definition to appropriate access_control_rules:

#Example configuration
jwt: 
 - name: vimana_jwt_provider
   signature_algo: HS256
   signature_key: ""
   user_claim: sub
   roles_claim: prm
   header_name: Authorization

access_control_rules:
  - name: Valid JWT token with a writer role
    indices: ["@{user}-*"]
    jwt_auth:
      name: "custom_jwt_provider"
      roles: ["kibana_access_role"]

The auth service can provide a JWT token with a special key called tenant or tnt to mark which tenant that user belongs to. So, if the JWT provider were to expose more properties for the access_control_rules configuration, we can achieve a ACL configuration that looks like the following:

- name: Valid JWT token with a writer role
  indices: ["@{tnt}-*"]
  jwt_auth:
    name: "custom_jwt_provider"
    roles: ["kibana_access"]

One workaround that we can think of is to use tenant name as username and create RO/RW access_control_roles mapped to appropriate JWT roles. However, this workaround will limit auditing capabilities.
How can we achieve the same? Are there any more workarounds that we can utilise? Should there be a feature request that can pick various values from a JWT token and make it available to access_control_roles? Have I missed certain parts of configuration?

2

currently we don’t support the use of arbitrary JWT claims as dynamic variables. A PR would be appreciated. However, a workaround is to use HTTP headers, those are all accessible via dynamic variables.

1 Like
3

The JWT, since it is signed, ensures the tenent value is authorized. How would that be ensured if headers were used?

4

I’m guessing we would inject a proxy in front of ror that sets or removes the headers we use as variables. Of course that would mean we don’t use ror jwt functionality at all, but rather implement full auth in the proxy.

5

Yeah that was a proposed workaround. The solution would be the PR.

6

Yes, this is one solution.

7

This would be super useful on my end also. Manually adding a user is a bit of a headache and being able to dynamically do it via a field in the token would be a life saver. +1