Allow to disable local login

[n0emis]

• Gitea version (or commit ref): 1.12.6
• Git version: N/A
• Operating system: N/A
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL)
  • No
  • Not relevant
• Log gist: N/A

Description

When using gitea in an environent (e.g. corporate deployment) when SSO login is required, it would be nice to have a way to disable local login, to not have a confusing login-page, which can't be used.

A nice extra would be that, when only one authentication-source is configured, clicking on the "Sign in" button on the header automatically redirects to the IdP/SSO.

[darkguy2008]

+1. 1 year and still no response from the Gitea team. For how long we'll be waiting? This request is pretty valid.

[jolheiser]

+1. 1 year and still no response from the Gitea team. For how long we'll be waiting? This request is pretty valid.

Unfortunately none of us are paid to work on Gitea, we are all volunteers.
You are more than welcome to send in a PR for us to review. 🙂

Alternatively, putting a bounty on an issue has worked to get things done more quickly in the past.

[darkguy2008]

+1. 1 year and still no response from the Gitea team. For how long we'll be waiting? This request is pretty valid.

Unfortunately none of us are paid to work on Gitea, we are all volunteers. You are more than welcome to send in a PR for us to review. slightly_smiling_face

Alternatively, putting a bounty on an issue has worked to get things done more quickly in the past.

Oh, fair enough. I'll try to give it a shot, I'm starting to move from GitLab and I'm in the process of securing everything first.

I think a bounty could be useful for this too, it's a good idea to disable local logins once you've set up another authentication mechanism. If something fails you still have gitea admin just in case :)

[wxiaoguang]

@darkguy2008 we are facing the same problem I think. Just share some background here:

The login module of Gitea is quite complex, and it is more complex now because more options are introduced like skip local 2fa.

I just proposed a PR about Enforce 2FA (#16880) but it seems difficult to be merged into main branch, so I just use my patch for my private server.

To resolve the login problems fundamentally, I think we should make a global plan and design first, otherwise many features may conflict or may bring security risks.

Maybe we also need a leader for login related features. 😊

[mrmelon54]

This sounds very useful maybe I'll work on it in the near future?

[ranomier]

Maybe just add a option to hide it and put it on a different URL.

So its still available but most users wont see it.

[dodedodo]

In the meantime, you could use an http redirect from /user/login* to gitea's sso login url. In my case (traefik, authentik and gitea) the redirect rule looks like this:

…
labels: 
     …
      - "traefik.http.routers.gitea.middlewares=gitea-login-redirect"
      - "traefik.http.middlewaresgitea-login-redirect.redirectregex.regex=^https://gitea.redacted.tld/user/login*"
      - "traefik.http.middlewares.gitea-login-redirect.redirectregex.replacement=https://gitea.redacted.tld/user/oauth2/Authentik-oid"
…

/Authentik-oid is the name i've assigned to gitea's authentication provider.

I imagine this would work for other webservers and reverse proxies as well.

[techknowlogick]

@dodedodo For authentik are you using the oidc connector for gitea logins ?

[dodedodo]

@dodedodo For authentik are you using the oidc connector for gitea logins ?

@techknowlogick Yes I am. There's a very detailed guide in the authentik documentation.

[techknowlogick]

@dodedodo oh wow. Thanks for linking that <3

[mrmelon54]

Really surprised I didn't think of using a redirect on my reverse proxy. Thanks 👍

[mcrapts]

In the meantime, you could use an http redirect from /user/login* to gitea's sso login url. In my case (traefik, authentik and gitea) the redirect rule looks like this:

…
labels: 
     …
      - "traefik.http.routers.gitea.middlewares=gitea-login-redirect"
      - "traefik.http.middlewaresgitea-login-redirect.redirectregex.regex=^https://gitea.redacted.tld/user/login*"
      - "traefik.http.middlewares.gitea-login-redirect.redirectregex.replacement=https://gitea.redacted.tld/user/oauth2/Authentik-oid"
…

/Authentik-oid is the name i've assigned to gitea's authentication provider.

I imagine this would work for other webservers and reverse proxies as well.

Thank you, this works. For anyone using Caddy, I did it like this:

gitea.domain.tld {
  rewrite /user/login /user/oauth2/authelia
  reverse_proxy <host>:<port>
}

Authelia is the name of the authentication provider I configured in Gitea, change it accordingly.

[nrdev88]

For anyone using NGINX as a proxy, use this:

	location / {
		...
		rewrite ^/user/login.*$ /user/oauth2/configname last;
		...
	}

Or at server level of course.

[grachevko]

For anyone using NGINX as a proxy, use this:

	location / {
		...
		rewrite ^/user/login.*$ /user/oauth2/configname last;
		...
	}

Or at server level of course.

Sign Out -> Homepage -> Login -> Again Logged In )

