Restrict HTTP Password Generation

[Nandha Kumar Nagarajan]

Hi Team,

Recently, we migrated our Gerrit from LDAP to SSO based authentication. Post the change, each and every user have an option to generate their own HTTP Password from UI --> Settings

We would like to kind of restrict that for everyone by default. Say for example, if a user want have an HTTP password, as an administrator we need to allow that like adding him to some group or whitelisting the user somehow.

Is that possible?

Thanks

Nandhakumar N

[Nasser Grainawi]

On Sep 29, 2021, at 9:33 AM, Nandha Kumar Nagarajan <nandh...@gmail.com> wrote:

Hi Team,

Recently, we migrated our Gerrit from LDAP to SSO based authentication. Post the change, each and every user have an option to generate their own HTTP Password from UI --> Settings

Does that mean you use auth.type=HTTP?

We would like to kind of restrict that for everyone by default. Say for example, if a user want have an HTTP password, as an administrator we need to allow that like adding him to some group or whitelisting the user somehow.

Can you explain the use case for this a bit more? Why don’t you want users to have HTTP passwords?

Is that possible?

https://gerrit-review.googlesource.com/Documentation/config-gerrit.html#auth.gitBasicAuthPolicy controls what passwords are valid for HTTP auth, but doesn’t control generating HTTP passwords.

Thanks

Nandhakumar N

--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/repo-discuss/7c75f176-c593-4231-bf12-b5366e3a4b7dn%40googlegroups.com.

[Nandha Kumar Nagarajan]

Hi

Does that mean you use auth.type=HTTP?

      - Yes

Can you explain the use case for this a bit more? Why don’t you want users to have HTTP passwords?

    - As we know, these HTTP passwords are stored locally in Gerrit and not controlled by LDAP/SSO and also for each user when they login to Gerrit a local account is automatically created. 

So if a user leaves the team/organization, his reference local account will still be present inside Gerrit along with his HTTP password. So, the user can still able to access Gerrit using this credential even though he is not in the organization and that's a Security issue right.

This is the main reason we are trying to restrict HTTP password generation

Thanks

[Nasser Grainawi]

On Sep 29, 2021, at 10:43 AM, Nandha Kumar Nagarajan <nandh...@gmail.com> wrote:

Please don’t top-post, it makes it hard to follow the thread.

Hi

Does that mean you use auth.type=HTTP?

      - Yes

Can you explain the use case for this a bit more? Why don’t you want users to have HTTP passwords?

    - As we know, these HTTP passwords are stored locally in Gerrit and not controlled by LDAP/SSO and also for each user when they login to Gerrit a local account is automatically created. 

So if a user leaves the team/organization, his reference local account will still be present inside Gerrit along with his HTTP password. So, the user can still able to access Gerrit using this credential even though he is not in the organization and that's a Security issue right.

If the account inactive flag is being managed correctly when users leave, then they will not be able to use their account. If you’re not using LDAP, you’ll probably need to manage that flag on your own using the REST API [1] or SSH API [2]. Correctly flagging accounts as active/inactive will also help other aspects of Gerrit workflows, such as selecting appropriate reviewers for changes.

[1] https://gerrit-review.googlesource.com/Documentation/rest-api-accounts.html#delete-active

[2] https://gerrit-review.googlesource.com/Documentation/cmd-set-account.html

To view this discussion on the web visit https://groups.google.com/d/msgid/repo-discuss/bc6382c4-3ad1-4d3c-bbf9-fb0fb8f7c8e6n%40googlegroups.com.

[Luca Milanesio]

On 29 Sep 2021, at 17:49, Nasser Grainawi <nas...@codeaurora.org> wrote:

On Sep 29, 2021, at 10:43 AM, Nandha Kumar Nagarajan <nandh...@gmail.com> wrote:

Please don’t top-post, it makes it hard to follow the thread.

Hi

Does that mean you use auth.type=HTTP?

      - Yes

Can you explain the use case for this a bit more? Why don’t you want users to have HTTP passwords?

    - As we know, these HTTP passwords are stored locally in Gerrit and not controlled by LDAP/SSO and also for each user when they login to Gerrit a local account is automatically created. 

So if a user leaves the team/organization, his reference local account will still be present inside Gerrit along with his HTTP password. So, the user can still able to access Gerrit using this credential even though he is not in the organization and that's a Security issue right.

If the account inactive flag is being managed correctly when users leave, then they will not be able to use their account. If you’re not using LDAP, you’ll probably need to manage that flag on your own using the REST API [1] or SSH API [2]. Correctly flagging accounts as active/inactive will also help other aspects of Gerrit workflows, such as selecting appropriate reviewers for changes.

Also, Gerrit can automatically set the inactive flag based on the LDAP account status, see [3].

In my experience, HTTP passwords are very useful because you do not trigger an LDAP authentication for *every single Git/HTTPS* call, which could literally hammer and cause issues to your LDAP server.

HTH

Luca.

[3] https://gerrit-documentation.storage.googleapis.com/Documentation/3.4.1/config-gerrit.html#auth.autoUpdateAccountActiveStatus

To view this discussion on the web visit https://groups.google.com/d/msgid/repo-discuss/F744AF0E-0A49-483D-AA0F-808027BBC79C%40codeaurora.org.

[Lord Raheem]

I am also in need of a feature like this.

Currently, we have more than 2000+ users on gerrit, and it is another matter to find which user has left the organization or not, and then deactivate them.