Перейти к содержанию

Настройка интеграций по протоколам

В Системе в разделе Сервисы необходимо добавить сервис для интеграции, указать наименование, протокол, параметры и адрес с которого будет производиться запрос на вход.

Подключение к Системе по протоколу CAS

В зависимости от подключаемого сервиса может понадобиться настройка Атрибутов сервисов

Информация

Для примеров используется настроенный атрибут сервисов со следующим содержимым 

Имя атрибута - cn, Поле источник - username
Имя атрибута - memberOf, Поле источник - groups

Подключение redmine

Для подключения redmine необходимо установить модуль Redmine Omniauth plugin:

  • клонируем плагин в директорию /usr/src/redmine/plugins 
    1
    git clone https://github.com/jbbarth/redmine_omniauth_cas.git
  • копируем файл /usr/src/redmine/plugins/redmine_omniauth_cas/initializersredmine_omniauth_cas.rb в контейнер с redmine 
    1
    docker cp redmine_omniauth_cas.rb redmine:/usr/src/redmine/config/initializers/
  • перезапускаем redmine

В redmine, в настройках подключенного модуля (Администрирование - Модули) в качестве "CAS server URL" указываем путь до контейнера sso, например: 

1
http://localhost:8082/auth

Подключение jenkins

Для подключения jenkins необходимо установить плагин "cas-plugin". В jenkins в настройках плагина (находятся в "Глобальные настройки безопасности") необходимо заполнить:

  • "CAS server URL" указать путь до контейнера sso, например, http://localhost:8082/auth
  • "CAS Protocol" выбрать "CAS 3.0"
  • "Авторизация" - "Role-Based Strategy"

Далее в расширенных настройках заполнить:

  • "Roles Attribute(s)" - "memberOf"
  • "Full Name Attribute" - "displayName"
  • "Email Attribute" - "email"

Остальные параметры заполнять не нужно.

Подключение gitlab

Для подключения gitlab необходимо внести изменения в файл настроек gitlab.rb:

Информация

Не работает начиная с версии 16.0!

gitlab.rb
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
gitlab_rails['omniauth_providers'] = [
    {
        "name"=> "cas3",
        "label"=> "cas",
        "args"=> {
            "url"=> 'http://localhost:8082/auth',
            "login_url"=> '/cas/login',
            "service_validate_url"=> '/cas/p3/serviceValidate',
            "logout_url"=> '/cas/logout',
            "uid_field"=> 'cn'
        }
    }
  ]

Подключение к Системе по протоколу OpenId Connect

Информация

Важно понимать,что OpenID Connect протокол требует TLS (HTTPS) взаимодействия. Поэтому Единая точка доступа должна быть запущена в режиме https

Предупреждение

Если Единая точка доступа работает с самоподписанным сертификатом, то предварительно нужно настроить доверие сервиса к этому сертификату. Если сервис работает с самоподписанным сертификатом, то также необходимо настроить доверие Единая точка доступа к сертификату сервера

Подключение ownCloud

Для подключения ownCloud необходимо установить из маркета приложение OpenID Connect, либо установить его через консоль: 

occ app:enable openidconnect

На стороне сервера owncloud настроить config.php, например:

config.php
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
  'http.cookie.samesite' => 'Lax',

  'openid-connect' => [
    // путь до протокола OIDC
    'provider-url' => 'https://sso.local/auth/oidc',
    //
    'client-id' => '...',
    'client-secret' => '...',
    // запрашиваемые атрибуты (указываются в Системе Допуск)
    'scopes' => ['openid', 'owncloud'],
    //'auto-provision' => ['enabled' => true] необходимо для автоматического создания пользователей, если не нужно поставьте ['enabled' => false]
    'auto-provision' => [
      'enabled' => true,
      'email-claim' => 'email',
      // обновляет информацию о пользователе
      'update' => [
        'enabled' => true,
      ],
    ],
    'search-attribute' => 'username', // по умолчанию равно email
    'claim-mapping' => [
      'name' => 'display_name',
    ],
  ],

Более подробное описание настроек см. openidconnect

В Системе в разделе Атрибуты сервисов необходимо создать группу атрибутов owncloud со следующими атрибутами: 

display_name display_name
email        email
username     username

В Системе в разделе Сервисы необходимо указать настройки:

  • В поле Разрешенные типы предоставления токенов (grant types) - Authorization code

  • В поле Разрешенные типы ответов (response types) - code

  • В поле Секретный ключ клиента - значение 'client-secret' из owncloud

  • В поле Атрибуты - выбрать раннее созданную группу атрибутов owncloud

Подключение Vaultwarden

Для подключения Vaultwarden необходимо в UI Vaultwarden Admin перейти в пункт OpenID connect SSO settings и настроить параметры:

  • Client ID - значение из ID клиента
  • Client Key- значение из Секретный ключ клиента
  • Authority Server - https://sso.local/auth/oidc
  • Authorization request scopes - preferred_username email
  • CallBack Path - оставить стандартное значение

Более подробное описание настроек см. Vaultwarden

