go-gitea / gitea

Git with a cup of tea! Painless self-hosted all-in-one software development service, including Git hosting, code review, team collaboration, package registry and CI/CD
https://gitea.com
MIT License
43.39k stars 5.33k forks source link

Allow to disable local login #13606

Open n0emis opened 3 years ago

n0emis commented 3 years ago

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 commented 2 years ago

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

jolheiser commented 2 years ago

+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.

darkguy2008 commented 2 years ago

+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 commented 2 years ago

@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 (https://github.com/go-gitea/gitea/pull/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 commented 2 years ago

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

ranomier commented 2 years ago

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 commented 1 year ago

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 commented 1 year ago

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

dodedodo commented 1 year ago

@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 commented 1 year ago

@dodedodo oh wow. Thanks for linking that <3

mrmelon54 commented 1 year ago

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

mcrapts commented 1 year ago

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 commented 1 year ago

For anyone using NGINX as a proxy, use this:

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

Or at server level of course.

grachevko commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 11 months ago

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 commented 8 months ago

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 commented 5 months ago

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 commented 1 month ago

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 commented 2 weeks ago

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: CleanShot 2024-07-06 at 10 38 07@2x

 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 commented 2 weeks ago
 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 commented 2 weeks ago

Closed by https://github.com/go-gitea/gitea/pull/31535

kdumontnu commented 2 weeks ago

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.