История изменений

Инструкции по обновлению#

Важно

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

Внимание

В случае СУБД PostgreSQL нужно проверить по актуальному файлу resources.zip, какие в нем появились новые DDL-скрипты, и выполнить их, если такие изменения отсутствуют в текущей схеме БД.

5.22.5 -> 5.23#

  1. В случае использования СУБД PostgreSQL применить скрипт: 022-5.23.0.sql.

  2. На серверах с Blitz Identity Provider установить JDK 11. Определить актуальное значение JAVA_HOME.

  3. В файлах конфигурации /etc/default/blitz-* указать новое значение параметра JAVA_HOME.

  4. Установить blitz-5.23.bin.

  5. Теперь Blitz Identity Provider позволяет сохранять группы пользователя в организации, полученные от внешнего поставщика ЕСИА, и передавать их по запросу в утверждениях токена идентификации. Для того чтобы задействовать данную возможность, необходимо выполнить следующие действия:

    1. Открыть файл конфигурации /usr/share/identityblitz/blitz-config/blitz.conf.

    2. В секции blitz.prod.local.idp.federation.points.esia.org.scopes добавить разрешение на получение данных о группах пользователя http://esia.gosuslugi.ru/org_grps.

      "org" : {
   ...,
   "scopes" : [
        ...,
        "http://esia.gosuslugi.ru/org_grps"
   ]
},
...

      В результате группы пользователя будут сохраняться в базе данных в атрибуте org.groupNames.

    3. Для передачи групп пользователя из атрибута org.groupNames в утверждение (claim) токена идентификации, внести изменения в секцию blitz.prod.local.idp.federation.points.esia.claims. Ниже показан пример передачи параметра в утверждение с именем org_groups.

      "claims" : [
   {
    "name" : "org_groups",
    "value" : "org.groupNames"
   }
]

  6. При наличии настроек провести миграцию имен в новый формат в блоке blitz.prod.local.idp.internal-store-jdbc.pool:

    • max_total_conn -> maxTotalConn,

    • max_idle_conn -> maxIdleConn,

    • min_idle_conn -> minIdleConn,

    • max_wait_conn_ms -> maxWaitConnMs.

    В тот же блок добавить параметры расширенной настройки пула соединений.

    Пример настроек после редактирования:

    "internal-store-jdbc" : {
     "pool" : {
         "maxIdleConn" : 10,
         "maxTotalConn" : 20,
         "maxWaitConnMs" : 30000,
         "minIdleConn" : 7,
         "testOnBorrow" : false,
         "testOnCreate" : false,
         "testOnReturn" : false,
         "testWhileIdle" : true,
         "timeBetweenEvictionRunsMillis" : 30000,
         "validationQuery" : ""
     }
}

  7. При необходимости задействовать следующие новые возможности:

    • Потребовать при восстановлении доступа подтверждение по второму фактору только в случае, если для пользователя включен хотя бы один метод из списка методов дополнительной проверки (Необходимость дополнительной проверки -> Требовать, если доступна).

    • Добавить параметры obj_type (тип пользователя) и roles (типы ролей пользователя) в вызов сервиса аутентификации ЕСИА.

    • Добавить возможность регистрации пользователя во внешнем поставщике при входе через него.

    • Настроить отображение в консоли и Личном кабинете информации о привязанных внешних аккаунтах пользователя. Настройку можно сделать в консоли, посредством процедуры на Java и через API.

    • В процедуру обработки запросов RADIUS добавить функции, позволяющие выбирать способ подтверждения входа и отображать краткую инструкцию по способам подтверждения.

    • Настроить интервал считывания глобальной конфигурации кластера Couchbase Server.

