Determine desired password-handling behavior for ExternalLoginUsers #392

@strk commented on GitHub (Mar 6, 2017):

Thanks for getting this started @morrildl.
I think a whitelits/blacklist approach is good for self-registration, this can be email (assuming confirmation is always requested for that) or domain/url (for those who are willing to register via OpenID). Not sure what would make a good whitelist/blacklist for OAuth, but in case dynamic-client-registration with OpenID-Connect is implemented the URL whitelist/blacklits could also be re-used there.

Allowing for a user to have no password at all seems an interesting idea to me, and could be implemented as a first step. Doing that would require to redefine how users confirm some critical operations (currently: password change, account deletion) as those are currently requiring to
enter your password again.

That said, I think username/password should be one over several ways to log in, for a user, who should then possibly have multiple ways to authenticate/login. This is already the case with the merged OAuth2 provider in that it has a separate table to list those "external account". And is the case with the OpenID PR, also using a separate table. The difference within the two is what they encode in the "User.LoginSource" field in the "User" table. My "OpenID" branch leaves "User.LoginSource" consistent with "User.LoginName" and "User.Passwd" (so that when logging in via username/password the system knows where to send them [think LDAP or SMTP etc.]), while the "OAuth" mechanism set "User.LoginSource" to the identifier of the OAuth2 source if and only if the user first registered by presenting the OAUth2 credentials. I think this is inconsistent and should be changed.

@strk commented on GitHub (Mar 6, 2017): Thanks for getting this started @morrildl. I think a whitelits/blacklist approach is good for self-registration, this can be email (assuming confirmation is always requested for that) or domain/url (for those who are willing to register via OpenID). Not sure what would make a good whitelist/blacklist for OAuth, but in case dynamic-client-registration with OpenID-Connect is implemented the URL whitelist/blacklits could also be re-used there. Allowing for a user to have *no* password at all seems an interesting idea to me, and could be implemented as a first step. Doing that would require to redefine how users confirm some critical operations (currently: password change, account deletion) as those are currently requiring to enter your password again. That said, I think username/password should be one over several ways to log in, for a user, who should then possibly have multiple ways to authenticate/login. This is already the case with the merged OAuth2 provider in that it has a separate table to list those "external account". And is the case with the OpenID PR, also using a separate table. The difference within the two is what they encode in the "User.LoginSource" field in the "User" table. My "OpenID" branch leaves "User.LoginSource" consistent with "User.LoginName" and "User.Passwd" (so that when logging in via username/password the system knows where to send them [think LDAP or SMTP etc.]), while the "OAuth" mechanism set "User.LoginSource" to the identifier of the OAuth2 source if and only if the user first registered by presenting the OAUth2 credentials. I think this is inconsistent and should be changed.

GiteaMirror commented

@strk commented on GitHub (Mar 6, 2017):

@willemvd your thoughs are welcome on the matter with User.LoginSource

@strk commented on GitHub (Mar 6, 2017): @willemvd your thoughs are welcome on the matter with User.LoginSource

GiteaMirror commented

@morrildl commented on GitHub (Mar 6, 2017):

Re: local password still working for logins -- I definitely recognize people will want this. However my concern here is that I will eventually be running an instance for a business operation, and our password doctrine is that we delegate to an OAuth2 provider, and explicitly don't want our users to have a (working) local password. The reason is that it encourages them to enter weak passwords, or skip using OAuth2 entirely.

IOW, some admins will want to use OAuth2/OpenID as just a way for users to link accounts, or as a convenience feature to pick up profile details; but others will want to use them to avoid local passwords to the extent possible. I feel these are both good use cases, depending in part on whether you're running a public/community or private instance.

@morrildl commented on GitHub (Mar 6, 2017): Re: local password still working for logins -- I definitely recognize people will want this. However my concern here is that I will eventually be running an instance for a business operation, and our password doctrine is that we delegate to an OAuth2 provider, and explicitly don't want our users to have a (working) local password. The reason is that it encourages them to enter weak passwords, or skip using OAuth2 entirely. IOW, some admins will want to use OAuth2/OpenID as just a way for users to link accounts, or as a convenience feature to pick up profile details; but others will want to use them to avoid local passwords to the extent possible. I feel these are both good use cases, depending in part on whether you're running a public/community or private instance.

GiteaMirror commented

@strk commented on GitHub (Mar 6, 2017):

Treating "local" authentication just as another "LoginSource" to be
enabled/disabled could allow implementing your usecase. You'd only
enable an OAuth2 LoginSource and be done with it.

I actually second that approach.

