Личный кабинет
База знаний: Indeed Access Manager 9 > Примеры настройки Indeed AM с различными системами > Identity Provider
Indeed AM IDP + Gitlab (SAML)
Автор Dmitry Bukreev, Last modified by Dmitry Bukreev на 27 августа 2026 03:19 PM

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

  • Установленный и настроенный Indeed AM (9.4 и выше)
  • Установленный и настроенный GitLab

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

Настройка GitLab

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

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

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. Отпечаток сертификата IDP

Понадобится для параметра idp_cert_fingerprint в конфиге GitLab. Выполняется на сервере AM, из директории с сертификатами:

cd /opt/am/ssl/saml_certs
openssl pkcs12 -in idp.pfx -clcerts -nokeys -out idp-public.crt -nodes
openssl x509 -noout -fingerprint -sha1 -in idp-public.crt

При запросе пароля к .pfx — он указан в idp/app-settings.json, в разделе SAML.Configurations[0].LocalIdentityProviderConfiguration.LocalCertificates[0].Password.

Полученное значение подставляется в idp_cert_fingerprint в шаге ниже.

3. Добавление 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: "Indeed AM SSO",
    args: {
      assertion_consumer_service_url: "https://gitlab.example.local:8443/users/auth/saml/callback",
      idp_cert_fingerprint: "<SHA1-отпечаток публичного сертификата IDP>",
      idp_sso_target_url: "https://<dns_idp>/am/idp/Account/SsoService",
      issuer: "https://gitlab.example.local:8443/users/auth/saml/metadata",
      name_identifier_format: "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress",
      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: ["Email"],
        name: ["Name"]
      }
    }
  }
]

Где:

  • idp_sso_target_url — адрес страницы входа Indeed AM IDP;
  • idp_cert_fingerprint — SHA1-отпечаток открытого сертификата IDP (получение см. выше);
  • issuer — Entity ID, под которым GitLab регистрируется на стороне IDP; должен совпадать с тем, что будет указано в app-settings.json и в МС;
  • certificate/private_key — сертификат из шага 1, которым GitLab подписывает AuthnRequest; сертификат нужно предварительно положить на сервер GitLab по указанному пути (например /etc/gitlab/ssl/saml/).

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

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

gitlab-ctl reconfigure

Если GitLab развёрнут в Docker и конфигурация задаётся через GITLAB_OMNIBUS_CONFIG в docker-compose.yml:

docker compose down
docker compose up -d

Настройка Indeed Identity Provider

1. Белый список SP

В файле .env в корне инсталляции AM добавить домен GitLab в переменную CUSTOM_SP_*:

CUSTOM_SP_1=gitlab.example.local:8443

2. Сертификат SP

Сертификаты для SAML на стороне AM хранятся на хосте по пути /opt/am/ssl/saml_certs/ — там же лежит idp.pfx и сертификаты остальных SP. Публичный сертификат, созданный в шаге 1 настройки GitLab, копируется туда же:

cp ~/gitlab-deploy/config/ssl/saml/gitlab-saml.crt /opt/am/ssl/saml_certs/gitlab-saml.crt

cd /opt/am
grep -E 'AM_UID|AM_GID' .env
chown <AM_UID>:<AM_GID> ssl/saml_certs/gitlab-saml.crt

Внутри контейнера idp эта директория смонтирована по пути /opt/access-manager/idp/certificates/ — именно этот путь указывается в app-settings.json.

3. app-settings.json

В idp/app-settings.json, в раздел Authentication.LoginFormats:

{
  "ServiceProvider": "https://gitlab.example.local:8443/users/auth/saml/metadata",
  "InLoginFormat": "Name",
  "OutLoginFormat": "PrincipalName"
}

В раздел Authentication.CustomAttributes:

{
  "ServiceProvider": "https://gitlab.example.local:8443/users/auth/saml/metadata",
  "Attributes": [
    { "Name": "Email", "UserNameFormat": "Email" },
    { "Name": "Name", "UserNameFormat": "Name" }
  ]
}