5.21.1 -> 5.22.5#

  1. Установить blitz-5.22.5.bin.

  2. При необходимости задействовать новые возможности:

    • Настроить первичный вход по электронной почте.

    • Выбрать хранилище учетных записей для первичного входа по SMS.

    • Настроить аутентификацию с ЕСИА с использованием КриптоПро JCP.

    • Отключить запоминание логина пользователя для будущих входов.

    • Добавить в процедуру входа вызов сброса сессии.

    • Добавить в процедуру входа кастомные ошибки.

    • Настроить метки приложений и задействовать их в процедуре входа.

    • Кастомизировать логотип и CSS-оформление Личного кабинета.

    • Настроить получение признака isIdentified из Tinkoff ID.

  3. Если профили первого и второго фактора для методов входа по коду из SMS/push, с помощью электронной почты или ключа безопасности ранее были объединены, необходимо открыть файл конфигурации /usr/share/identityblitz/blitz-config/blitz.conf и разделить профили вручную в секциях email, sms, webAuthn раздела idp.login.methods. В настройки второго фактора не нужно переносить параметры bind, storeRouter, factorCoverage (только для webAuthn).

    Пример разделения профилей для входа с помощью электронной почты#
    "email": {
    "profiles": {
        "1": {
            "attr": "${email-}",
            "bind": [
                [
                    {
                        "attr": "email",
                        "value": "${login}"
                    }
                ]
            ],
            "psw-expire-time-sec": 300,
            "psw-length": 6,
            "psw-max-attempts": 3,
            "tempLockAfter": 100,
            "tempLockForMin": 1,
            "storeRouter": {}
        },
        "2": {
            "attr": "${email-}",
            "psw-expire-time-sec": 300,
            "psw-length": 6,
            "psw-max-attempts": 3,
            "tempLockAfter": 100,
            "tempLockForMin": 1
        }
    }
}
    Пример разделения профилей для входа по коду из SMS/push#
    "sms": {
    "profiles": {
        "1": {
            "bind": [
                [
                    {
                        "attr": "personal_mobile",
                        "value": "${login}"
                    }
                ],
                [
                    {
                        "attr": "uid",
                        "value": "${login}"
                    }
                ]
            ],
            "channels": [
                {
                    "attr": "${personal_mobile-}${uid-}",
                    "type": "push"
                },
                {
                    "attr": "${personal_mobile-}",
                    "type": "sms"
                }
            ],
            "psw-expire-time-sec": 30,
            "psw-length": 2,
            "psw-max-attempts": 3,
            "tempLockAfter": 10,
            "tempLockForMin": 15,
            "storeRouter": {}
        },
        "2": {
            "channels": [
                {
                    "attr": "${personal_mobile-}${uid-}",
                    "type": "push"
                },
                {
                    "attr": "${personal_mobile-}",
                    "type": "sms"
                }
            ],
            "psw-expire-time-sec": 30,
            "psw-length": 2,
            "psw-max-attempts": 3,
            "tempLockAfter": 10,
            "tempLockForMin": 15
        }
    }
}
    Пример разделения профилей для входа с помощью ключа безопасности#
    "webAuthn" : {
    "profiles" : {
        "1" : {
            "alwaysApplicable" : true,
            "bind" : [
                [
                    {
                        "attr" : "surname",
                        "value" : "mysurname"
                    }
                ]
            ],
            "factorCoverage" : 2,
            "storeRouter" : {
                "cases" : [
                    {
                        "matchers" : [
                            {
                                "not" : false,
                                "pattern" : "myemail@m.ru",
                                "source" : "${login}"
                            }
                        ],
                        "result" : "dldap01"
                    }
                ]
            },
            "trustedAttestationModes" : [
                "FULL",
                "FULL_NO_ROOT",
                "SELF"
            ]
        },
        "2" : {
            "alwaysApplicable" : false,
            "trustedAttestationModes" : [
                "FULL",
                "FULL_NO_ROOT",
                "SELF"
            ]
        }
    }
}

