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.
|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|
|name_identifier_format||urn:oasis:names:tc:SAML:2.0:nameid-format:persistent||The NameID format requested|
|uid||urn:oasis:names:tc:SAML:attribute:subject-id||See Attributes available to Relying Parties#eduTEAMSIdentifier|
|urn:oid:0.9.2342.19200300.100.1.3||See Attributes available to Relying Parties#Emailaddress|
|first_name||urn:oid:220.127.116.11||See Attributes available to Relying Parties#GivenName|
|last_name||urn:oid:18.104.22.168||See Attributes available to Relying Parties#FamilyName|
|groups_attribute||urn:oid:22.214.171.124.4.1.59126.96.36.199.7||See Attributes available to Relying Parties#Groups|
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