Allow Login with External Authentication

[Queuecumber]

This PR adds support for external authenticating proxies which set the X-Auth-Request-Email header.

This is useful for self-hosted instances which are part of a larger single-sign-on system. Since simplelogin doesn't support SSO (in general), this allows a generic proxy like oauth2-proxy to handle the authentication and communicate the user information via a header. This also alleviates some of the stated reasons for removing the various SSO providers from SL: Google (for example) will only see the generic proxy which may handle many different sites and will have no knowledge of the underlying SL instance; SL will not have to maintain separate oauth code for every provider since that is outsourced to the proxy.

• Administrators can deploy SL with the PROXY_ALLOW_LOGIN option to support this. This option is disabled by default and should only be enabled if there is a suitable proxy handling requests. User's will then authenticate to the proxy using whatever SSO their organization supports and will be directed to the dashboard.

• If registration is disabled and the proxy-passed email does not exist in the SL database, users will be redirected to the login page with an error. Normal password logins are still completely supported even with the proxy (although it would be somewhat awkward to use).

• If administrators have not disabled registration (DISABLE_REGISTRATION) then users which do not exist in the SL database will instead be redirected to the registration page with their email pre-filled in the sign-up for where they can enter a password which would be used for sudo mode.

• Administrators may also add the PROXY_AUTO_PASSWORD configuration in which case users which do not exist in the SL database are automatically created with their password set to None. The sudo code has been modified to support this case by not asking the user to re-enter their password if they were provisioned with a None password. This option should be used with care but reflects that the authenticating proxy is the ultimate and only source of trust in such a system: SL in this case should not be making decisions about who can do what on its own.

The following video demonstrates this flow (including the lack of a sudo check)

https://user-images.githubusercontent.com/5865387/201968156-366e96c3-cd61-4946-bc15-50592459d7da.mp4

[Queuecumber]

Couple of additional notes

1. You may want automated tests for this; I took a look over the testing code and it was quite sparse so I opted to ask about it after making the PR
2. The current way that config options are checked is kind of concerning: DISABLE_RATE_LIMIT = "DISABLE_RATE_LIMIT" in os.environ for example. It should really check for a truthy value because DISABLE_RATE_LIMIT=false wont work and that's confusing, I assume you are aware
3. There are quite a number of outstanding PRs waiting to be merged, I would like to move this along in a reasonable time frame so please let me know what I can do to make the process smoother

[Queuecumber]

This PR is a followup from my unanswered discussion at https://github.com/simple-login/app/discussions/1386

[nguyenkims]

@Queuecumber thanks for making the PR. This flow is quite specific and to keep SL code as minimal as possible, unfortunately we can't include it in the official version.

One solution is to fork our repo and keep the PR there. This fork can then sync with the upstream from time to time to have all updates. You can then build a docker image from the fork and use it on your server. SL uses AGPL license so there shouldn't be any issue license-wise. What do you think?

[Queuecumber]

I think it's fine in the short term, I think you should merge it in the long term

This isn't as specific a flow as you might think it is, and there are two main scenarios that it supports

1. Personal-use self hosting where a small number of users don't want to juggle separate logins for separate locally hosted sites
2. Larger enterprise style (read: might be willing to pay you) deployments which may have a single-sign-on requirement (LDAP, Google workspaces, etc); since SL has committed to not supporting external authentications (that aren't proton) this is an easy, secure, and simple way to outsource that logic. Many apps don't support SSO and the ability to configure an authenticating proxy is a fairly standard solution.

Looking over the changelog, I think these changes are quite minimal (~50 lines; not a huge technical burden there) considering the scope of the feature it adds (ability to log in however you want including ways your business may require of any deployed internal site), so it seems to me that it fits quite nicely with the goal of keeping SL simple.

By all means though, let's leave it open and solicit other opinions

[acasajus]

Hello @Queuecumber . It's not the loc that counts, it's the fact that's making the auth flow and account management even more complex than it currently is. As it's right now we do have several flows that we need to maintain and think about when we do any change. So to keep it as simple as possible we'd like to minimize those.

[Queuecumber]

What are the flows you're currently supporting?

[Bergruebe]

It would be really great if this PR could be merged!

In my use case I have a self hosted MailCow for my family and it would be perfect if my family members could login into the self hosted simple login over the MailCow-OIDC or OAuth, so they do not need to understand the difference between the two systems.

[muhlba91]

same story here - i'd like to integrate oauth/oidc login through an already used provider for my family.

@acasajus / @nguyenkims any plans to support oauth/oidc logins in the future?

[nguyenkims]

@muhlba91 there's actually some supports for OIDC logins in SL as you can see in https://github.com/simple-login/app/blob/e91fd26964ea95a3b6d37106373b2bca6106d3ce/app/auth/views/github.py#L1-L0

These login options used to be offered in the past but as they aren't open source and don't have a good privacy policy, we decided to not show them.

You can use them to add a generic OpenID/OAuth2 authentication provider and create a PR to this repo.

[muhlba91]

@nguyenkims finally i had some time for this. i opened a PR (https://github.com/simple-login/app/pull/2046) adding generic OIDC auth to be configured by a few environment variables. i'd love you could review it and we can get it into the codebase. 😃

[Queuecumber]

Closed in favor of #2046