BigW Consortium Gitlab

saml.md 11.6 KB
Newer Older
1 2
# SAML OmniAuth Provider

3 4 5
GitLab can be configured to act as a SAML 2.0 Service Provider (SP). This allows
GitLab to consume assertions from a SAML 2.0 Identity Provider (IdP) such as
Microsoft ADFS to authenticate users.
6

7 8
First configure SAML 2.0 support in GitLab, then register the GitLab application
in your SAML IdP:
9

10 11
1.  Make sure GitLab is configured with HTTPS.
    See [Using HTTPS](../install/installation.md#using-https) for instructions.
12 13 14 15 16 17 18 19 20

1.  On your GitLab server, open the configuration file.

    For omnibus package:

    ```sh
      sudo editor /etc/gitlab/gitlab.rb
    ```

21
    For installations from source:
22 23 24 25 26 27 28

    ```sh
      cd /home/git/gitlab

      sudo -u git -H editor config/gitlab.yml
    ```

29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62
1.  See [Initial OmniAuth Configuration](omniauth.md#initial-omniauth-configuration)
    for initial settings.

1.  To allow your users to use SAML to sign up without having to manually create
    an account first, don't forget to add the following values to your configuration:

    For omnibus package:

    ```ruby
      gitlab_rails['omniauth_allow_single_sign_on'] = ['saml']
      gitlab_rails['omniauth_block_auto_created_users'] = false
    ```

    For installations from source:

    ```yaml
      allow_single_sign_on: ["saml"]
      block_auto_created_users: false
    ```

1.  You can also automatically link SAML users with existing GitLab users if their
    email addresses match by adding the following setting:

    For omnibus package:

    ```ruby
      gitlab_rails['omniauth_auto_link_saml_user'] = true
    ```

    For installations from source:

    ```yaml
      auto_link_saml_user: true
    ```
63 64 65 66 67 68 69 70

1.  Add the provider configuration:

    For omnibus package:

    ```ruby
      gitlab_rails['omniauth_providers'] = [
        {
71 72
          name: 'saml',
          args: {
73 74 75 76 77
                   assertion_consumer_service_url: 'https://gitlab.example.com/users/auth/saml/callback',
                   idp_cert_fingerprint: '43:51:43:a1:b5:fc:8b:b7:0a:3a:a9:b1:0f:66:73:a8',
                   idp_sso_target_url: 'https://login.example.com/idp',
                   issuer: 'https://gitlab.example.com',
                   name_identifier_format: 'urn:oasis:names:tc:SAML:2.0:nameid-format:transient'
78
                 },
79
          label: 'Company Login' # optional label for SAML login button, defaults to "Saml"
80 81 82 83 84 85 86
        }
      ]
    ```

    For installations from source:

    ```yaml
87 88 89 90 91 92 93 94 95 96 97
      - {
          name: 'saml',
          args: {
                 assertion_consumer_service_url: 'https://gitlab.example.com/users/auth/saml/callback',
                 idp_cert_fingerprint: '43:51:43:a1:b5:fc:8b:b7:0a:3a:a9:b1:0f:66:73:a8',
                 idp_sso_target_url: 'https://login.example.com/idp',
                 issuer: 'https://gitlab.example.com',
                 name_identifier_format: 'urn:oasis:names:tc:SAML:2.0:nameid-format:transient'
               },
          label: 'Company Login' # optional label for SAML login button, defaults to "Saml"
        }
98 99
    ```

Patricio Cano committed
100 101
1.  Change the value for `assertion_consumer_service_url` to match the HTTPS endpoint
    of GitLab (append `users/auth/saml/callback` to the HTTPS URL of your GitLab
102
    installation to generate the correct value).
103

Patricio Cano committed
104 105
1.  Change the values of `idp_cert_fingerprint`, `idp_sso_target_url`,
    `name_identifier_format` to match your IdP. Check
106 107
    [the omniauth-saml documentation](https://github.com/omniauth/omniauth-saml)
    for details on these options.
108

Patricio Cano committed
109
1.  Change the value of `issuer` to a unique name, which will identify the application
110
    to the IdP.
111 112 113

1.  Restart GitLab for the changes to take effect.

114
1.  Register the GitLab SP in your SAML 2.0 IdP, using the application name specified
Patricio Cano committed
115
    in `issuer`.
116

117 118
To ease configuration, most IdP accept a metadata URL for the application to provide
configuration information to the IdP. To build the metadata URL for GitLab, append
Patricio Cano committed
119
`users/auth/saml/metadata` to the HTTPS URL of your GitLab installation, for instance:
120 121 122 123
   ```
   https://gitlab.example.com/users/auth/saml/metadata
   ```

124
At a minimum the IdP *must* provide a claim containing the user's email address, using
Patricio Cano committed
125 126
claim name `email` or `mail`. The email will be used to automatically generate the GitLab
username. GitLab will also use claims with name `name`, `first_name`, `last_name`
127 128
(see [the omniauth-saml gem](https://github.com/omniauth/omniauth-saml/blob/master/lib/omniauth/strategies/saml.rb)
for supported claims).
129

130 131 132
On the sign in page there should now be a SAML button below the regular sign in form.
Click the icon to begin the authentication process. If everything goes well the user
will be returned to GitLab and will be signed in.
133

Patricio Cano committed
134 135 136 137 138 139 140
## External Groups

>**Note:**
This setting is only available on GitLab 8.7 and above.

SAML login includes support for external groups. You can define in the SAML
settings which groups, to which your users belong in your IdP, you wish to be
141
marked as [external](../user/permissions.md).
Patricio Cano committed
142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161

### Requirements

First you need to tell GitLab where to look for group information. For this you
need to make sure that your IdP server sends a specific `AttributeStament` along
with the regular SAML response. Here is an example:

```xml
<saml:AttributeStatement>
  <saml:Attribute Name="Groups">
    <saml:AttributeValue xsi:type="xs:string">SecurityGroup</saml:AttributeValue>
    <saml:AttributeValue xsi:type="xs:string">Developers</saml:AttributeValue>
    <saml:AttributeValue xsi:type="xs:string">Designers</saml:AttributeValue>
  </saml:Attribute>
</saml:AttributeStatement>
```

The name of the attribute can be anything you like, but it must contain the groups
to which a user belongs. In order to tell GitLab where to find these groups, you need
to add a `groups_attribute:` element to your SAML settings. You will also need to
162
tell GitLab which groups are external via the `external_groups:` element:
Patricio Cano committed
163 164 165 166 167 168 169 170 171 172 173 174 175 176 177

```yaml
{ name: 'saml',
  label: 'Our SAML Provider',
  groups_attribute: 'Groups',
  external_groups: ['Freelancers', 'Interns'],
  args: {
          assertion_consumer_service_url: 'https://gitlab.example.com/users/auth/saml/callback',
          idp_cert_fingerprint: '43:51:43:a1:b5:fc:8b:b7:0a:3a:a9:b1:0f:66:73:a8',
          idp_sso_target_url: 'https://login.example.com/idp',
          issuer: 'https://gitlab.example.com',
          name_identifier_format: 'urn:oasis:names:tc:SAML:2.0:nameid-format:transient'
        } }
```

178 179
## Customization

Patricio Cano committed
180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202
### `auto_sign_in_with_provider`

You can add this setting to your GitLab configuration to automatically redirect you
to your SAML server for authentication, thus removing the need to click a button
before actually signing in.

For omnibus package:

```ruby
gitlab_rails['omniauth_auto_sign_in_with_provider'] = 'saml'
```

For installations from source:

```yaml
omniauth:
  auto_sign_in_with_provider: saml
```

Please keep in mind that every sign in attempt will be redirected to the SAML server,
so you will not be able to sign in using local credentials. Make sure that at least one
of the SAML users has admin permissions.

Patricio Cano committed
203
### `attribute_statements`
204 205 206 207 208 209

>**Note:**
This setting is only available on GitLab 8.6 and above.
This setting should only be used to map attributes that are part of the
OmniAuth info hash schema.

Patricio Cano committed
210 211
`attribute_statements` is used to map Attribute Names in a SAMLResponse to entries
in the OmniAuth [info hash](https://github.com/intridea/omniauth/wiki/Auth-Hash-Schema#schema-10-and-later).
212 213 214 215 216 217 218

For example, if your SAMLResponse contains an Attribute called 'EmailAddress',
specify `{ email: ['EmailAddress'] }` to map the Attribute to the
corresponding key in the info hash.  URI-named Attributes are also supported, e.g.
`{ email: ['http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress'] }`.

This setting allows you tell GitLab where to look for certain attributes required
Patricio Cano committed
219
to create an account. Like mentioned above, if your IdP sends the user's email
220 221 222 223 224 225 226 227 228 229
address as `EmailAddress` instead of `email`, let GitLab know by setting it on
your configuration:

```yaml
args: {
        assertion_consumer_service_url: 'https://gitlab.example.com/users/auth/saml/callback',
        idp_cert_fingerprint: '43:51:43:a1:b5:fc:8b:b7:0a:3a:a9:b1:0f:66:73:a8',
        idp_sso_target_url: 'https://login.example.com/idp',
        issuer: 'https://gitlab.example.com',
        name_identifier_format: 'urn:oasis:names:tc:SAML:2.0:nameid-format:transient',
230
        attribute_statements: { email: ['EmailAddress'] }
231 232 233
}
```

Patricio Cano committed
234
### `allowed_clock_drift`
235 236

The clock of the Identity Provider may drift slightly ahead of your system clocks.
Patricio Cano committed
237 238 239
To allow for a small amount of clock drift you can use `allowed_clock_drift` within
your settings. Its value must be given in a number (and/or fraction) of seconds.
The value given is added to the current time at which the response is validated.
240 241 242 243 244 245 246 247

```yaml
args: {
        assertion_consumer_service_url: 'https://gitlab.example.com/users/auth/saml/callback',
        idp_cert_fingerprint: '43:51:43:a1:b5:fc:8b:b7:0a:3a:a9:b1:0f:66:73:a8',
        idp_sso_target_url: 'https://login.example.com/idp',
        issuer: 'https://gitlab.example.com',
        name_identifier_format: 'urn:oasis:names:tc:SAML:2.0:nameid-format:transient',
248
        attribute_statements: { email: ['EmailAddress'] },
249 250 251 252
        allowed_clock_drift: 1 # for one second clock drift
}
```

253 254
## Troubleshooting

255
### 500 error after login
256

257 258
If you see a "500 error" in GitLab when you are redirected back from the SAML sign in page,
this likely indicates that GitLab could not get the email address for the SAML user.
259

260
Make sure the IdP provides a claim containing the user's email address, using claim name
Patricio Cano committed
261
`email` or `mail`.
262

263
### Redirect back to login screen with no evident error
264

265 266 267 268 269 270 271 272
If after signing in into your SAML server you are redirected back to the sign in page and
no error is displayed, check your `production.log` file. It will most likely contain the
message `Can't verify CSRF token authenticity`. This means that there is an error during
the SAML request, but this error never reaches GitLab due to the CSRF check.

To bypass this you can add `skip_before_action :verify_authenticity_token` to the
`omniauth_callbacks_controller.rb` file. This will allow the error to hit GitLab,
where it can then be seen in the usual logs, or as a flash message in the login
273 274
screen.

Patricio Cano committed
275 276 277 278
That file is located at `/opt/gitlab/embedded/service/gitlab-rails/app/controllers`
for Omnibus installations and by default on `/home/git/gitlab/app/controllers` for
installations from source.

279
### Invalid audience
280 281 282 283 284

This error means that the IdP doesn't recognize GitLab as a valid sender and
receiver of SAML requests. Make sure to add the GitLab callback URL to the approved
audiences of the IdP server.

285
### Missing claims
286 287 288 289 290 291 292 293

The IdP server needs to pass certain information in order for GitLab to either
create an account, or match the login information to an existing account. `email`
is the minimum amount of information that needs to be passed. If the IdP server
is not providing this information, all SAML requests will fail.

Make sure this information is provided.

294
### Key validation error, Digest mismatch or Fingerprint mismatch
295 296 297 298 299 300 301 302 303 304 305 306 307 308

These errors all come from a similar place, the SAML certificate. SAML requests
need to be validated using a fingerprint, a certificate or a validator.

For this you need take the following into account:

- If no certificate is provided in the settings, a fingerprint or fingerprint
  validator needs to be provided and the response from the server must contain
  a certificate (`<ds:KeyInfo><ds:X509Data><ds:X509Certificate>`)
- If a certificate is provided in the settings, it is no longer necessary for
  the request to contain one. In this case the fingerprint or fingerprint
  validators are optional

Make sure that one of the above described scenarios is valid, or the requests will
309
fail with one of the mentioned errors.