4.3.6. Установка Avanpost FAM SelfService в ОС Linux

При наличии нескольких экземпляров Avanpost FAM возможно реализовать общий личный кабинет на основе опроса этих экземпляров. В данной статье рассмотрен вопрос настройки данного механизма посредством использования компонента SelfService.

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

• В сети существуют несколько экземпляров Avanpost FAM Server для настройки, далее именуемые соответственно FAM1 (Avanpost FAM Server экземпляр 1), FAM2 (Avanpost FAM Server экземпляр 1) и т.д.
• Выполнена синхронизация времени в ОС с сервером синхронизации времени.

• В ОС семейства Debian Linux должны быть установлены следующие программы:
  - openssl (программа управления сертификатами);
  - psql (CLI-клиент из состава PostgreSQL);
  - nginx (веб-сервер/прокси-сервер);
  - sudo (программа выполнения команд от имени суперпользователя).

Установка и настройка FAM SelfService

Для корректной работы фактора WebAuthn рекомендуется разворачивать Avanpost FAM SelfService поддомене Avanpost FAM (например, если FAM Server развернут на домене fam.avanpost.ru, то для FAM SelfService следует использовать selfservice.fam.avanpost.ru). 

Установка компонента SelfSevice осуществляется в следующей последовательности: 

1. Скачать и распаковать на рабочую машину актуальную версию Avanpost FAM SelfService из репозитория.
2. Создать пользователя idp, используя следующую команду:

   sudo useradd idp

3. Создать папку сервиса, используя следующую команду:

   sudo mkdir /opt/avanpost_selfservice

4. Распаковать архив, используя следующую команду:

   sudo tar -C /opt/avanpost_selfservice -xvzf /path_to_tar_file/avanpost_selfservice-1.0-4.linux.tar.gz

5. Перейти в папку avanpost_selfservice, используя команду:

   cd /opt/avanpost_selfservice/

6. Скопировать стандартный конфигурационный файл FAM SelfService, используя команду:

   cp config.selfservice.sample.toml config.selfservice.toml

7. Скопировать конфигурационный файл NATS-сервера, используя команду:

   cp config.selfservice.nats.sample.json config.selfservice.nats.json

8. Предоставить пользователю idp полные права на осуществление действий с данными файлами, используя команду:

   sudo chown -R idp:idp /opt/avanpost_selfservice

9. Создать файл сервиса FAM SelfService для дальнейшего автоматического запуска используя команду: 

   sudo nano /etc/systemd/system/selfservice.service

   [Unit]
   Description=SelfService
   [Service]
   WorkingDirectory=/opt/avanpost_selfservice
   ExecStart=/opt/avanpost_selfservice/selfservice_linux_amd64
   Restart=always
   RestartSec=10
   SyslogIdentifier=selfservice
   User=idp
   Environment="SSO_CFG=/opt/avanpost_selfservice/config.selfservice.toml"
   [Install]
   WantedBy=multi-user.target

10. При необходимости исправить параметры конфигурационного файла NATS-сервере config.selfservice.nats.json (подробнее о параметрах описано в приложении А), используя команду:

    sudo nano /opt/avanpost_selfservice/config.selfservice.nats.json

11. Скопировать закрытую часть сертификата (самоподписанный сертификат, создаваемый на стороне Avanpost FAM Server) для дальнейшего указания в параметре cert конфигурационного файла config.selfservice.toml.  

