This section provides the configuration information on integrating Advanced Authentication with GitLab. This integration secures the GitLab connection.
To configure the integration of Advanced Authentication appliance with GitLab using SAML 2.0 perform following tasks:
Ensure that the following requirements are met:
Advanced Authentication is configured with a repository (Active Directory).
A user account has been created in a repository that corresponds to a user account in GitLab. The email address used for logging in to the GitLab account must be the same as an address from email attribute for the corresponding account of your repository.
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 (which is Advanced Authentication here).
First configure SAML 2.0 support in GitLab, then register the GitLab application in the Identity Provider (IdP).
On your GitLab server, perform the following steps:
In the vi /etc/gitlab/gitlab.rb file, perform the following steps:
To allow users to use SAML to sign up without having to manually create an account first, add the following values to your configuration for omnibus package:
gitlab_rails['omniauth_enabled'] = true
gitlab_rails['omniauth_allow_single_sign_on'] = ['saml']
gitlab_rails['omniauth_block_auto_created_users'] = false
You can automatically link SAML users with existing GitLab users if their email addresses match by adding the following setting:
gitlab_rails['omniauth_auto_link_saml_user'] = true
Add the provider configuration:
gitlab_rails['omniauth_providers'] = [
{
name: 'saml',
args:{
assertion_consumer_service_url: 'https://<gitlabserver address>/users/auth/saml/callback',
idp_cert_fingerprint: 'A3:8D:36:9E:9C:B7:31:0E:14:26:A5:10:68:73:07:A7:CA:7C:9E:BB',
idp_sso_target_url: 'https://<adfs-serveraddress>/adfs/ls/',
idp_slo_target_url: 'https://<adfs-serveraddress>/adfs/ls/',
issuer: 'https://<gitlab_serveraddress>',
name_identifier_format: 'urn:oasis:names:tc:SAML:2.0:nameid-format:transient',
attribute_statements: {
username: ['http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn'],
email: ['http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress'],
name: ['http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name'],
first_name: ['http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname'],
last_name: ['http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname'],
}
}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 installation to generate the correct value).
Change the values of idp_cert_fingerprint, idp_sso_target_url, name_identifier_format to match your IdP. If a fingerprint is used, it must be a SHA1 fingerprint. For more information, see the omniauth-saml documentation.
Change the value of issuer to a unique name, which will identify the application to the IdP. Ensure to configure the issuer with the GitLab server address.
For the changes to take effect, you must reconfigure GitLab if you installed through Omnibus.
Register the GitLab SP in the IdP(Advanced Authentication). For more information, see Configuring the SAML 2.0 Event on Advanced Authentication.
On the ADFS Management console, click Relying Party Trusts > Add Relying Party Trust.
Click Start.
To import GitLab metadata, perform the following:
Select Import data about the relying party from a file.
Specify the GitLab URL in https://<gitlab_serveraddress>/users/auth/saml/metadata format.
Click Next.
Specify Display Name and Notes for GitLab and click Next.
Select Permit everyone from Choose an access control policy list to configure access control policy for ADFS and click Next.
Verify the values imported from the GitLab metadata and click Next.
Select Configure claims issuance policy for this application and click Close.
Select the trust created for GitLab on the Relying Party Trusts and click Edit Claim Rules.
In the Issuance Transform Rule tab, add two rules:
To add the first rule, perform the following steps:
Click Add Rule.
Select Transform an incoming Claim from Claim Rule Template.
Specify the Claim rule name.
Select Name ID from Incoming claim type.
Select Unspecified from Incoming name ID format.
Select Name ID from Outgoing claim type.
Select Transient Identifier from Outgoing name ID format.
Select Pass through all claim values.
Click Finish.
To add the second rule, perform the following steps:
Click Add Rule.
Select Pass Through or Filter an Incoming Claim from Claim Rule Template and click Next.
Specify the Claim rule name.
Select E-mail Address from Incoming claim type.
Select Pass through all claim values.
Click Finish.
Open the ADFS management console.
Expand the Trust Relationships menu.
Click Add Claims Provider trust.
Select Import data about the claims provider.
Paste OSP metadata URL in https://<AAF_server_hostname>/osp/a/TOP/auth/saml2/metadata format or import the file manually.
It may not work for the self-signed certificate. You can copy metadata from OSP URL to an XML file and provide the file name.
Specify the Display name.
Edit Claim Rules for the created claims provider trust.
In the Acceptance Transform Rules tab, add two rules:
To add the first rule, perform the following steps:
Click Add Rule.
Select Transform an incoming Claim from Claim Rule Template and click Next.
Specify Claim rule name.
Select Name ID from Incoming claim type.
Select Transient Identifier from Incoming name ID format.
Select Name ID from Outgoing claim type.
Select Unspecified from Outgoing name ID format.
Select Pass through all claim values.
Click Finish.
To add the second rule, perform the following steps:
Click Add Rule.
Select Transform an incoming Claim from Claim Rule Template and click Next.
Specify the Claim rule name.
Select mail from Incoming Claim Type.
Select E-mail Address from Outgoing claim type.
Select Pass through all claim values
click Finish.
Open Properties for the created claims provider trust and navigate to the Endpoints tab.
Ensure that the Binding of all endpoints is set to POST.
WARNING:While removing the existing endpoints from the Endpoints tab, make a note of configuration to re-create an endpoint and set the Binding to POST.
Click OK.
Open the Advanced Authentication Administration portal.
Click Events > Add.
Create an event with the following parameters:
Name: GitLab
Chains: select the required chains.
Paste the content of the file https://<adfs_hostname>/FederationMetadata/2007-06/FederationMetadata.xml to the SP SAML 2.0 meta data.
or
Click Choose File and upload the saved XML file.
Click Save.
NOTE:Verify that you can access the file in your browser. If the file is not displayed, then you have an issue on ADFS that you need to resolve.
Click Policies > Web Authentication.
Set External URL to https://AdvancedAuthenticationServerAddress/ and replace AdvancedAuthenticationServerAddress with domain name or IP address of your Advanced Authentication server.
NOTE:To use multiple Advanced Authentication servers with SAML 2.0, you must do the following:
Configure an external load balancer.
Specify the address in External URL instead of specifying an address of a single Advanced Authentication server.
Click Download IdP SAML 2.0 Metadata.
You must open the file as an XML file.
NOTE:If {"Fault":{... ` is displayed, you must verify the configuration.