Allow whitelisted session variables to be passed through HTTP headers

[lanthaler]

Currently all X-Hasura-* HTTP headers are filtered and not available to to be used in column presets or permission checks. This means that switching between organizations in the example use case in the docs requires to either use webhook based auth or to get a new the JWT each time the user switches to a different organization.

I discussed this briefly with @coco98 on Discord and he mentioned this is for security reasons. I do understand the reasoning but don't think it should apply to all headers. Enforcing that the user only acts on behalf of allowed organization is still possible. Similarly, there are probably plenty of use cases where it the information passed via a HTTP header has nothing to do with auth (I'm thinking of things such as passing the client version, A/B experiment logging etc.).

Would it be possible to whitelist certain headers to be used as session variables?

[ecthiender]

Interesting use-case.

I'm trying to break this down with an example. Please correct me if I misunderstand at any point.

Let's say for the multi-org example - you want to issue a single JWT which contains the list of orgs the user belongs to? And then from the client you want to send a particular header to indicate the current org? But, where would you validate that the client is sending the correct org-id, and that the user is actually allowed access to that org-id? The JWT contains the list of allowed orgs for the user, but where can this validation happen? So I'm not sure what the possible solution can be here.

For the non-auth use-cases: let's say you want to send client version as a header, and then use this value in the permission to restrict some tables/columns to the user. And if this header is just directly passed from the client (i.e. no auth server is "validating" it), wouldn't it be possible for the client to just spoof it?

A detailed example of your use-case would be helpful for us to understand what the exact limitation is, and what are the possible solutions.

[lanthaler]

Sorry for the late reply. I missed the notification about your comment somehow. Answers inline below

Let's say for the multi-org example - you want to issue a single JWT which contains the list of orgs the user belongs to?

Maybe but that's not supported anyway at the moment (#1333). Currently I'd just look into a particular table in the DB to check whether a user does indeed belong to a specific org.

And then from the client you want to send a particular header to indicate the current org?

Correct.

But, where would you validate that the client is sending the correct org-id, and that the user is actually allowed access to that org-id? The JWT contains the list of allowed orgs for the user, but where can this validation happen? So I'm not sure what the possible solution can be here.

As long as there's a user-organization table I could check it by setting up a check for the org and the corresponding user ID which would come from the JWT as usual.

For the non-auth use-cases: let's say you want to send client version as a header, and then use this value in the permission to restrict some tables/columns to the user.

If I would use it to "restrict some tables/columns to the user" it would actually not be a non-auth use case.

And if this header is just directly passed from the client (i.e. no auth server is "validating" it), wouldn't it be possible for the client to just spoof it?

Sure, but since it's a non-auth case I wouldn't particularly care. I would just log the value. Think of an A/B experiment. The client would simply send the experiment ID A or B and I would silently log it in all relevant tables without having to touch all queries. A similar use case would be passing some marketing campaign, or affiliate ID along.

Of course, everything that can be send as a header, could also directly be included in the query. I think it would still be beneficial though to not to have to pollute all query interfaces by such cross-cutting concerns such as experiment logging or organization IDs.

I hope this clarifies it. If not, please let me know and I'll give it another try.

I haven't written any Haskell before so it's quite difficult for me to understand the code base but perhaps I'd be able to get this implemented with a little help from your side. I'd be happy to contribute a PR

[lanthaler]

Thoughts?

[0x777]

Sorry for the late reply! Somehow missed this.

I can see how this feature could be useful. Where would you specify what headers are allowed? Couple of options:

1. In permissions. I'm not sure if this a great idea. Imagine you allow x-hasura-h for select permission for role 'r' on table t1 but not on table t2 and if you request t1 and t2 (say through relationship) the engine wouldn't know what to do.
2. Part of authorization. In case of JWT, the claims can have a list of allowed_client_headers? Similarly the webhook can also return something similar? I like this better. However you lose the ability to configure this per table/permission.

Would this work?

[lanthaler]

I'm not sure I follow so let me try to explain how I see it. Currently Hasura filters all custom headers so that they aren't available to be used as default values or in (permission) checks. I'd like developers to pass data for cross-cutting concerns (selection of organization, logging, etc.) through headers so that not all queries have to be polluted. JWT would work, but I'm not sure what it would buy us. On the other hand, it unnecessarily increases the size of the JWT.

Ideally, I'd be able to specify a name as server flag or environment variable and would then be able to send arbitrary headers in the form of <name>-* that I can use for default values and checks (in case you wonder why I dropped the x- prefix).

In case you don't want to introduce such a blanket approach, I'd probably suggest to pass a list of allowed headers as server flag or env. variable that can then be used as usual in the form of x-hasura-<name>. The downside of this approach is obviously that you have a single namespace and apps my start to use something that you then later need to for Hasura itself.

[0x777]

JWT would work, but I'm not sure what it would buy us. On the other hand, it unnecessarily increases the size of the JWT.

The only question here is to decide on the granularity with which this (allowing client side headers) can be configured. Few options:

1. Global like you suggested, take a regex/list of headers
2. Per user, by making it part of the authorization, i.e, jwt or webhook
3. Per permission (this is the bit I was talking about under (1) in my previous reply)

[lanthaler]

The global one seems by far the easiest to implement and understand. Can you think of any disadvantage it might have?

The cons I see for 2) are increased overhead (JWT size increases) and complexity (the authentication service needs to know about additional, potentially completely auth-unrelated headers). I'm still not sure I fully understand what you have in mind for 3) but you already pointed out a problem in your previous comment

[lanthaler]

Friendly ping

[0x777]

Hi, sorry about the delay in getting back to you.

Global setting

Having this setting globally is definitely easy to implement. However I'm a little apprehensive about this feature (global setting) as even a slight misuse (or incorrect use) could mean that the permission rules may not be restricting access as they are supposed to. However we can add it as an advanced feature.

Per user setting

Increased JWT size

The JWT size will increase. However, it also means that the you have more control, only select users can now be allowed to set headers from the client.

.. additional, potentially completely auth-unrelated headers

Once you start using these variables in permission rules don't they become part of your app's authorization logic?

When we add this, we'll add it both globally and per user as part of JWT/webhook.