Allow to customize result header name

[skuzzle]

Not all applications I came along support the X-Forwarded-User header. It would be great if the result header name could be configured to also support those applications.
To drive this further, it would be great if the claim name from which the header's value is taken were also be customizable.

[thomseddon]

👍 I agree, it would be trivial to add a config option for this.

For the second point, what provider are you using?

[skuzzle]

I'm using keycloak and it provides multiple identifying attributes in the authentication token. There is a unique id (UUID), the user's mail address, the user name and/or probably configured custom attributes. Depending on the application that is to be secured, any of these values might be of interest

[thmo]

As an example, I am testing letting users log into a Trac installation with their Keycloak account.

Currently, I have to do some hackery like this in the nginx conf:

map $http_x_forwarded_user $mapped_user {
    "~*^(?<user>[^@]+)@(?<domain>.+)$" $user;
}

# ...

location @wsgi {
    # ...
    uwsgi_param REMOTE_USER $mapped_user if_not_empty;
}

which of course only works because the username matches the local part of their email addresses.

#159 is related, isn't it?

[monsdar]

My usecase is integrating rundeck in preauthenticated mode: https://docs.rundeck.com/docs/administration/security/authentication.html#preauthenticated-mode

I found this non-merged PR in one of the many forks of traefik-forward-auth that is related to this feature: mesosphere/traefik-forward-auth#72

[bennesp]

@monsdar I just want to be sure that we are aligned

What @skuzzle is trying to do here is to just change the header name from being X-Forwarded-User to a different one (eg: X-User or X-Auth-User or anything else).

This is already possible with mesosphere's (probably unmaintained now?) fork with the FORWARD_TOKEN_HEADER_NAME variable. See here on the master branch: https://github.com/mesosphere/traefik-forward-auth/blob/057c6d41a7126080c08f011a7fbaa0f12c16d10a/internal/configuration/config.go#L56

Instead, the PR I proposed to mesosphere's fork you mention, is about adding any number of headers to the request taking the values from the authentication claims.

So, we have two paths, according to me:

1. Replicate the mesosphere's fork FORWARD_TOKEN_HEADER_NAME behavior, in this repository. This would just solve this issue but it would not give the same flexibility you can achieve with Send configured claims as headers to backends mesosphere/traefik-forward-auth#72
2. Implement a proper way of assigning claims to headers in this repository, in the same way as the tentative I made in mesosphere's fork. This would of course solve much complex scenarios, but it would require more effort

Given the above, and the fact that the last commit to this repository is 3 years old, if nothing changes, I would highly recommend going with the mesosphere's fork that already has FORWARD_TOKEN_HEADER_NAME

[monsdar]

You are right. The issue is about renaming X-Forwarded-User, not about adding additional headers from claims. The mesosphere branch does not really work outside a K8s cluster though (as far as I remember), therefore this version of traefik-forward-auth still could profit from such a feature.