Атрибут Email GitLab использует как значение поля email при создании/сопоставлении пользователя — само имя атрибута (Email) не привязано к источнику значения жёстко, важно лишь, на какой ключ (email) он смапплен в attribute_statements на стороне GitLab (см. шаг 3 выше). Если у части пользователей mail в AD не заполнен, вместо UserNameFormat: "Email" можно использовать UserNameFormat: "PrincipalName" (UPN) — тогда атрибут можно оставить с именем Email либо переименовать в UID для наглядности, главное согласовать имя в app-settings.json и в attribute_statements GitLab. Например, при переименовании в UID:

app-settings.json:

{ "Name": "UID", "UserNameFormat": "PrincipalName" }

GitLab (attribute_statements):

attribute_statements: {
  email: ["UID"],
  name: ["Name"]
}

В раздел SAML.Configurations[0].PartnerServiceProviderConfigurations:

{
  "Name": "https://gitlab.example.local:8443/users/auth/saml/metadata",
  "Description": "GitLab",
  "WantAuthnRequestSigned": true,
  "SignSamlResponse": true,
  "SignAssertion": true,
  "EncryptAssertion": true,
  "AssertionConsumerServiceUrl": "https://gitlab.example.local:8443/users/auth/saml/callback",
  "ValidAssertionConsumerServiceUrls": [
    "https://gitlab.example.local:8443/users/auth/saml/callback"
  ],
  "PartnerCertificates": [
    { "FileName": "/opt/access-manager/idp/certificates/gitlab-saml.crt" }
  ]
}

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

cd /opt/am
docker compose down -v
docker compose up -d

5. Приложение в Management Console

Для регистрации Gitlab в качестве приложения выполните следующие шаги в Консоли Администратора:

  • Войдите в Консоль Администратора Indeed AM (https://<server_fqdn>/am/mc)
  • Перейдите в раздел Приложения → Создать приложение, введите название приложения и нажмите Создать

  • Перейдите в Политики → выберите нужную политику → Приложения → Добавить приложение → выберите созданное приложение → Добавить

Проверка

При нажатии на кнопку «Indeed AM SSO» на странице входа GitLab (/users/sign_in) происходит перенаправление на Indeed AM IDP. После успешной аутентификации пользователь возвращается в GitLab и входит под учётной записью, сопоставленной по email.

Логика сопоставления пользователя: GitLab ищет существующего пользователя по email из атрибута Email; при совпадении привязывает SAML-identity к найденной учётной записи; если пользователь не найден — создаёт нового автоматически.

Требования к атрибутам пользователя в AD

Атрибут Email в SAML-ответе формируется из значения mail в объекте пользователя AD (UserNameFormat: "Email" в CustomAttributes). Если у пользователя в AD поле mail не заполнено — атрибут Email в ответе будет пустым, и вход в GitLab не произойдёт: email обязателен для создания/сопоставления учётной записи GitLab, без него JIT-provisioning отработать не сможет.

Перед подключением новых пользователей к этому SP стоит убедиться, что у них заполнен mail в AD и что значение уникально (не совпадает с mail другого пользователя) — иначе возможны коллизии при сопоставлении по email на стороне GitLab.

Если mail в AD не заполнен или не ведётся стабильно, в качестве альтернативы можно использовать в атрибуте email значение UPN (UserNameFormat: "PrincipalName" вместо "Email"), как и для основного идентификатора — GitLab не проверяет источник значения, только то, что оно синтаксически похоже на email. При этом важно, чтобы у существующих в GitLab учётных записей поле email было заполнено этим же значением (UPN) — иначе привязка по email при первом SSO-входе не сработает и вместо входа в существующий аккаунт создастся новый.

Итого два рабочих варианта пары атрибутов:

  • Email + Name — атрибут email берётся из mail в AD (UserNameFormat: "Email"). Используется по умолчанию в этой инструкции.
  • UID + Name — атрибут email берётся из UPN (UserNameFormat: "PrincipalName"), в GitLab маппится как email: ["UID"]. Применяется, если mail в AD не заполнен.

Смешивать источники (часть атрибутов из mail, часть из UPN) не нужно — для конкретного SP выбирается один из двух вариантов целиком.

Атрибут Name не обязателен для входа — без него GitLab всё равно создаст пользователя, но подставит в отображаемое имя значение email/NameID вместо реального имени. Чтобы у новых пользователей сразу был корректный логин, рекомендуется держать оба атрибута (Email/UID и Name) в CustomAttributes, как указано в инструкции выше.

(0 голос(а))
Эта статья полезна
Эта статья бесполезна