@strk commented on GitHub (Mar 6, 2017): Treating "local" authentication just as another "LoginSource" to be enabled/disabled could allow implementing your usecase. You'd only enable an OAuth2 LoginSource and be done with it. I actually second that approach.

GiteaMirror commented

@peterahl commented on GitHub (Sep 12, 2017):

Hello!

Is there anyone working on this? And if not, are there any suggestions on where to start, if one where to make a pull request?

A lot of the points made here makes sense, especially from an enterprise point of view. We are currently working on an implementation of gitea for hosting in-house projects.

I definitely recognize people will want this. However my concern here is that I will eventually be running an instance for a business operation, and our password doctrine is that we delegate to an OAuth2 provider, and explicitly don't want our users to have a (working) local password. The reason is that it encourages them to enter weak passwords, or skip using OAuth2 entirely.

We are really interested in this feature, as we are trying to federate our users using openid connect. For us, the best thing would be that the users are registered automatically the first time they log in using openid connect.

If we use the profile scope of OIDC, we would get name and email. We could perhaps use the first part of the email as username, since that would be familiar, and unique. This would off course not work with a publicly hosted version, but a great enterprise option.

I tried to present the options neutrally, but as a user/admin, my own preference among them is to suppress passwords during OAuth2 signup, but let the user add an HTTP[S] password after the fact, similar to how you'd add an SSH key

I second this opinion.

Kind regards
Peter

@peterahl commented on GitHub (Sep 12, 2017): Hello! Is there anyone working on this? And if not, are there any suggestions on where to start, if one where to make a pull request? A lot of the points made here makes sense, especially from an enterprise point of view. We are currently working on an implementation of gitea for hosting in-house projects. > I definitely recognize people will want this. However my concern here is that I will eventually be running an instance for a business operation, and our password doctrine is that we delegate to an OAuth2 provider, and explicitly don't want our users to have a (working) local password. The reason is that it encourages them to enter weak passwords, or skip using OAuth2 entirely. We are really interested in this feature, as we are trying to federate our users using openid connect. For us, the best thing would be that the users are registered automatically the first time they log in using openid connect. If we use the profile scope of OIDC, we would get name and email. We could perhaps use the first part of the email as username, since that would be familiar, and unique. This would off course not work with a publicly hosted version, but a great enterprise option. > I tried to present the options neutrally, but as a user/admin, my own preference among them is to suppress passwords during OAuth2 signup, but let the user add an HTTP[S] password after the fact, similar to how you'd add an SSH key I second this opinion. Kind regards Peter

GiteaMirror commented

@lafriks commented on GitHub (Sep 12, 2017):

@peterahl I think currently noone is working on this

@lafriks commented on GitHub (Sep 12, 2017): @peterahl I think currently noone is working on this

GiteaMirror commented

@devmattrick commented on GitHub (Oct 23, 2017):

Hi there, we are also trying to use Gitea for hosting in-house projects. I would be very useful if it was possible to authenticate using only OAuth and not have the need to link to existing/ new accounts, as we have a number of services that would be a pain to manage multiple credentials for. I think the method @morrildl method would work best for us as well:

as a user/admin, my own preference among them is to suppress passwords during OAuth2 signup, but let the user add an HTTP[S] password after the fact, similar to how you'd add an SSH key. (This might
even be worth considering in general -- keep UI login password separate from the git HTTP[S] password, so you can make git passwords revocable.)

I'm not sure what other uses cases people have, but that seems to make the most sense to me.

@devmattrick commented on GitHub (Oct 23, 2017): Hi there, we are also trying to use Gitea for hosting in-house projects. I would be very useful if it was possible to authenticate using only OAuth and not have the need to link to existing/ new accounts, as we have a number of services that would be a pain to manage multiple credentials for. I think the method @morrildl method would work best for us as well: > as a user/admin, my own preference among them is to suppress passwords during OAuth2 signup, but let the user add an HTTP[S] password after the fact, similar to how you'd add an SSH key. (This might even be worth considering in general -- keep UI login password separate from the git HTTP[S] password, so you can make git passwords revocable.) I'm not sure what other uses cases people have, but that seems to make the most sense to me.

GiteaMirror commented

@johanhugg commented on GitHub (Mar 7, 2018):

