Add Authentication Source for Reverse Proxy Authentication #6505

Open
opened 2025-11-02 06:58:03 -06:00 by GiteaMirror · 0 comments
Owner

Originally created by @heisz on GitHub (Dec 11, 2020).

This is new feature extension/idea, not an issue, so I didn't include my current environment (apologies if inappropriate, I'm new here). Raising the idea for discussion, volunteering to be the implementer and contribute to gitea (really liking this platform after trying several other git management solutions that came up short).

In our environment, I've set up Gitea behind an authenticating reverse proxy that provides the user 'token' using the existing supported ENABLE_REVERSE_PROXY_AUTHENTICATION and REVERSE_PROXY_AUTHENTICATION_USER configuration options. Our users do not have any password available for login.

There are a few areas in the UI (like change my password) that refer to the user password, which are disabled if the LoginType of the user is not Plain or OAuth2. What I'm proposing is to add another LoginType of 'Reverse Proxy', for which the administrator can define an Authentication Source (no other options, although there might be some other ideas around that) and associate it to the users (in my case all of them) that are only accessible through the external proxy so that these password options never appear. This option would only appear if the ENABLE flag is true. If the flag was changed to false with already existing login sources defined, those sources could either be automatically disabled (TBD) or at least the UI could indicate that that data login source should not be used (show a warning in the bottom).

I'm open for ideas and discussion around this use case. Some other thoughts I've had that might be related:

  • adding a general configuration option like REVERSE_PROXY_AUTHENTICATION_ONLY to turn off the login page in general for instances where users get through the proxy but the AUTHENTICATION_USER is not matched
  • some form of configuration option to allow for an additional feature to support an external id in the user table to match the proxy authentication data against. Depending on the origin (e.g. Azure SSO) the entity identifier is not the same as a username, might be handy to have an internal mapping instead of handling the mapping in the reverse proxy. This might be a separate idea/issue.
Originally created by @heisz on GitHub (Dec 11, 2020). This is new feature extension/idea, not an issue, so I didn't include my current environment (apologies if inappropriate, I'm new here). Raising the idea for discussion, volunteering to be the implementer and contribute to gitea (really liking this platform after trying several other git management solutions that came up short). In our environment, I've set up Gitea behind an authenticating reverse proxy that provides the user 'token' using the existing supported ENABLE_REVERSE_PROXY_AUTHENTICATION and REVERSE_PROXY_AUTHENTICATION_USER configuration options. Our users do *not* have any password available for login. There are a few areas in the UI (like change my password) that refer to the user password, which are disabled if the LoginType of the user is not Plain or OAuth2. What I'm proposing is to add another LoginType of 'Reverse Proxy', for which the administrator can define an Authentication Source (no other options, although there might be some other ideas around that) and associate it to the users (in my case all of them) that are only accessible through the external proxy so that these password options never appear. This option would only appear if the ENABLE flag is true. If the flag was changed to false with already existing login sources defined, those sources could either be automatically disabled (TBD) or at least the UI could indicate that that data login source should not be used (show a warning in the bottom). I'm open for ideas and discussion around this use case. Some other thoughts I've had that might be related: - adding a general configuration option like REVERSE_PROXY_AUTHENTICATION_ONLY to turn off the login page in general for instances where users get through the proxy but the AUTHENTICATION_USER is not matched - some form of configuration option to allow for an additional feature to support an external id in the user table to match the proxy authentication data against. Depending on the origin (e.g. Azure SSO) the entity identifier is not the same as a username, might be handy to have an internal mapping instead of handling the mapping in the reverse proxy. This might be a separate idea/issue.
GiteaMirror added the type/featuretopic/authentication labels 2025-11-02 06:58:03 -06:00
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#6505