feat: implement unauthorized passthrough of requests

[bastianjoel]

resolves #232

[sevensolutions]

Hi @bastianjoel,
thanks for submitting this PR and sorry for the delay.

I have a few questions about this or things I want to mention:

• Unfortunately, when thinking of 🚀 FR: Support passing headers on bypassed routes #232 i dont really like the naming of the setting. UnauthorizedPassthrough makes me think that all requests are sent upstream. But then why would one use the plugin at all if one wants unauthorized passthrough?
• There is an option called BypassAuthenticationRule by which you can route "some" requests upstream, even if unauthorized. In other words this allows some routes to be public.
• 🚀 FR: Support passing headers on bypassed routes #232 is mainly about passing headers to these public routes, even if the user is not authorized.

What do you think about adding an option which controls "when" headers are sent.
Eg.

SendHeaders: "OnAuthorized" (default)
SendHeaders: "Always"

But: While writing my reply and thinking about this whole thing I'am questioning: Do you really want "unauthorized passthrough" in terms of forwarding every request upstream, even if the user not authorized? And if yes, could you please give me a use-case for that?

[bastianjoel]

Thanks for taking a look!

Unfortunately, when thinking of #232 i dont really like the naming of the setting. UnauthorizedPassthrough makes me think that all requests are sent upstream. But then why would one use the plugin at all if one wants unauthorized passthrough?

I agree that the naming might not be ideal. We have some services in our stack that do not require a user to be authenticated. In that case we want those to pass the Authorization header to those services while they remain accessible for non authorized users.
The main reason why we want to use the library is because it handles the OIDC logic and resolving a session cookie to a Authorization header we can use across our services.

There is an option called BypassAuthenticationRule by which you can route "some" requests upstream, even if unauthorized. In other words this allows some routes to be public.

I am aware of this. The problem is that routes listed for that option do not receive information about the currently authenticated user.

#232 is mainly about passing headers to these public routes, even if the user is not authorized.

The reason why I implemented it via a "global" setting is because we only need this on a per service level. This is also suggested in the issue:

Essentially I would like to use BypassAuthenticationRule on everything other than the login query and supply the headers to the rest of the application if a session is present.

However I see that it might make more sense to couple this to the BypassAuthenticationRule config. I will update my PR in the next days. SendHeaders sounds good.

Do you really want "unauthorized passthrough" in terms of forwarding every request upstream, even if the user not authorized? And if yes, could you please give me a use-case for that?

We might do not want that but instead just for unauthenticated. This is more for error handling as we need one of our services to be always reachable even if something weird happens. In that case no Authorization header should be passed to the service. But I have to admit that I might lack knowledge here. So I am happy to be corrected.

Our use case will be https://github.com/OpenSlides/openslides-autoupdate-service for that. We have a single route there where a user can request data. This data is then restricted by the service itself which can also handle "anonymous" users and provide only public information to those.

[sevensolutions]

Thank you for the explanations @bastianjoel.
Ok, i think both use-cases are valid. Here is what i have in my mind:

A) Always sending requests to the upstream, no matter if they're authenticated or not. For this scenario we could add another value to the UnauthorizedBehavior config. Currently we have "Challenge" and "Unauthorized". We could add something like "Forward" which would still forward the request, even if it's not authorized. So in this case the upstream can handle it itself.
Here is a diagram. The last option is the new one:

sequenceDiagram
  alt Unauthorized Request with Unauthorized Behavior=Challenge
    Client->>traefik: Request
    traefik->>Client: Redirect to IDP
  end
  alt Unauthorized Request with Unauthorized Behavior=Unauthorized
    Client->>traefik: Request
    traefik->>Client: Unauthorized (401)
  end
  alt Unauthorized Request with Unauthorized Behavior=Forward
    Client->>traefik: Request
    traefik->>Upstream: Forward Request
    Upstream->>traefik: Response    
    traefik->>Client: Response
  end

Loading

B) Sending headers with unauthenticated requests (on public routes or forwarded ones).
In this case I would like to attach it to the header config.

Eg.:

Headers:
  - Name: "Authorization"
    Value: "{{`Bearer {{ .accessToken }}`}}"
    IncludeWhen: "Authorized" or "Always"

What do you think?

[bastianjoel]

That would still fit our use case and I like the semantics much better than from my initial proposal. I am planning to add those changes next week.