Hydrator passes headers from original request to hydrate endpint

[pike1212]

Is your feature request related to a problem? Please describe.

Calls to the hydrate endpoint pass along all the headers of the original request including the authorization headers (including the original Authorization header which might not be valid for the hydrate call).

Describe the solution you'd like

I'd like the ability to configure it to not pass the headers

[aeneasr]

Do you want to simply disable this or also have the ability to overwrite headers?

[Sbou]

I think the issue is how the Hydrator receives the headers.

For me, the headers of the original request should be in the Header field of AuthenticationSession and we would have differents headers for the Hydrator request itself.

I wrote a topic about this in the forum related to this issue. https://community.ory.sh/t/how-to-use-headers/1382

What do you think about that ?

[aeneasr]

So in general this functionality is like a passthrough request - we're simply proxying the request to the upstream. There it is considered best practice to do it the way it's currently solved.

I understand however that you'd like to overwrite the, for example, authorization header. Could you maybe elaborate why having the original headers is a problem, or what you'd like to modify?

[pike1212]

I am not sure I would consider the hydrate request a simple proxy. Many of the headers in the context of the original request could be problematic for the service handling the hydrate request, i.e. Authorization, Content-Type, Accept. At a minimum, I think we need the ability to specify a list of a headers to overwrite / remove.

[aeneasr]

Right, that's a good point. Those should be (un-)set explicitly, especially Accept and Content-Type.

@piotrmsc what do you think? Would that cause an issue/regression in Kyma?

[aeneasr]

/reminder @piotrmsc

[DimitarPetrov]

We also hit the Authorization header problem. In our case, all the endpoints are secured by RequestAuthentication istio resource which automatically checks the Authorization header.

Oathkeeper is excluded from this policy and the policy trusts oathkeeper's id_token JWKS. However when we call oathkeeper it authenticates the request, but sends the original Authorization header to the hydrators which are inside the mesh and therefore secured with the RequestAuthentication, but the original Authorization header is not id_token therefore not trusted.

It is a bit of a mess when oahtkeeper forwards this header because all the issuers and authentication mechanisms cannot be isolated in the oathkeeper's authentication chain and strictly assume that everything down the flow will trust only id_tokens.

[BobClaerhout]

I'm running into this issue because I'm authenticating an SSE call. The incoming Accept header is still text/event-stream while the mutator actually expects a JSON serialized AuthenticationSession. This doesn't make sense at all.
The issue here is pretty quite while I can image others are bumping into this as well.
Any progress on this? Or is there a workaround? Is it possible to set an outgoing header to the mutator somehow?

[github-actions[bot]]

Hello contributors!

I am marking this issue as stale as it has not received any engagement from the community or maintainers for a year. That does not imply that the issue has no merit! If you feel strongly about this issue

• open a PR referencing and resolving the issue;
• leave a comment on it and discuss ideas on how you could contribute towards resolving it;
• leave a comment and describe in detail why this issue is critical for your use case;
• open a new issue with updated details and a plan for resolving the issue.

Throughout its lifetime, Ory has received over 10.000 issues and PRs. To sustain that growth, we need to prioritize and focus on issues that are important to the community. A good indication of importance, and thus priority, is activity on a topic.

Unfortunately, burnout has become a topic of concern amongst open-source projects.

It can lead to severe personal and health issues as well as opening catastrophic attack vectors.

The motivation for this automation is to help prioritize issues in the backlog and not ignore, reject, or belittle anyone.

If this issue was marked as stale erroneously you can exempt it by adding the backlog label, assigning someone, or setting a milestone for it.

Thank you for your understanding and to anyone who participated in the conversation! And as written above, please do participate in the conversation if this topic is important to you!

Thank you 🙏✌️