Allow whitelist to take a username mapping.

[tommie]

Gitea is a service that can use a reverse proxy header for authentication, but doesn't allow at-signs in usernames. The reverse proxy support is part of SSO support, and is tailored to having a single domain for everyone, and the reverse proxy doing the username mapping. For enterprise domains, we could implement stripping or mangling of the domain, but in private installations where friends gather, this isn't compatible with the federating principle of OAuth2.

I'm using it for personal personal repositories, but want to allow others to be able to access it. For small sites, I think having the ability to just do a simple mapping is easier than changing each of the protected services.

I believe this is conceptually compatible with #63, with trivial merging.

[thomseddon]

This is an interesting idea, I'm not against it but I wonder if there is a more generic fix - could you link me to the gitea docs that outline the proxy header based auth (I couldn't see this on the authentication docs page).

[tommie]

There isn't much docs, unfortunately.

• https://docs.gitea.io/en-us/config-cheat-sheet/ lists the headers REVERSE_PROXY_AUTHENTICATION_USER and REVERSE_PROXY_AUTHENTICATION_EMAIL
• https://github.com/go-gitea/gitea/blob/master/modules/auth/sso/reverseproxy.go#L35 is the relevant code. (That file is short.)
• Support Reverse Proxy Email go-gitea/gitea#2347 was the proposal to support getting email separately from username in the RP auth.
• Traefik header transformation traefik/traefik#6047 header transformation FR. In Apache, I could use a header replace to make this mapping, but Traefik doesn't have that.

Full disclosure: I've been contemplating dropping Traefik because it seems very limited for my use-case. Gitea can do OAuth2 on its own, but (1) I like keeping the auth setup simple to avoid mistakes and (2) Traefik doesn't support ignoring forward-auth for only certain routes, AFAICT.

[thomseddon]

I've thought a little more about this and I think this is a bit of a gitea quirk, however I think there is a more generic implementation that would make sense; rather than adding the map to the whitelist, perhaps we could create another config field called user-attribute-map which would take values in a similar way to how you have conceived them here:

user-attribute-map = thom@example.com,X-WEBAUTH-USER:thomusername,X-Auth-Level:admin
```

I think we could parse this into a map on startup and then add the fields after we add the 'X-Forwarded-User' field: https://github.com/thomseddon/traefik-forward-auth/blob/master/internal/server.go#L108

What do you think?

[tommie]

What do you think?

Thanks for thinking about it. More powerful, but more verbose. That works for me. To allow multiple users, each user would use a separate --user-attribute-map, since comma is used to separate attributes now?

• user-attribute-map maybe should be user-header-map to go with HTTP nomenclature.

• I'd use a different separator between "predicate" (thom@example.com) and the "result" so it can be extended. Equal sign? That's used in DKIM, but I don't think it's common in normal addresses. (If it becomes a problem, escaping rules could be added.)

• If supporting arbitrary headers, it might be limiting to use comma as a separator, but escaping rules could be added later.

  user-header-map = thom@example.com=X-WEBAUTH-USER:thomusername,X-Auth-Level:admin
  

[tommie]

Sorry about the 1.5 year delay. My code was running fine, but now I want to use the new rule configuration, and remembered. :)

See the README for the syntax. To support environment variables, I chose comma as the outermost separator.

[tommie]

One open question: It would be useful (in terms of verbosity) to always send X-Forwarded-Email if the X-Forwarded-User.