5.20.0 -> 5.21.0 (5.21.1)#

  1. В случае использования СУБД PostgreSQL применить скрипт: 021-5.21.0.sql.

  2. Установить blitz-5.21.0.bin.

  3. При необходимости задействовать новую возможность: настроить доступ к сетевым службам по протоколу RADIUS.

  4. В новой версии изменился установленный по умолчанию идентификатор поставщика идентификации issuer, а также URL сервиса OpenID Connect Discovery:

    • В предыдущих версиях issuer соответствовал значению domain, где domain – внешнее имя домена системы. Теперь issuer формируется как domain/context, где context – URL-путь, на котором функционирует Blitz Identity Provider.

    • В предыдущих версиях сервис OIDC Discovery располагался по адресу https://<issuer>/<context>/oauth/.well-known/openid-configuration. Теперь адрес формируется как https://<issuer>/.well-known/openid-configuration.

    С учетом вышесказанного после установки обновления сервис OIDC Discovery автоматически переместится на адрес https://<domain>/<context>/.well-known/openid-configuration.

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

    1. Не менять настройки приложений, но явно указать значение issuer в секции blitz.prod.local.idp.net файла конфигурации /usr/share/identityblitz/blitz-config/blitz.conf как всë, что стоит перед /.well-known/openid-configuration. Это позволит избежать лишних редиректов при функционировании системы.

      Внимание

      Решение не рекомендуется в долгосрочной перспективе.

      "net" : {
   "domain" : "demo.idblitz.ru",
   "issuer" : "demo.idblitz.ru/blitz/oauth",
   ...
},
...

    2. Рекомендуется Привести настройки своей системы и подключенных приложений в соответствие с новыми правилами, указав в них значение адреса OIDC Discovery как https://<domain>/<context>/.well-known/openid-configuration.

5.18.0 -> 5.20.0#

  1. В случае использования СУБД PostgreSQL применить скрипт: 020-5.20.0.sql.

  2. Установить blitz-5.20.0.bin.

  3. При необходимости настроить новые способы аутентификации:

  4. При необходимости задействовать новые возможности кастомизации работы с помощью программирования на Java:

5.16.2 -> 5.18.0#

  1. В случае использования СУБД PostgreSQL применить скрипты:

    1. 018-5.17.0.sql

    2. 019-5.18.0.sql

  2. Найти в конфигурационном файле blitz.conf блок настроек blitz.prod.local.idp.provisioning.recovery. Внести в блок следующие изменения:

    1. Переименовать настройку security-question в system-security-questions.

    2. Создать блок factor2 и перенести в него целиком секцию methods с содержимым. Удалить исходную секцию methods.

    3. В блоке factor2 установить "mode" :  "by_user_required_factor".

    Пример блока после редактирования#
    "recovery" : {
    "dropInactivityLock" : true,
    "factor2" : {
        "methods" : [
            "email",
            "sms",
            "totp"
        ],
        "mode" : "by_user_required_factor"
    },
    "recovery-contacts" : [
        "phone_number",
        "email"
    ],
    "search-attrs" : [
        "email",
        "phone_number"
    ],
    "system-security-questions" : {
        "attrs" : [
            "family_name"
        ]
    }
}

  3. Установить blitz-5.18.0.bin.

5.15.x -> 5.16.x#

  1. В настройках nginx закрыть доступ на адреса /blitz/metrics из внешних сетей:

    location /blitz/metrics {
    return 404;
}

  2. При использовании для приложений особых bundle с помощью lang-variant (опциональное поле lang-variant в настройках приложения) нужно все варианты языка прописать в настройку lang в blitz.conf в настройку lang-variant.

    Пример:

    "lang": {
    "ignore-browser": false,
    "lang-variants": ["12345", "12346"], // this field
    "languages": ["ru","en"],
    "portal-lang-cookie": {
        "domain": ".identityblitz.ru",
        "name": "portal_lang"
    }
}

  3. Установить новый blitz.bin.

  4. При необходимости настроить сбор метрик функционирования в Prometheus через непосредственное обращение к /blitz/metrics по внутренним адресам серверов приложений.

  5. При необходимости настроить хранение настроек приложений в отдельных файлах.

5.14.0 -> 5.15.x#

  1. В случае использования СУБД PostgreSQL применить скрипты:

    1. 017-5.15.0.sql

  2. Установить новый blitz.bin.

