Proposal: Support for REMOTE_USER Authentication for SSO Integration (e.g., SAML, OAuth, OpenID Connect)

[spetzreborn]

Feature Description

I propose adding native support for using the REMOTE_USER HTTP header as an authentication mechanism in the application. This would enable seamless integration with Single Sign-On (SSO) technologies, such as SAML, Shibboleth, or others, which commonly authenticate users via an external identity provider and pass the user’s identity to the application through the REMOTE_USER header.

Purpose and Benefits

Purpose: The primary goal is to allow the application to easily integrate with external SSO solutions, thereby improving security and simplifying the user authentication process. Many organizations use SSO to centralize authentication across multiple applications, and supporting REMOTE_USER would allow this project to fit into that ecosystem more easily.

Optional Self Service: If the category users is implemented that only can create, modify, list and delete their own configurations wireguard-ui can become a "self service" service. That is because the users get provisioned automatically on login.

Proposed Implementation

1. **Middleware for REMOTE_USER**: Introduce a middleware that can extract the REMOTE_USER header from the incoming request and use it to authenticate or automatically create a user in the application.
   

2. User Creation: If the REMOTE_USER is present and matches an existing user, log the user in. If no matching user exists, create a new user with the information provided by REMOTE_USER.
3. Configuration Options: Allow administrators to enable or disable REMOTE_USER authentication via configuration settings.

Proof of Concept

I have made a crude proof of concept branch from the steps of the proposed Implementation. This is mostly so my organisation can start testing if wireguard-ui is the frontend we want to continue working with.

It has some limitations, as in our case the REMOTE_USER uses a scoped identifier. This identifier looks like:
[email protected] This is not an email, even as it looks like one. At the time of writing this works from the back end perspective, but we can not edit or delete the users from the UI because the validator does not permit email as usernames.

I will make an PR and link in from this issue to have a concrete example to discuss - but as I said, it is a proof of concept and not complete production code.

Related issues I want to discuss if SSO is intresting is:

1. Change the username validator to allow email looking usernames
2. Possibillity for self service - make a new user tier that is "just user" and only can see their own configs.

Regards
Björn

[spetzreborn]

PR #632