| Gerrit Code Review - Single Sign-On Security |
| ============================================ |
| |
| Gerrit supports integration with some types of single sign-on |
| security solutions, making it possible for end-users to setup |
| and manage accounts, without administrator involvement. |
| |
| OpenID |
| ------ |
| |
| By default a new Gerrit installation relies upon OpenID to perform |
| user authentication services. To enable OpenID, the auth.type |
| setting should be `OpenID`: |
| |
| ==== |
| git config --file $site_path/etc/gerrit.config auth.type OpenID |
| ==== |
| |
| As this is the default setting there is nothing required from the |
| site administrator to make use of the OpenID authentication services. |
| |
| * http://openid.net/[openid.net] |
| |
| If Jetty is being used, you may need to increase the header |
| buffer size parameter, due to very long header lines. |
| Add the following to `$JETTY_HOME/etc/jetty.xml` under |
| `org.mortbay.jetty.nio.SelectChannelConnector`: |
| |
| ==== |
| <Set name="headerBufferSize">16384</Set> |
| ==== |
| |
| In order to use permissions beyond those granted to the |
| `Anonymous Users` and `Registered Users` groups, an account |
| must only have OpenIDs which match at least one pattern from the |
| `auth.trustedOpenID` list in `gerrit.config`. Patterns may be |
| either a |
| link:http://download.oracle.com/javase/6/docs/api/java/util/regex/Pattern.html[standard |
| Java regular expression (java.util.regex)] (must start with `^` |
| and end with `$`) or be a simple prefix (any other string). |
| |
| Out of the box Gerrit is configured to trust two patterns, which |
| will match any OpenID provider on the Internet: |
| |
| * `http://` -- trust all OpenID providers using the HTTP protocol |
| * `https://` -- trust all OpenID providers using the HTTPS protocol |
| |
| To trust only Google Accounts: |
| ==== |
| git config --file $site_path/etc/gerrit.config auth.trustedOpenID 'https://www.google.com/accounts/o8/id?id=' |
| ==== |
| |
| Database Schema |
| ~~~~~~~~~~~~~~~ |
| |
| User identities obtained from OpenID providers are stored into the |
| `account_external_ids` table. Users may link more than one OpenID |
| identity to the same Gerrit account (use Settings, Web Identities |
| to manage this linking), making it easier for their browser to sign |
| in to Gerrit if they are frequently switching between different |
| unique OpenID accounts. |
| |
| |
| HTTP Basic/Digest Authentication |
| -------------------------------- |
| |
| When using HTTP authentication, Gerrit assumes that the servlet |
| container or the frontend web server has performed all user |
| authentication prior to handing the request off to Gerrit. |
| |
| As a result of this assumption, Gerrit can assume that any and |
| all requests have already been authenticated. The "Sign In" and |
| "Sign Out" links are therefore not displayed in the web UI. |
| |
| To enable this form of authentication: |
| |
| ==== |
| git config --file $site_path/etc/gerrit.config auth.type HTTP |
| git config --file $site_path/etc/gerrit.config --unset auth.httpHeader |
| git config --file $site_path/etc/gerrit.config auth.emailFormat '{0}@example.com' |
| ==== |
| |
| The auth.type must always be HTTP, indicating the user identity |
| will be obtained from the HTTP authorization data. |
| |
| The auth.httpHeader must always be unset. If set to any value |
| (including `Authorization`) then Gerrit won't correctly honor the |
| standard `Authorization` HTTP header. |
| |
| The auth.emailFormat field ('optional') sets the preferred email |
| address during first login. Gerrit will replace `{0}` with the |
| username, as obtained from the Authorization header. A format such |
| as shown in the example would be typical, to add the domain name |
| of the organization. |
| |
| If Apache HTTPd is being used as the primary web server and the |
| Apache server will be handling user authentication, a configuration |
| such as the following is recommended to ensure Apache performs the |
| authentication at the proper time: |
| |
| ==== |
| <Location "/login/"> |
| AuthType Basic |
| AuthName "Gerrit Code Review" |
| Require valid-user |
| ... |
| </Location> |
| ==== |
| |
| Database Schema |
| ~~~~~~~~~~~~~~~ |
| |
| User identities are stored in the `account_external_ids` table. |
| The user string obtained from the authorization header has the prefix |
| "gerrit:" and is stored in the `external_id` field. For example, |
| if a username was "foo" then the external_id field would be populated |
| with "gerrit:foo". |
| |
| |
| Computer Associates Siteminder |
| ------------------------------ |
| |
| Siteminder is a commercial single sign on solution marketed by |
| Computer Associates. It is very common in larger enterprise |
| environments. |
| |
| When using Siteminder, Gerrit assumes it has been installed in a |
| servlet container which is running behind an Apache web server, |
| and that the Siteminder authentication module has been configured |
| within Apache to protect the entire Gerrit application. In this |
| configuration all users must authenticate with Siteminder before |
| they can access any resource on Gerrit. |
| |
| As a result of this assumption, Gerrit can assume that any and |
| all requests have already been authenticated. The "Sign In" and |
| "Sign Out" links are therefore not displayed in the web UI. |
| |
| To enable this form of authentication: |
| |
| ==== |
| git config --file $site_path/etc/gerrit.config auth.type HTTP |
| git config --file $site_path/etc/gerrit.config auth.httpHeader SM_USER |
| git config --file $site_path/etc/gerrit.config auth.emailFormat '{0}@example.com' |
| ==== |
| |
| The auth.type must always be HTTP, indicating the user identity |
| will be obtained from the HTTP authorization data. |
| |
| The auth.httpHeader indicates in which HTTP header field the Siteminder |
| product has stored the username. Usually this is "SM_USER", but |
| may differ in your environment. Please refer to your organization's |
| single sign-on or security group to ensure the setting is correct. |
| |
| The auth.emailFormat field ('optional') sets the user's preferred |
| email address when they first login. Gerrit will replace `{0}` |
| with the username, as supplied by Siteminder. A format such as |
| shown in the example would be typical, to add the domain name of |
| the organization. |
| |
| If Jetty is being used, you may need to increase the header |
| buffer size parameter, due to very long header lines. |
| Add the following to `$JETTY_HOME/etc/jetty.xml` under |
| `org.mortbay.jetty.nio.SelectChannelConnector`: |
| |
| ==== |
| <Set name="headerBufferSize">16384</Set> |
| ==== |
| |
| |
| Database Schema |
| ~~~~~~~~~~~~~~~ |
| |
| User identities are stored in the `account_external_ids` table. |
| The user string obtained from Siteminder (e.g. the value in the |
| "SM_USER" HTTP header) has the prefix "gerrit:" and is stored in the |
| `external_id` field. For example, if a Siteminder username was "foo" |
| then the external_id field would be populated with "gerrit:foo". |
| |
| GERRIT |
| ------ |
| Part of link:index.html[Gerrit Code Review] |