В Системе в разделе Сервисы необходимо создать соответствующий сервис со следующими настройками:

  • В поле URL-адрес переадресации - ввести значение из CallBack Path

  • В поле Атрибуты - preferred_username и email (Перед этим нужно создать во вкладке Атрибуты сервисов атрибут preferred_username со значением preferred_username - display_name)

  • В поле ID клиента - ввести название клиента, например vaultwarden

  • В поле Секретный ключ клиента - ввести секретный ключ клиента (нужно придумать или сгенерировать самостоятельно)

  • В поле Разрешенные типы предоставления токенов (grant types) - Authorization code

  • В поле Разрешенные типы ответов (response types) - code

Информация

Vaultwarden при создании пользователя через SSO будет брать значение имени пользователя из атрибута preferred_username, а значение email соответственно из атрибута email

Предупреждение

Для создания пользователя в Vaultwarden email этого пользователя должен быть подтверждён - иметь тег VERIFIED

Подключение к Системе по протоколу SAML

При первом запуске Системы создаются ключи и сертификат для доступа по протоколу SAML. Если изменится параметр sso.url при перезапуске Системы, то сертификат SAML обновится и настроенные подключения по SAML перестанут работать. Чтобы они снова заработали, нужно будет обновить SHA-1 отпечаток сертификата подписи метаданных SAML на стороне настроенных сервисов.

Подключение gitlab

Для подключения gitlab необходимо внести изменения в файл настроек gitlab.rb:

gitlab.rb
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
gitlab_rails['omniauth_providers'] = [
  {
    name: "saml",
    label: "Provider name", # optional label for login button, defaults to "Saml"
    args: {
      assertion_consumer_service_url: "http://your-url-here/users/auth/saml/callback",
      idp_cert_fingerprint: "your-idp_cert_fingerprint-here",
      idp_sso_target_url: "https://your-url-here/cas/idp/profile/SAML2/Redirect/SSO",
      issuer: "http://your-url-here",
      name_identifier_format: "urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"
    }
  }
]

Для получения значения idp_cert_fingerprint требуется перейти в настройки на вкладку Общие в поле SHA-1 отпечаток сертификата подписи метаданных SAML.

Примечание

В случае, если параметр sso.url будет изменён, то SHA-1 отпечаток сертификата подписи метаданных SAML обновится и нужно будет прописать новое значение idp_cert_fingerprint в уже настроенном сервисе

Далее в Системе:

  • В разделе Атрибуты добавить запись gitlab для группы атрибутов gitlab, указав в качестве протокола SAML 2.0 и заполнив список атрибутов (в качестве полей источников выбрать email, first_name, family_name, display_name)
  • В разделе Сервисы необходимо указать в Разрешения значение gitlab, созданную ранее в п. 1

Примечание

В случае, если время в Системе и на сервере Gitlab будет отличаться, возникнет ошибка: 

Could not authenticate you from SAML because 
"Current time is earlier than notbefore condition (2019-03-25 <current time> utc < 2019-03-25 <current time> utc)"
Небольшой сдвиг по времени допустим при использовании параметра allowed_clock_drift. При проверке указанное в параметре значение добавляется к текущему времени.
gitlab.rb
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
gitlab_rails['omniauth_providers'] = [
  {
    name: "saml",
    label: "Provider name", # optional label for login button, defaults to "Saml"
    args: {
      assertion_consumer_service_url: "http://your-url-here/users/auth/saml/callback",
      idp_cert_fingerprint: "your-idp_cert_fingerprint-here",
      idp_sso_target_url: "https://your-url-here/cas/idp/profile/SAML2/Redirect/SSO",
      issuer: "http://your-url-here",
      name_identifier_format: "urn:oasis:names:tc:SAML:2.0:nameid-format:persistent",
      allowed_clock_drift: 1 # for one second clock drift
    }
  }
]

Примечание

Чтобы изменения, внесённые в gitlab.rb вступили в силу, необходимо выполнить: 

1
sudo gitlab-ctl reconfigure

Подключение Jenkins

Для подключения Jenkins необходимо установить плагин SAML, после установки зайти в настройки безопасности Jenkins (http://jenkins.local/manage/configureSecurity/) и там заполнить:

IdP Metadata URL   - https://sso.local/auth/idp/metadata
Username Attribute - username
Email Attribute    - email
Logout URL         - https://sso.local/auth/client/logout

Далее в Системе:

  • В разделе Атрибуты сервисов добавить запись jenkins, указав в качестве протокола SAML 2.0 и заполнив список атрибутов (в качестве полей источников выбрать username, email)
  • В разделе Сервисы создать сервис заполнив поля: 
    Идентификатор объекта SAML - http://jenkins.local.*
Путь к метаданным          - http://jenkins.local/securityRealm/metadata (В UI jenkins нажать Service Provider Metadata)

Примечание

Путь к метаданным можно найти В UI jenkins - в настройках SAML нажать на ссылку Service Provider Metadata При копировании этого пути нужно убрать из него /manage, например из http://jenkins.local/manage/securityRealm/metadata сделать http://jenkins.local/securityRealm/metadata