12. Отредактировать конфигурационный файл SelfService config.selfservice.toml в соответствии с таблицей (более подробно о настройке параметров описано в приложении Б). 

    Параметр	Значение
    cert	Имя и путь файла сертификата (в данном примере cert.pem).
    issuer	Скопировать параметр из конфигурационной файла FAM Server.
    baseUrl	Базовый URL-адрес, по которому переходит пользователь в личный кабинет (в данном примере http://self.avanpost.local/)
    authority	URL-адрес, по которому осуществляется аутентификация. Рекомендуется указать адрес из параметра baseUrl.
    clientId	Идентификатор OpenID-приложения из настроек Avanpost FAM Server (в данном примере используется remote-lk-client).
    serverCfgFile	Имя и путь файла конфигурации NATS-сервера.

13. Запустить SelfService, используя команды:

    sudo systemctl daemon-reload
    sudo systemctl enable selfservice
    sudo systemctl start selfservice

14. Создать файл nginx по пути  /etc/nginx/conf.d/self.conf, указав в нем параметры проксирования аналогично Avanpost FAM Server:

    sudo nano /etc/nginx/conf.d/self.conf

     server {
        listen        80;
        server_name   self.avanpost.local;
        location / {
            proxy_pass       http://127.0.0.1:4009;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header Host $host;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            add_header Content-Security-Policy "default-src 'self'; img-src 'self' data: https: *; style-src 'self' 'unsafe-inline' *; connect-src 'self' *; script-src 'self' 'unsafe-inline' https://idp.avanpost.local;";
    
        }
     }

15. Проверить конфигурацию Nginx:

    sudo nginx -t
    # nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
    # nginx: configuration file /etc/nginx/nginx.conf test is successful

16. Перезапустить Nginx:

    sudo systemctl restart nginx

17. Добавить в раздел [lk] конфигурационного файла FAM Server config.toml следующее:

    runAs = "nats"
    webauthnOrigin = "http://self.avanpost.local" #baseUrl SelfService

18.  Добавить в раздел [lk.nats] конфигурационного файла FAM Server config.toml следующее:

     connection = "nats://<IP Self Service>:4222"
     useTls = false
     #caCertPath = "cmd/selfservice/develop-cert-ca.pem"
     #clientCertPath = "cmd/selfservice/develop-cert-client.pem"
     #clientKeyPath = "cmd/selfservice/develop-key-client.pem"
     #username = "natsUser"
     #password = "password"

19. Из консоли машины с узлом FAM1 перезапустить FAM Server, используя команду:

    sudo systemctl restart idp

20. Открыть административную консоль главного узла FAM1 и зайти во вкладку создания приложения, нажав кнопку "Добавить приложение" режима "Приложения".
21. На этапе "Основные настройки" требуется ввести наименование и выбрать тип "OAuth/OpenID Connect" (более подробно процесс создания и управления приложениями описан в разделах Управление приложениями и Управление OIDC-приложениями).
22. На этапе "Настройки интеграции" заполнить указанные поля в соответствии с таблицей (назначение прочих параметров описано в Шаг 2. Настройки интеграции для OIDC-приложений).

    Параметр	Значение
    ID synonym	remote-lk-client Перед указанием параметра ID synonym требуется поставить галочку в чекбоксе "Публичный" для возможности использования ID Synonym вместо параметра Client ID при использовании протокола OpenID Connect.
    BaseUrl	Должен соответствовать параметру baseUrl из конфигурационного файла (по умолчанию, http://self.avanpost.local).
    Redirect URls	Должен соответствовать параметру callbackUrl из конфигурационного файла (по умолчанию, http://self.avanpost.local/callback).
    Backchannel-logout URI	Должен соответствовать параметру baseUrl из конфигурационного файла (по умолчанию, http://self.avanpost.local/logout).
    Audience	remote-lk-client
    Allowed Grant Types	Обязательно включить grant type "Autorization code" (рекомендуется, но не обязательно включить "Refresh Token").
    Access Token type	Выбрать "JSON Web Token".

23. На этапе "Настройки аутентификации" выбрать факторы аутентификации приложения, установив переключатели напротив тех или иных факторов (более подробно описано в Шаг 3. Настройки аутентификации для OIDC-приложения).
24. На этапе "Завершение" следует сохранить приложение, делая его активным сразу после создания (более подробно в Шаг 4. Завершение для OIDC-приложения).
25. Проверить корректность настройки:
    1. Открыть в браузере адрес http://self.avanpost.local, по которому выполняется запрос к Avanpost FAM.
    2. Удостовериться, что осуществляется вход в личный кабинет.

Обновление FAM SelfService

Обновление компонента Avanpost FAM SelfService следует проводить следующим образом:

1. Скачать и распаковать на рабочую машину обновленную версию Avanpost FAM SelfService из репозитория.
2. Остановить сервисы FAM SelfService, используя команду:

   sudo systemctl stop selfservice.service

3. Удалить папку /public, используя команду:

   sudo rm -r /opt/avanpost_selfservice/public/

4. Обновить компонент, используя скаченный файл, при помощи команды:

   tar -C /opt/avanpost_selfservice -xvzf /path_to_tar_file/avanpost_selfservice-*.linux.tar.gz

5. Запустить FAM SelfService, используя команду:

   sudo systemctl start selfservice.service

Приложение A. Параметры конфигурационного файла NATS-сервера config.selfservice.nats.sample.json

В конфигурационном файле NATS-сервера допускается настройка дополнительных параметров согласно документации https://docs.nats.io/running-a-nats-service/configuration.

Приложение Б. Параметры конфигурационного файла FAM Self Service config.selfservice.sample.json 

Приложение В. Пример конфигурационного файла 

 cert = 'cert.pem'
 public_dir = 'public/'
 
[templates]
 templates = 'public/templates/default'
 localization = 'public/templates/localization'
 saml_response = 'public/templates/saml-response.html'
 oauth2_form_post_template = 'public/templates/oauth2-formpost-response.html'
 oauth2_error_template = 'public/templates/oauth2-error-response.html'

[lk]
 issuer = 'fam.avanpost.local'
 baseUrl = 'http://self.avanpost.local'
 authority = 'http://self.avanpost.local'
 port = 4009
 host = '127.0.0.1'
 path = '/'
 verifyPermissions = true
 idleTimeoutInMinutes = 50
 dir = './public/spa'
 clientId = 'remote-lk-client'
 natsTimeoutSec = 30
 
[nats]
 # omit or empty for embedded NATS
 connection = 'nats://127.0.0.1:4222'
 embedded = true
 serverCfgFile = 'config.selfservice.nats.json'
 #useTls = false
 #caCertPath = ''
 #certPath = ''
 #keyPath = ''
 #clientCertPath = ''
 #clientKeyPath = ''

 [cluster]
 enabled = false

 [cluster.self]
 id = 'some.1'

[[cluster.nodes]]
 id = 'other.2'

[[cluster.nodes]]
 id = 'another.3'
                                   

Приложение Г. Endpoint'ы Avanpost FAM SelfService

Endpoint'ы,  использующиеся для работы компонента Avanpost FAM SelfService:

http://self.avanpost.local/health/ready

Приложение Д. Выпуск сертификатов для mTLS-соединения

Для повышения безопасности взаимодействия между компонентами платформы может использоваться mTLS (Mutual TLS), представляющий собой расширение протокола TLS, при котором клиент и сервер предъявляют и проверяют цифровые сертификаты для установления доверия. В отличие от обычного HTTPS, где только сервер предоставляет сертификат, при mTLS клиент также должен иметь действительный сертификат, подписанный доверенным центром сертификации (ЦС).

Выпуск сертификатов для mTLS-соединения выполняется следующим образом:

1. Создать корневой сертификат для центра сертификации (CA):
   1. Сгенерировать закрытый ключ для корневого центра сертификации (CA) при помощи команды:

      openssl genrsa -out server.key 2048

   2. Сгенерировать сертификат root CA при помощи команды:

      openssl req -x509 -new -nodes -key CA.key -sha256 -days 3650 -out CA.pem

2. Создать клиентский сертификат:

   1. Создать закрытый RSA-ключ для Client CA, используя команду:

      openssl genrsa -out client.key 4096
      

   2. Создать клиентский CSR-файл (Client CSR-файл) посредством команды:

      openssl req -new -key client.key -out client.csr

   3. Создать файл client.ext, содержащий конфигурацию расширений X.509 для клиентского сертификата (более подробно в документации OpenSSL):

      Пример конфигурационного файла client.ext

      authorityKeyIdentifier=keyid,issuer
      basicConstraints=CA:FALSE
      keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
      extendedKeyUsage = clientAuth

      Параметр	Значение
      authorityKeyIdentifier	Идентификатор центра сертификации (CA), подписавшего сертификат (ID ключа и имя).
      basicConstraints	Указывает, может ли сертификат использоваться как центр сертификации (в данном случае указывается сертификат конечного субъекта, который не может выступать как CA).
      keyUsage	Определяет разрешённые криптографические операции: digitalSignature— подпись (например, TLS handshake); nonRepudiation— защита от отказа; keyEncipherment— шифрование ключей (для RSA); dataEncipherment— шифрование данных. Как для клиента, так и для сервера не стоит использовать значения keyCertSign (разрешение подписывать другие сертификаты) и cRLSign (разрешение подписывать списки отзыва сертификатов). Данные права ограничены только доверенными центрами сертификации (CA).
      extendedKeyUsage	Назначение сертификата (значение clientAuth  указывает, что сертификат предназначен для аутентификации клиента в TLS/mTLS).

   4. Создать подписанный сертификат Client CA:

      openssl x509 -req -in client.csr -CA CA.pem -CAkey CA.key -CAcreateserial -out client.crt -days 2000 -sha256 -extfile client.ext

3. Создать серверный сертификат:
   1. Сгенерировать закрытый ключ Server CA при помощи команды:

      openssl genrsa -out server.key 2048

   2. Создать серверный CSR-файл (Server CSR-файл) посредством команды:

      openssl req -new -key server.key -out server.csr

   3. Создать файл server.ext, содержащий конфигурацию расширений X.509 для клиентского сертификата (более подробно в документации OpenSSL):
      Пример конфигурационного файла server.ext

      authorityKeyIdentifier=keyid,issuer
      basicConstraints=CA:FALSE
      keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
      subjectAltName = @alt_names
      
      [alt_names]
      DNS.1 = hellfish.test
      DNS.2 = test.test
      IP.1 = 192.168.0.1
      IP.2 = 192.168.0.2

      Параметр	Значение
      authorityKeyIdentifier	Идентификатор центра сертификации (CA), подписавшего сертификат (ID ключа и имя).
      basicConstraints	Указывает, может ли сертификат использоваться как центр сертификации (в данном случае указывается сертификат конечного субъекта, который не может выступать как CA).
      keyUsage	Определяет разрешённые криптографические операции: digitalSignature— подпись (например, TLS handshake); nonRepudiation— защита от отказа; keyEncipherment— шифрование ключей (для RSA); dataEncipherment— шифрование данных.
      subjectAltName	Указывает имя секции, в которой находятся альтернативные наименования сервера
      [alt_names]	Секция, в которой содержатся альтернативные имена сервера (в приведенном примере – домены и IP-адреса).

   4. Создать подписанный сертификата сервера, используя команду:

      openssl x509 -req -in server.csr -CA CA.pem -CAkey CA.key
      -CAcreateserial -out server.crt -days 2000 -sha256 -extfile server.ext