Shawn O. Pearce | f384b44 | 2009-01-10 16:20:56 -0800 | [diff] [blame] | 1 | Gerrit2 - Single Sign-On Security |
| 2 | ================================= |
| 3 | |
| 4 | Gerrit2 supports integration with some types of single sign-on |
| 5 | security solutions, making it possible for end-users to setup |
| 6 | and manage accounts, without administrator involvement. |
| 7 | |
| 8 | OpenID |
| 9 | ------ |
| 10 | |
| 11 | By default a new Gerrit installation relies upon OpenID to perform |
| 12 | user authentication services. To enable OpenID, the `system_config` |
| 13 | table needs `login_type` set to `OPENID`: |
| 14 | |
| 15 | ==== |
| 16 | UPDATE system_config SET login_type = 'OPENID'; |
| 17 | ==== |
| 18 | |
| 19 | As this is the default setting for new installations there is |
| 20 | nothing required from the site administrator to make use of the |
| 21 | OpenID authentication services. |
| 22 | |
| 23 | * http://openid.net/[openid.net] |
| 24 | |
| 25 | Database Schema |
| 26 | ~~~~~~~~~~~~~~~ |
| 27 | |
| 28 | User identities obtained from OpenID providers are stored into the |
| 29 | `account_external_ids` table. Users may link more than one OpenID |
| 30 | identity to the same Gerrit account (use Settings, Web Identities |
| 31 | to manage this linking), making it easier for their browser to sign |
| 32 | in to Gerrit if they are frequently switching between different |
| 33 | unique OpenID accounts. |
| 34 | |
| 35 | |
| 36 | HTTP Basic/Digest Authentication |
| 37 | -------------------------------- |
| 38 | |
| 39 | When using HTTP authentication, Gerrit assumes that the servlet |
| 40 | container or the frontend web server has performed all user |
| 41 | authentication prior to handing the request off to Gerrit. |
| 42 | |
| 43 | As a result of this assumption, Gerrit can assume that any and |
| 44 | all requests have already been authenticated. The "Sign In" and |
| 45 | "Sign Out" links are therefore not displayed in the web UI. |
| 46 | |
| 47 | To enable this form of authentication, update `system_config`: |
| 48 | |
| 49 | ==== |
| 50 | UPDATE system_config |
| 51 | SET |
| 52 | login_type='HTTP' |
| 53 | ,login_http_header=NULL |
| 54 | ,email_format='{0}@example.com'; |
| 55 | ==== |
| 56 | |
| 57 | The `login_type` must always be `HTTP`, indicating the user identity |
| 58 | will be obtained from the HTTP authorization data. |
| 59 | |
| 60 | The `login_http_header` must always be `NULL`. If non-null then |
| 61 | Gerrit won't correctly honor the `Authorization` HTTP header. |
| 62 | |
| 63 | The `email_format` field ('optional') sets the preferred email |
| 64 | address during first login. Gerrit will replace `\{0\}` with the |
| 65 | username, as obtained from the Authorization header. A format such |
| 66 | as shown in the example would be typical, to add the domain name |
| 67 | of the organization. |
| 68 | |
Shawn O. Pearce | 9520f98 | 2009-02-06 10:25:11 -0800 | [diff] [blame^] | 69 | If Apache HTTPd is being used as the primary web server and Apache |
| 70 | will be handling authentication, a configuration such as the |
| 71 | following is recommended to ensure repo can obtain the `/ssh_info` |
| 72 | URL during `repo upload`: |
| 73 | |
| 74 | ==== |
| 75 | <Location "/ssh_info"> |
| 76 | # We don't want authentication for this one location, |
| 77 | # as repo uses it to grab our hostname and ssh port |
| 78 | # |
| 79 | ProxyPass http://127.0.0.1:8081/ssh_info |
| 80 | Allow from all |
| 81 | Satisfy Any |
| 82 | </Location> |
| 83 | # |
| 84 | <Location "/"> |
| 85 | # Everything else should be protected by password |
| 86 | # |
| 87 | ProxyPass http://127.0.0.1:8081/ |
| 88 | AuthType Basic |
| 89 | AuthName "Gerrit Review Server" |
| 90 | Require valid-user |
| 91 | ... |
| 92 | </Location> |
| 93 | ==== |
| 94 | |
Shawn O. Pearce | f384b44 | 2009-01-10 16:20:56 -0800 | [diff] [blame] | 95 | Database Schema |
| 96 | ~~~~~~~~~~~~~~~ |
| 97 | |
| 98 | User identities are stored in the `account_external_ids` table. |
| 99 | The user string obtained from the authorization header has the prefix |
| 100 | "gerrit:" and is stored in the `external_id` field. For example, |
| 101 | if a username was "foo" then the external_id field would be populated |
| 102 | with "gerrit:foo". |
| 103 | |
| 104 | |
| 105 | Computer Associates Siteminder |
| 106 | ------------------------------ |
| 107 | |
| 108 | Siteminder is a commercial single sign on solution marketed by |
| 109 | Computer Associates. It is very common in larger enterprise |
| 110 | environments. |
| 111 | |
| 112 | When using Siteminder, Gerrit assumes it has been installed in a |
| 113 | servlet container which is running behind an Apache web server, |
| 114 | and that the Siteminder authentication module has been configured |
| 115 | within Apache to protect the entire Gerrit application. In this |
| 116 | configuration all users must authenticate with Siteminder before |
| 117 | they can access any resource on Gerrit. |
| 118 | |
| 119 | As a result of this assumption, Gerrit can assume that any and |
| 120 | all requests have already been authenticated. The "Sign In" and |
| 121 | "Sign Out" links are therefore not displayed in the web UI. |
| 122 | |
| 123 | To enable this form of authentication, update `system_config`: |
| 124 | |
| 125 | ==== |
| 126 | UPDATE system_config |
| 127 | SET |
| 128 | login_type='HTTP' |
| 129 | ,login_http_header='SM_USER' |
| 130 | ,email_format='{0}@example.com'; |
| 131 | ==== |
| 132 | |
| 133 | The `login_type` must always be `HTTP`, indicating the user identity |
| 134 | will be obtained from an HTTP header. |
| 135 | |
| 136 | The `login_http_header` indicates which HTTP header field the |
| 137 | Siteminder product has stored the username. Usually this is |
| 138 | "SM_USER", but may differ in your environment. Please refer to |
| 139 | your organization's single sign-on or security group to ensure the |
| 140 | setting is correct. |
| 141 | |
| 142 | The `email_format` field ('optional') sets the user's preferred email |
| 143 | address when they first login. Gerrit will replace `\{0\}` with the |
| 144 | username, as supplied by Siteminder. A format such as shown in the |
| 145 | example would be typical, to add the domain name of the organization. |
| 146 | |
Shawn O. Pearce | 9520f98 | 2009-02-06 10:25:11 -0800 | [diff] [blame^] | 147 | If Apache HTTPd is being used, see the section above to configure |
| 148 | the `/ssh_info` URL to be available to `repo upload`. |
| 149 | |
| 150 | |
Shawn O. Pearce | f384b44 | 2009-01-10 16:20:56 -0800 | [diff] [blame] | 151 | Database Schema |
| 152 | ~~~~~~~~~~~~~~~ |
| 153 | |
| 154 | User identities are stored in the `account_external_ids` table. |
| 155 | The user string obtained from Siteminder (e.g. the value in the |
| 156 | "SM_USER" HTTP header) has the prefix "gerrit:" and is stored in the |
| 157 | `external_id` field. For example, if a Siteminder username was "foo" |
| 158 | then the external_id field would be populated with "gerrit:foo". |
| 159 | |