Предусловия:

• Установленный и настроенный GitLab
• Установленный и настроенный ADFS
• Установленный и настроенный Indeed AM (9.4 и выше)
• Настроенное расширение Indeed ADFS Extension для второго фактора аутентификации (настройка расширения описана в документации Indeed AM); приложение ADFS должно быть добавлено в соответствующую политику в МС Indeed AM. Подразумевается, что расширение уже установлено и на нём зарегистрирован хотя бы один аутентификатор — в этой инструкции используется Indeed Key.

В примерах используется нестандартный порт 8443 — актуально для случаев, когда порт 443 на сервере GitLab уже занят другим сервисом. Если у вас GitLab работает на стандартном порту 443, во всех адресах ниже порт указывать не нужно.

Настройка GitLab

1. Сертификат для подписи SAML-запросов

Отдельный сертификат — используется GitLab для подписи AuthnRequest.

mkdir -p ~/gitlab-deploy/config/ssl/saml
cd ~/gitlab-deploy/config/ssl/saml

openssl req -x509 -newkey rsa:2048 -keyout gitlab-saml.key -out gitlab-saml.crt \
  -days 3650 -nodes -subj "/CN=gitlab.example.local"

2. Добавление SAML-провайдера в конфигурацию GitLab

В gitlab.rb (либо в GITLAB_OMNIBUS_CONFIG, если GitLab развёрнут в Docker) добавить блок:

gitlab_rails['omniauth_enabled'] = true
gitlab_rails['omniauth_allow_single_sign_on'] = ['saml']
gitlab_rails['omniauth_auto_link_saml_user'] = true
gitlab_rails['omniauth_block_auto_created_users'] = false

gitlab_rails['omniauth_providers'] = [
  {
    name: "saml",
    label: "ADFS SSO",
    args: {
      assertion_consumer_service_url: "https://gitlab.example.local:8443/users/auth/saml/callback",
      idp_cert_fingerprint: "<SHA1-отпечаток token-signing сертификата ADFS>",
      idp_sso_target_url: "https://<adfs-server>/adfs/ls/",
      issuer: "https://gitlab.example.local:8443/users/auth/saml/metadata",
      name_identifier_format: "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified",
      certificate: File.read("/etc/gitlab/ssl/saml/gitlab-saml.crt"),
      private_key: File.read("/etc/gitlab/ssl/saml/gitlab-saml.key"),
      security: {
        authn_requests_signed: true,
        want_assertions_signed: true,
        metadata_signed: false,
        signature_method: "http://www.w3.org/2001/04/xmldsig-more#rsa-sha256",
        digest_method: "http://www.w3.org/2001/04/xmlenc#sha256"
      },
      attribute_statements: {
        email: ["UID"],
        name: ["Name"]
      }
    }
  }
]

Где:

• idp_sso_target_url — адрес страницы входа ADFS (см. п. 5 настройки ADFS ниже);
• idp_cert_fingerprint — SHA1-отпечаток token-signing сертификата ADFS (получение см. п. 4 ниже);
• issuer — Entity ID, под которым GitLab регистрируется на стороне ADFS (Identifier в Relying Party Trust);
• name_identifier_format — unspecified, так как в качестве NameID используется UPN, а не email;
• certificate/private_key — сертификат из шага 1, которым GitLab подписывает AuthnRequest;
• attribute_statements.email: ["UID"] — в поле email пользователя GitLab попадёт значение атрибута UID, в который ADFS кладёт UPN (см. настройку Claim Rules ниже). Это позволяет использовать SSO даже для пользователей, у которых в AD не заполнен mail.

3. Применение изменений

Если GitLab установлен как Omnibus-пакет:

gitlab-ctl reconfigure

Если GitLab развёрнут в Docker:

docker compose down
docker compose up -d

4. Получение метаданных GitLab

https://gitlab.example.local:8443/users/auth/saml/metadata

Понадобится для импорта в ADFS на следующем шаге — либо открыть URL напрямую (если у сервера ADFS есть сетевой доступ к GitLab), либо сохранить содержимое в файл и перенести на сервер ADFS.

Настройка ADFS

1. Отношение доверия проверяющей стороны

Управление AD FS → Отношения доверия проверяющей стороны → Добавить отношение доверия проверяющей стороны → Проверяющая сторона поддерживает утверждения → Пуск:

• Выбор источника данных — импорт метаданных GitLab по URL, либо «Импортировать данные о проверяющей стороне из файла» с сохранённым XML.

• Указание отображаемого имени — например GitLab.
• Выбор политики управления доступом — «Разрешение для каждого и запрос MFA».

• Готово.

2. Правила утверждений (Claim Rules)

Правило 1 — Добавить правило → Отправить атрибуты LDAP как утверждения:

• Хранилище атрибутов: Active Directory
• Сопоставление:
  • User-Principal-Name → Тип исходящего утверждения (ввести вручную): UID
  • User-Principal-Name → Тип исходящего утверждения: UPN
  • Display-Name → Тип исходящего утверждения: Name

Правило 2 — Добавить правило → Преобразование входящего утверждения:

• Тип входящего утверждения: UPN
• Тип исходящего утверждения: Идентификатор имени (Name ID)
• Формат идентификатора имени в исходящих утверждениях: «Не указан» (Unspecified)
• Передать все значения утверждений

Применить → ОК.

3. Сертификат подписи запроса от GitLab

Раз GitLab подписывает AuthnRequest (authn_requests_signed: true), ADFS должен знать публичный сертификат GitLab для проверки этой подписи. Он публикуется в метаданных GitLab автоматически (<md:KeyDescriptor use="signing">) и подтягивается вместе с отношением доверия на шаге 1.

Если метаданные импортировались файлом и позже обновлялись — актуализировать сертификат:

Update-AdfsRelyingPartyTrust -TargetName "GitLab" -MetadataFile "C:\path\to\metadata.xml"

Проверка, что сертификат подтянут:

Get-AdfsRelyingPartyTrust -Name "GitLab" | Select -ExpandProperty RequestSigningCertificate

4. Отпечаток сертификата подписи маркеров ADFS

$cert = (Get-AdfsCertificate -CertificateType Token-Signing)[0].Certificate
$cert.GetCertHashString()

Результат — SHA1-отпечаток без разделителей (40 символов). Расставить двоеточия между каждой парой символов и подставить в idp_cert_fingerprint конфига GitLab.

5. Адрес страницы входа ADFS

Управление AD FS → Служба → Конечные точки, тип SAML 2.0/WS-Federation, обычно:

https://<adfs-server>/adfs/ls/

Проверка

• Открыть страницу входа GitLab (/users/sign_in) — на ней отображается кнопка «ADFS SSO».

• Нажать кнопку — происходит перенаправление на страницу входа ADFS, ввести доменный логин и пароль.

• ADFS запрашивает второй фактор через Indeed ADFS Extension — на экране появляется сообщение «В целях безопасности необходимо указать дополнительные данные для проверки учётной записи». Пройти проверку выбранным аутентификатором (в этом примере — Indeed Key).

• После успешного прохождения второго фактора происходит возврат в GitLab уже под залогиненной учётной записью.

• Факт входа фиксируется в Management Console Indeed AM — в разделе События появляется запись об успешной аутентификации пользователя.

Пользователь сопоставляется по значению атрибута UID (UPN), помещённому в поле email профиля GitLab.