I am also interested in implementing this (which isn't surprising since both me and @peterahl work for the same company).

However, I am unsure how this would look if I make a solution that fits everyone. Right now I have a proof of concept where if you log in with your provider (for example we use OpenId connect with Keycloak, which is integrating with our Active Directory) a user "profile" is created, and linked with the provider. It is a user that has no password set, the provider is the primary authentication source. This solution works fine for us since the usernames we get from OpenId Connect is compatible with the format that Gitea wants, however different providers have different ways of representing a username, which could (and will) be a problem (this also includes OpenID Connect since the preferred_username can contain special characters and thus incompatible).

@johanhugg commented on GitHub (Mar 7, 2018): I am also interested in implementing this (which isn't surprising since both me and @peterahl work for the same company). However, I am unsure how this would look if I make a solution that fits everyone. Right now I have a proof of concept where if you log in with your provider (for example we use OpenId connect with Keycloak, which is integrating with our Active Directory) a user "profile" is created, and linked with the provider. It is a user that has no password set, the provider is the primary authentication source. This solution works fine for us since the usernames we get from OpenId Connect is compatible with the format that Gitea wants, however different providers have different ways of representing a username, which could (and will) be a problem (this also includes OpenID Connect since the preferred_username can contain special characters and thus incompatible).

GiteaMirror commented

@Thulium-Drake commented on GitHub (Sep 11, 2018):

@johanhugg : Hi Johan,
How did you get Gitea to automatically create useraccounts when the authentication succeeds? I've tried enabling the following options in app.ini, but no cigar..

DISABLE_REGISTRATION              = false
ALLOW_ONLY_EXTERNAL_REGISTRATION  = true
ENABLE_REVERSE_PROXY_AUTHENTICATION = true
ENABLE_REVERSE_PROXY_AUTO_REGISTRATION = true

I basically want my useraccounts to have no (useable) password on their profiles for the same reasons stated earlier (weak passwords, too many passwords etc.).

Did you configure it, or did you need to hack a bit on the code to make it work? In my current setup I'm still asked to fill in a form when signing in via Keycloak with a new useraccount.

Thanks in advance!

@Thulium-Drake commented on GitHub (Sep 11, 2018): @johanhugg : Hi Johan, How did you get Gitea to automatically create useraccounts when the authentication succeeds? I've tried enabling the following options in app.ini, but no cigar.. ``` DISABLE_REGISTRATION = false ALLOW_ONLY_EXTERNAL_REGISTRATION = true ENABLE_REVERSE_PROXY_AUTHENTICATION = true ENABLE_REVERSE_PROXY_AUTO_REGISTRATION = true ``` I basically want my useraccounts to have no (useable) password on their profiles for the same reasons stated earlier (weak passwords, too many passwords etc.). Did you configure it, or did you need to hack a bit on the code to make it work? In my current setup I'm still asked to fill in a form when signing in via Keycloak with a new useraccount. Thanks in advance!

GiteaMirror commented

@moiflo033 commented on GitHub (Feb 4, 2021):

I would welcome the option for users to only be able to authenticate with ssh, as i don't want my users to skip 2FA like morrildl mentioned.

@moiflo033 commented on GitHub (Feb 4, 2021): I would welcome the option for users to only be able to authenticate with ssh, as i don't want my users to skip 2FA like morrildl mentioned.

GiteaMirror commented

@tacerus commented on GitHub (Aug 12, 2021):

Hi,

I would too appreciate if local passwords could be disabled for people who created their Gitea account through an OIDC sign-in - if I could choose whether passwords in Gitea will be completely hidden for those users (hence only allowing authenticated git using SSH), or whether there is a separate option to define passwords for git via HTTP(s), I would probably go for the former, as to not confuse less-tech-savvy users with more password boxes.

@tacerus commented on GitHub (Aug 12, 2021): Hi, I would too appreciate if local passwords could be disabled for people who created their Gitea account through an OIDC sign-in - if I could choose whether passwords in Gitea will be completely hidden for those users (hence only allowing authenticated git using SSH), or whether there is a separate option to define passwords for git via HTTP(s), I would probably go for the former, as to not confuse less-tech-savvy users with more password boxes.

GiteaMirror commented

@Thulium-Drake commented on GitHub (Sep 13, 2021):

I think this was fixed in #6606

@Thulium-Drake commented on GitHub (Sep 13, 2021): I think this was fixed in #6606

GiteaMirror commented

@mewalig commented on GitHub (Oct 5, 2021):

@Thulium-Drake #6606 seems to have been done in 2019, so assuming it is included in the code as of June 2021 which is what we are testing on, AFAIK this issue remains. If that's not the case, could anyone provide guidance as to how to make everything password-related disappear, for accounts that we want to be able to authenticate solely through a 3rd party provider such as Gmail? As of now, when we have such accounts, certain operations still ask for a password (at the least, "Delete account" does)

@mewalig commented on GitHub (Oct 5, 2021): @Thulium-Drake #6606 seems to have been done in 2019, so assuming it is included in the code as of June 2021 which is what we are testing on, AFAIK this issue remains. If that's not the case, could anyone provide guidance as to how to make everything password-related disappear, for accounts that we want to be able to authenticate solely through a 3rd party provider such as Gmail? As of now, when we have such accounts, certain operations still ask for a password (at the least, "Delete account" does)

GiteaMirror commented

@Thulium-Drake commented on GitHub (Oct 5, 2021):

It seems you're right, I looked in my config and I already have those options disabled (REQUIRE_EXTERNAL_REGISTRATION_PASSWORD in this case), but it's still possible for me to create a password.

And ofcourse the delete account thingey also asks for a password (though I'd probably never use it ;-) )

@Thulium-Drake commented on GitHub (Oct 5, 2021): It seems you're right, I looked in my config and I already have those options disabled (REQUIRE_EXTERNAL_REGISTRATION_PASSWORD in this case), but it's still possible for me to create a password. And ofcourse the delete account thingey also asks for a password (though I'd probably never use it ;-) )

GiteaMirror commented

@w112nxs commented on GitHub (Dec 17, 2021):

any idea if this is fixed,.. build a toal new server using the latest docker image and stil; asks for password for google Oauth

@w112nxs commented on GitHub (Dec 17, 2021): any idea if this is fixed,.. build a toal new server using the latest docker image and stil; asks for password for google Oauth

GiteaMirror commented

@kousu commented on GitHub (Dec 8, 2022):

How did you get Gitea to automatically create useraccounts when the authentication succeeds? I've tried enabling the following options in app.ini, but no cigar..
DISABLE_REGISTRATION              = false
ALLOW_ONLY_EXTERNAL_REGISTRATION  = true
ENABLE_REVERSE_PROXY_AUTHENTICATION = true
ENABLE_REVERSE_PROXY_AUTO_REGISTRATION = true
I basically want my useraccounts to have no (useable) password on their profiles for the same reasons stated earlier (weak passwords, too many passwords etc.).

It's 4 years later and I have this implemented with gitea 1.17.1:

[service]
DISABLE_REGISTRATION = false
ALLOW_ONLY_EXTERNAL_REGISTRATION = true
ENABLE_CAPTCHA = false
DEFAULT_KEEP_EMAIL_PRIVATE = true
SHOW_REGISTRATION_BUTTON = false

[openid]
ENABLE_OPENID_SIGNIN = false
ENABLE_OPENID_SIGNUP = false

[oauth2_client]
ENABLE_AUTO_REGISTRATION = true
OPENID_CONNECT_SCOPES = email,profile
USERNAME = email
UPDATE_AVATAR = true

I've tested this against GitHub, Slack, and Google OAuth providers. They all behave: the user clicks "Sign in with [service]", they are bounced over to their GitHub/Slack/Google login page and asked "Do you authorize Gitea?", and then bounced right back, logged in with a new account.

Did you ever figure this out @Thulium-Drake?

@kousu commented on GitHub (Dec 8, 2022): > How did you get Gitea to automatically create useraccounts when the authentication succeeds? I've tried enabling the following options in app.ini, but no cigar.. > > ``` > DISABLE_REGISTRATION = false > ALLOW_ONLY_EXTERNAL_REGISTRATION = true > ENABLE_REVERSE_PROXY_AUTHENTICATION = true > ENABLE_REVERSE_PROXY_AUTO_REGISTRATION = true > ``` > > I basically want my useraccounts to have no (useable) password on their profiles for the same reasons stated earlier (weak passwords, too many passwords etc.). It's 4 years later and I have this implemented with gitea 1.17.1: ``` [service] DISABLE_REGISTRATION = false ALLOW_ONLY_EXTERNAL_REGISTRATION = true ENABLE_CAPTCHA = false DEFAULT_KEEP_EMAIL_PRIVATE = true SHOW_REGISTRATION_BUTTON = false [openid] ENABLE_OPENID_SIGNIN = false ENABLE_OPENID_SIGNUP = false [oauth2_client] ENABLE_AUTO_REGISTRATION = true OPENID_CONNECT_SCOPES = email,profile USERNAME = email UPDATE_AVATAR = true ``` I've tested this against GitHub, Slack, and Google OAuth providers. They all behave: the user clicks "Sign in with [service]", they are bounced over to their GitHub/Slack/Google login page and asked "Do you authorize Gitea?", and then bounced right back, logged in with a new account. Did you ever figure this out @Thulium-Drake?

GiteaMirror commented