Authentication Types in Gerrit explained!
Type of user authentication employed by Gerrit. The supported values are:
By default, OpenID
OpenID
The default setting. Gerrit uses any valid OpenID provider chosen by the end-user. For more information see openid.net.
OpenID_SSO
Supports OpenID from a single provider. There is no registration link, and the “Sign In” link sends the user directly to the provider’s SSO entry point.
HTTP
Gerrit relies upon data presented in the HTTP request. This includes HTTP basic authentication, or some types of commercial single-sign-on solutions. With this setting enabled the authentication must take place in the web server or servlet container, and not from within Gerrit.
HTTP_LDAP
Exactly like HTTP (above), but additionally Gerrit pre-populates a user’s full name and email address based on information obtained from the user’s account object in LDAP. The user’s group membership is also pulled from LDAP, making any LDAP groups that a user is a member of available as groups in Gerrit.
CLIENT_SSL_CERT_LDAP
This authentication type is actually kind of SSO. Gerrit will configure Jetty’s SSL channel to request the client’s SSL certificate. For this authentication to work a Gerrit administrator has to import the root certificate of the trust chain used to issue the client’s certificate into the <review-site>/etc/keystore. After the authentication is done Gerrit will obtain basic user registration (name and email) from LDAP, and some group memberships. Therefore, the “_LDAP” suffix in the name of this authentication type. This authentication type can only be used under hosted daemon mode, and the httpd.listenUrl must use https:// as the protocol. Optionally, certificate revocation list file can be used at <review-site>/etc/crl.pem. For details, see httpd.sslCrl.
LDAP
Gerrit prompts the user to enter a username and a password, which it then verifies by performing a simple bind against the configured ldap.server. In this configuration the web server is not involved in the user authentication process.
The actual username used in the LDAP simple bind request is the account’s full DN, which is discovered by first querying the directory using either an anonymous request, or the configured ldap.username identity. Gerrit can also use kerberos if ldap.authentication is set to GSSAPI.
LDAP_BIND
Gerrit prompts the user to enter a username and a password, which it then verifies by performing a simple bind against the configured ldap.server. In this configuration the web server is not involved in the user authentication process.
Unlike LDAP above, the username used to perform the LDAP simple bind request is the exact string supplied in the dialog by the user. The configured ldap.username identity is not used to obtain account information.
OAUTH
OAuth is a protocol that lets external apps request authorization to private details in a user’s account without getting their password. This is preferred over Basic Authentication because tokens can be limited to specific types of data, and can be revoked by users at any time.
Site owners have to register their application before getting started. Note that provider specific plugins must be used with this authentication scheme.
DEVELOPMENT_BECOME_ANY_ACCOUNT
DO NOT USE. Only for use in a development environment.
When this is the configured authentication method a hyperlink titled Become appears in the top right corner of the page, taking the user to a form where they can enter the username of any existing user account, and immediately login as that account, without any authentication taking place. This form of authentication is only useful for the GWT hosted mode shell, where OpenID authentication redirects might be risky to the developer’s host computer, and HTTP authentication is not possible.
Reference
https://dev.vaadin.com/review/Documentation/config-gerrit.html#auth
- Installing Jupyter: Get up and running on your computer - November 2, 2024
- An Introduction of SymOps by SymOps.com - October 30, 2024
- Introduction to System Operations (SymOps) - October 30, 2024