You are viewing an old version of this page. View the current version.
This guide describes how Gitlab CE v13.x can be configured as a SAML Service Provider for eduTEAMS. The integration via SAML provides more benefits than the integration via OIDC, as the SAML implementation in Gitlab has (limited) support for authorizing users using groups. The OIDC implementation in Gitlab supports only authenticating users.
1. In order to set up a basic configuration, which would allow all users from your VO to authenticate via eduTEAMS and access the Gitlab service, you should edit the omniauth section /etc/gitlab/gitlab.rb config file.
NOTE: The "STEP nnn" comments refer directly to the OmniAuth guide https://docs.gitlab.com/13.0/ee/integration/saml.html.
2. In order to edit this part of the config file correctly, you should have the values for the configuration options defined and known.
Also you need to generate a private / public key pair that will be used by the SAML SP to digitally sign and optionally decrypt SAML Assertsions. You can generate a key pair with the following command from your terminal:
Note: The private and the public key are going to be printed in the standard output.
|attribute_service_name:||(example) eduTEAMS Test Gitlab||The name of your service. This name will be visible to the end users|
|assertion_consumer_service_url||(example)https://gitlab.example.com/users/auth/saml/callback||The HTTPS endpoint of your GitLab instance|
|idp_cert_fingerprint||72:8A:6C:6B:63:35:3F:E0:BF:70:8D:41:0E:B7:02:CF:C5:86:53:24||This is the SHA1 fingerprint of the signing certificate used by the eduTEAMS SAML frontend|
|idp_sso_target_url||https://proxy.eduteams.org/saml2sp/sso/redirect||This is the eduTEAMS endpoint supporting the HTTP-Redirect SAML 2.0 Binding|
|issuer||A unique name identifying the gitlab application to the proxy. This should be changed to the toplevel domain of your Gitlab instance|
|name_identifier_format||urn:oasis:names:tc:SAML:2.0:nameid-format:persistent||The NameID format requested|
|uid_attribute||urn:oid:18.104.22.168.4.1.5922.214.171.124.13||By default Gitlab uses the NameID attribute as the unique identifier. With this configuration option we configure gitlab to use urn:oid:126.96.36.199.4.1.59188.8.131.52.13 (eduPersonUniqueId)|
This option controls the SAML attributes that are going to be include in the SAML of metadata for Gitlab.
The attributes required are:
For more information on the attributes that are available to services from eduTEAMS, you can read Attributes available to Relying Parties
|attribute_statements||This configure options controls the mapping from the SAML attributes to the Gitlab internal attributes|
This is the private key that is going to be used to sign the and optionally decrypt encrypted SAML assertions.
Copy the private key that you generated in your terminal
This is the certificate that is going to be used to sign the and optionally decrypt encrypted SAML assertions.
Copy the certificate that you generated in your terminal
This configuration option controls several aspects of the security configuration for the SP
Full group definition:
You should replace the <VO_Name> with your VO name to which you would like to connect the Gitlab service;
You should replace the <Top_level group>:[<Sub_group_name>] with your group (and subgroup) name which should have access to the Gitlab service;
The SAML login in Gitlab includes support for limiting access to specific groups from your VO and authorizing users using these groups. There are four groups types that can be configured: required, admin, audit and external.
1. In order to add to a basic configuration, which would allow all users from your VO to authenticate via eduTEAMS and access the Gitlab service, you should edit the omniauth section /etc/gitlab/gitlab.rb config file, after the
- You can control which groups can access the Gitlab instance using the
required_groupsconfiguration option. When
required_groupsis not set or it is empty, anyone with proper authentication will be able to use the service.
- You can control if a user should be assigned the admin role, using the
- You can control if a user should be assigned the auditor role, using the
- You can control if a user should be marked as external, using the
2. Once you edited the omniauth section of the /etc/gitlab/gitlab.rb file as above indicated, you need to reconfigure gitlab with the command:
3. You should be able to check the SAML metadata URL of the Gitlab instance at https://<gitlab.example.com>/users/auth/saml/metadata .
4. Congratulations, you have successfully configured your Gitlab instance for eduTEAMS. Now you can proceed to register your service following the steps described in Registering services on the eduTEAMS Service.
- No labels