[nrdev88]

For anyone using NGINX as a proxy, use this:

	location / {
		...
		rewrite ^/user/login.*$ /user/oauth2/configname last;
		...
	}

Or at server level of course.

Sign Out -> Homepage -> Login -> Again Logged In )

What's your point? Be clear please.

[grachevko]

For anyone using NGINX as a proxy, use this:

	location / {
		...
		rewrite ^/user/login.*$ /user/oauth2/configname last;
		...
	}

Or at server level of course.

Sign Out -> Homepage -> Login -> Again Logged In )

What's your point? Be clear please.

Can't sign out, instant redirect by chain above

[lukaslangrock]

If you mean that, when you manually click on login, you are automatically logged in without needing to do anything, then that's normal. You are still logged in with your oauth2 provider and thus, when you go to the login page and are getting redirected to /user/oauth2/<configname>, gitea will send you off to the corresponding oauth2 provider, who will then (most likely) authenticate you without requiring interaction, since you are logged in there and have previously authenticated to gitea before.

So by the process of logging out of gitea and then clicking login, you will most likely, unless your auth provider is set up to always ask you for permission, be logged in without needing to do anything.

If you wish that logging out of gitea will require entering a password etc. to log back in, you need to log out of your oauth2 provider too. oauth2 can do this automatically, but it seems like gitea does not fully support that yet. See #14270.

I am still a noob when it comes to oauth2 and that whole realm, so I might be totally wrong here. The way I described it is the way it works on my server.

[tuxmainy]

In the meantime, you could use an http redirect from /user/login* to gitea's sso login url. In my case (traefik, authentik and gitea) the redirect rule looks like this:

…
labels: 
     …
      - "traefik.http.routers.gitea.middlewares=gitea-login-redirect"
      - "traefik.http.middlewaresgitea-login-redirect.redirectregex.regex=^https://gitea.redacted.tld/user/login*"
      - "traefik.http.middlewares.gitea-login-redirect.redirectregex.replacement=https://gitea.redacted.tld/user/oauth2/Authentik-oid"
…

/Authentik-oid is the name i've assigned to gitea's authentication provider.

I imagine this would work for other webservers and reverse proxies as well.

Works like a charm. Might not be an option if you use multiple OAuth2/OpenID providers.

[rodude123]

For anyone using NGINX as a proxy, use this:

	location / {
		...
		rewrite ^/user/login.*$ /user/oauth2/configname last;
		...
	}

Or at server level of course.

How would you do this for apache2, can't seem to figure it out
I've got is this

RewriteEngine On
RewriteRule ^/user/login.*$ /user/oauth2/configname [L]

[pat-s]

Here's a resource definition for k8s

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    ingressClassName: nginx
    nginx.ingress.kubernetes.io/rewrite-target: /user/oauth2/<your oauth2 provider name>/$2
    nginx.ingress.kubernetes.io/use-regex: "true"
  name: rewrite
  namespace: gitea
spec:
  rules:
    - host: <gitea url>
      http:
        paths:
          - backend:
              service:
                name: gitea-http
                port:
                  number: 3000
            path: /user/login.*$
            pathType: Prefix

  tls:
    - hosts:
        - <gitea url>
      secretName: <gitea url>-tls

