GitSwarm can be configured to act as a SAML 2.0 Service Provider (SP). This allows GitSwarm to consume assertions from a SAML 2.0 Identity Provider (IdP) such as Microsoft ADFS to authenticate users.
First configure SAML 2.0 support in GitSwarm, then register the GitSwarm application in your SAML IdP:
Make sure GitSwarm is configured with HTTPS. See Using HTTPS for instructions.
On your GitSwarm server, open the configuration file.
For package installation:
sudo editor /etc/gitswarm/gitswarm.rbFor source installations:
cd /home/git/gitlab
sudo -u git -H editor config/gitlab.ymlSee Initial OmniAuth Configuration for initial settings.
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 package installation:
gitlab_rails['omniauth_allow_single_sign_on'] = ['saml']
gitlab_rails['omniauth_block_auto_created_users'] = falseFor source installations:
allow_single_sign_on: ["saml"]
block_auto_created_users: falseYou can also automatically link SAML users with existing GitSwarm users if their email addresses match by adding the following setting:
For package installation:
gitlab_rails['omniauth_auto_link_saml_user'] = trueFor source installations:
auto_link_saml_user: trueAdd the provider configuration:
For package installation:
gitlab_rails['omniauth_providers'] = [
{
name: 'saml',
args: {
assertion_consumer_service_url: 'https://gitswarm.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://gitswarm.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"
}
]For source installations:
- {
name: 'saml',
args: {
assertion_consumer_service_url: 'https://gitswarm.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://gitswarm.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"
}Change the value for assertion_consumer_service_url to match the HTTPS endpoint of GitSwarm (append users/auth/saml/callback to the HTTPS URL of your GitLab installation to generate the correct value).
Change the values of idp_cert_fingerprint, idp_sso_target_url, name_identifier_format to match your IdP. Check the omniauth-saml documentation for details on these options.
Change the value of issuer to a unique name, which will identify the application to the IdP.
Restart GitSwarm for the changes to take effect.
Register the GitSwarm SP in your SAML 2.0 IdP, using the application name specified in issuer.
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 GitSwarm, append users/auth/saml/metadata to the HTTPS URL of your GitLab installation, for instance: https://gitswarm.example.com/users/auth/saml/metadata
At a minimum the IdP must provide a claim containing the user's email address, using claim name email or mail. The email will be used to automatically generate the GitSwarm username. GitSwarm will also use claims with name name, first_name, last_name (see the omniauth-saml gem for supported claims).
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 GitSwarm and will be signed in.
Note: This setting is only available on GitSwarm 2016.2 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 marked as external.
First you need to tell GitSwarm 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:
<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 GitSwarm where to find these groups, you need to add a groups_attribute: element to your SAML settings. You will also need to tell GitSwarm which groups are external via the external_groups: element:
{ name: 'saml',
label: 'Our SAML Provider',
groups_attribute: 'Groups',
external_groups: ['Freelancers', 'Interns'],
args: {
assertion_consumer_service_url: 'https://gitswarm.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://gitswarm.example.com',
name_identifier_format: 'urn:oasis:names:tc:SAML:2.0:nameid-format:transient'
} }auto_sign_in_with_providerYou can add this setting to your GitSwarm configuration to automatically redirect you to your SAML server for authentication, thus removing the need to click a button before actually signing in.
For package installation:
gitlab_rails['omniauth_auto_sign_in_with_provider'] = 'saml'For source installations:
omniauth:
auto_sign_in_with_provider: samlPlease 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.
attribute_statementsNote: This setting is only available on GitSwarm 2016.2 and above. This setting should only be used to map attributes that are part of the OmniAuth info hash schema.
attribute_statements is used to map Attribute Names in a SAMLResponse to entries in the OmniAuth info hash.
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 GitSwarm where to look for certain attributes required to create an account. Like mentioned above, if your IdP sends the user's email address as EmailAddress instead of email, let GitSwarm know by setting it on your configuration:
args: {
assertion_consumer_service_url: 'https://gitswarm.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://gitswarm.example.com',
name_identifier_format: 'urn:oasis:names:tc:SAML:2.0:nameid-format:transient',
attribute_statements: { email: ['EmailAddress'] }
}allowed_clock_driftThe clock of the Identity Provider may drift slightly ahead of your system clocks. 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.
args: {
assertion_consumer_service_url: 'https://gitswarm.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://gitswarm.example.com',
name_identifier_format: 'urn:oasis:names:tc:SAML:2.0:nameid-format:transient',
attribute_statements: { email: ['EmailAddress'] },
allowed_clock_drift: 1 # for one second clock drift
}If you see a "500 error" in GitSwarm when you are redirected back from the SAML sign in page, this likely indicates that GitSwarm could not get the email address for the SAML user.
Make sure the IdP provides a claim containing the user's email address, using claim name email or mail.
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 GitSwarm 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 GitSwarm, where it can then be seen in the usual logs, or as a flash message in the login screen.
That file is located at /opt/gitswarm/embedded/service/gitlab-rails/app/controllers for package installations and by default on /home/git/gitlab/app/controllers for source installations.
This error means that the IdP doesn't recognize GitSwarm as a valid sender and receiver of SAML requests. Make sure to add the GitSwarm callback URL to the approved audiences of the IdP server.
The IdP server needs to pass certain information in order for GitSwarm 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.
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:
<ds:KeyInfo><ds:X509Data><ds:X509Certificate>)Make sure that one of the above described scenarios is valid, or the requests will fail with one of the mentioned errors.