5.11.x -> 5.14.0#

  1. В случае использования СУБД PostgreSQL применить скрипты:

    1. 015-5.12.0.sql,

    2. 016-5.13.0.sql

  2. Установить новый blitz.bin.

  3. В разделе «Внешний вид» проверить, что для всех шаблонов в поле «Название шаблона» задано уникальное имя. Если есть несколько шаблонов с одинаковым названием, то переименовать их.

  4. Для каждого настроенного внешнего поставщика идентификации в новом блоке «Выбор пользователя» заполнить значения настроек «Имя пользователя» и «Идентификатор пользователя». Пример заполнения:

    • Имя пользователя – ${given_name-} ${family_name-}

    • Идентификатор пользователя – ${email&maskInMiddle(4,8)}

    Настройка используется в процессе привязки пользователя при первом входе через внешний поставщик идентификации. На основе настройки пользователю показывается карточка найденной для привязки учетной записи в Blitz Identity Provider, соответствующей учетной записи внешнего поставщика идентификации.

  5. Проверить функции входа через внешние поставщики идентификации, если внешний вид экранов привязки при входе будет нарушен, то скорректировать используемые темы внешнего вида.

  6. Корректировка настроек в конфигурационном файле console.conf:

    1. Если используется вход в консоль управления по логину/паролю, то в console.conf добавить настройку roleClaim с пустым значением:

    Пример:

    {
"login" : {
    "fp" : {

    ...
    "subjectClaim" : "sub",
    "roleClaim" : "",
    ...
    },
    "mode" : "credentials"
}
}

    1. Если используется функция входа в консоль управления через SSO, то в console.conf в блок login.fp добавить настройку roleClaim. В качестве значения указать имя атрибута из id_token, в котором передается роль администратора (обычные названия ролей: root, security, sysadmin, app_admin, ui_admin, support, берутся из файла настроек credentials из roles.name). Настроить, чтобы внешняя IDP передавала атрибут с ролью. Атрибут может быть текстовым (String) – тогда передается одна роль, или массивом строк (ArrayOfString), тогда можно передавать множество ролей.

    Пример:

    {
"login" : {
    "fp" : {

    ...
    "subjectClaim" : "sub",
    "roleClaim" : "SOME_CLAIM_NAME",
    ...
    },
    "mode" : "sso"
}
}

    Из меню “Администраторы” консоли можно удалить тех пользователей-админов, которые входят только через внешний SSO-вход.

5.10.0 -> 5.11.x#

  1. В случае использования СУБД PostgreSQL применить скрипты 000-service-tasks.sql, 013-tasks.sql, 014-sec_ch_ua.sql.

  2. Проверить нестандартные строчки в custom_messages. Если в строчках с текстами писем используется функция $[device.mkey&dic(dics.devices)], то заменить ее на $[device.mkey&dic(dics.devices,os.ver)].

  3. Установить новый blitz.bin.

  4. В файле play.conf скорректировать настройки подключения к memcached – добавить operationTimeout, timeoutExceptionthreshold, maxReconnectDelay:

    • operationTimeout – время ожидания выполнения запроса к memcached в мс;

    • timeoutExceptionThreshold – количество попыток выполнения запроса, после которых узел считается не доступным;

    • maxReconectDelay – интервал между попытками установить соединение с узлом в секундах.

    Пример конфига с добавленными настройками с рекомендуемыми значениями:

    "memcached" : {
"operationTimeout" : 1000,
"timeoutExceptionThreshold" : 1,
"maxReconnectDelay" : 10,
"servers" : [
    …
]
}

  5. В случае использования СУБД PostgreSQL при необходимости переключить обработку задач с брокера RabbitMQ на брокер jdbc (это можно сделать если RabbitMQ больше ни для чего не используется и есть желание отказаться от его дальнейшего использования). Брокер jdbc рекомендуется использовать только в средах с небольшой нагрузкой.

    Для настройки использования брокера jdbc необходимо:

    • Проверить, что в блоке настроек stores в файле blitz.conf задана настройка default-type в значении jdbc:

    "stores" : {
"default-type" : "jdbc"
},

    • В файл blitz.conf в блоке tasks скорректировать настройки брокера следующим образом:

    "tasks" : {
"broker-type" : "task-store",
"executionRules" : [
    {
    "maxAttempts" : 2,
    "queue" : "blitz-tasks",
    "redeliveryDelayInSec" : 60
    }
],
"queues" : [
    {
    "dequeueBatchSize" : 10,
    "dequeuePeriodInSec" : 30,
    "executorPoolSize" : 5,
    "name" : "blitz-tasks"
    }
]
}

    • Серверу, выполняющему обработку задач, добавить параметр запуска akka.coordinated-shutdown.phases.service-stop.timeout в значении 30s:

    Dakka.coordinated-shutdown.phases.service-stop.timeout=30s