[joestump]

For anyone using Nginx Proxy Manager you can add the following in the Advanced tab of your Proxy Host:

location ~ ^/user/login.*$ {
  return 301 /user/oauth2/configname;
}

[zc-devs]

Gitea 1.21.5, Keycloak 23.0.7, Traefik 2.10.5, Kubernetes.
Gitea is configured with Authentication Source:

Authentication Type: OAuth2
Authentication Name: keycloak

apiVersion: traefik.io/v1alpha1
kind: IngressRoute
metadata:
  name: gitea
spec:
  routes:
    - kind: Rule
      match: Host(`gitea.example.org`)
      services:
        - name: gitea
          port: http
    - kind: Rule
      match: Host(`gitea.example.org`) && Path(`/user/login`)
      middlewares:
        - name: gitea-login-replace
      services:
        - name: gitea
          port: http

apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
  name: gitea-login-replace
spec:
  replacePath:
    path: /user/oauth2/keycloak

[codejanovic]

In the meantime, you could use an http redirect from /user/login* to gitea's sso login url. In my case (traefik, authentik and gitea) the redirect rule looks like this:

…
labels: 
     …
      - "traefik.http.routers.gitea.middlewares=gitea-login-redirect"
      - "traefik.http.middlewaresgitea-login-redirect.redirectregex.regex=^https://gitea.redacted.tld/user/login*"
      - "traefik.http.middlewares.gitea-login-redirect.redirectregex.replacement=https://gitea.redacted.tld/user/oauth2/Authentik-oid"
…

/Authentik-oid is the name i've assigned to gitea's authentication provider.
I imagine this would work for other webservers and reverse proxies as well.

Works like a charm. Might not be an option if you use multiple OAuth2/OpenID providers.

@tuxmainy Theres a tiny typo in your second label, the dot is missing. Got confused because it did not work properly in my project

[flotpg]

Hi and thanks for all your suggestions.
I opened #31573 and try to use your @nrdev88 solution with nginx but I get a 500 when clicking on sing-in button in the upper right corner:

 location / {
        proxy_pass http://localhost:3000;
        proxy_headers_hash_max_size 1024;
        proxy_headers_hash_bucket_size 128;
        proxy_set_header X-Forwarded-Host gitea.az.ontpg.com;
        proxy_set_header X-Forwarded-Proto https;
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload";
        client_max_body_size 0;
        rewrite ^/user/login*$ /user/oauth2/TPG%20Account last;
        }
}

Any idea?
Much appreciated :)
Thanks and best regards, Flo.

[flotpg]

 location / {
        proxy_pass http://localhost:3000;
        proxy_headers_hash_max_size 1024;
        proxy_headers_hash_bucket_size 128;
        proxy_set_header X-Forwarded-Host gitea.az.ontpg.com;
        proxy_set_header X-Forwarded-Proto https;
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload";
        client_max_body_size 0;
        rewrite ^/user/login*$ /user/oauth2/TPG%20Account last;
        }
}

Any idea? Much appreciated :) Thanks and best regards, Flo.

Looks like it works with redirect instead of last (don't know what last does).
rewrite ^/user/login*$ /user/oauth2/TPG%20Account redirect;

Regards, Flo.

[kdumontnu]

Closed by #31535

[kdumontnu]

I was mistaken - this isn't fully closed, but there should now be enough supporting code that implementing this would not be too difficult if someone wants to take this on.

[AleXoundOS]

but I get a 500 when clicking on sing-in button in the upper right corner

@flotpg, I faced the same issue with rewrite ^/user/login.*$ /user/oauth2/configname last; literally (notice obviously incorrect configname). But once I changed the line to rewrite ^/user/login.*$ /user/oauth2/OAUTH last; it began to work as intended. In my case OAUTH is the name used in gitea admin auth add-oauth --name OAUTH... So, maybe your login provider name was incorrect.