Хранилища и базы#

Хранение объектов в Couchbase Server#

Можно переназначить внутренние хранилища (buckets) Blitz Identity Provider в СУБД Couchbase Server, используемые для хранения данных. Предусмотрена возможность для следующих наборов данных указать необходимость использования иных хранилищ (buckets), чем стандартно используемые.

Для настройки иных хранилищ (buckets) нужно в блоке blitz.prod.local.idp.internal-store-cb добавить настройки:

buckets – перечисление используемых хранилищ (buckets), в случае если отличаются от стандартных;
bucketsMapping – переопределение стандартных размещений наборов данных на размещение в других хранилищах.

Пример настройки в конфигурационном файле представлен ниже. В результате набор данных acl размещается в хранилище users, а clt и iat – в apps. По умолчанию все три набора данных записывались в хранилище oauth.

"internal-store-cb" : {
  …
  "buckets" : {
    ["users", "oauth", "audit", "builtin_idstore", "ctxs"]
  },
  "bucketsMapping" : {
    "acl" : "users",
    "clt" : "apps",
    "iat" : "apps"
  },
  …
}

Считывание конфигурации кластера Couchbase Server#

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

Откройте файл конфигурации /usr/share/identityblitz/blitz-config/blitz.conf.
В секции blitz.prod.local.idp.internal-store-cb.ioConf задайте значение параметра configPollInterval в миллисекундах.
```
"internal-store-cb" : {
    "ioConf" : {
        "configPollInterval" : 2500
    },
    ...,
}
```

Время хранения объектов#

Можно настроить для данных аудита ограничение по сроку хранения записей в базе данных (по умолчанию записи хранятся бессрочно). Для этого в блоке blitz.prod.local.idp.internal-store-cb нужно добавить настройку ttlMapping с указанием doc_type записи (aud) и времени хранения в секундах.

Пример настройки (время хранения аудита ограничено до 90 суток):

"internal-store-cb": {
  …
  "ttlMapping": {
    "aud": 7776000
  },
  …
}

Можно настроить для данных об устройствах ограничение по сроку хранения записей в базе данных. Для этого нужно в блоке blitz.prod.local.idp.login добавить настройки:

uaActiveTtlInSec – время хранения записи об устройстве (в секундах), с которым связана долгосрочная сессия пользователя или которое пользователь при входе отметил в качестве доверенного. Если настройка не задана, то информация о таком устройстве хранится в течение года с последнего входа с этого устройства;
uaInactiveTtlInSec – время хранения записи об остальных устройствах (в секундах). Если настройка не задана, то информация о таком устройстве хранится в течение 5 суток.

Пример настроек:

"login": {
  …
  "uaActiveTtlInSec": 2678400,
  "uaInactiveTtlInSec": 432000,
  …
}

Расширенные настройки подключения к PostgreSQL#

Для расширенного управления пулом соединений с PostgreSQL или иной базой данных, поддерживающей JDBC, выполните следующие действия:

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

В секции blitz.prod.local.idp.internal-store-jdbc.pool задайте следующие опциональные настройки:

Параметр	По умолчанию	Описание
`testOnBorrow`	`true`	Проверка состояния соединения перед отправкой данных. В случае ошибки соединение удаляется и выбирается следующее из пула.
`testOnCreate`	`false`	Проверка состояния соединения после создания в пуле.
`testOnReturn`	`false`	Проверка состояния соединения после возвращения в пул.
`testWhileIdle`	`false`	Проверка состояния соединения в состоянии `idle`. В случае ошибки соединение удаляется из пула.
`timeBetweenEvictionRunsMillis`	`-1`	Интервал в мс между запуском проверки соединения в состоянии `idle`, влияет на `testWhileIdle`.
`validationQuery`	`-`	SQL-запрос выполняемый при проверке состояния соединения из пула, при пустом значении используется `isValid()`.

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

Перезапустите сервисы.

sudo systemctl restart blitz-idp blitz-console blitz-recovery blitz-registration

Расширенные настройки подключения к LDAP#

В консоли управления можно создать настройки подключения к хранилищам атрибутов, работающим по LDAP-протоколу. При этом через консоль управления можно задать настройки пула коннектов к LDAP. Blitz Identity Provider будет использовать общие настройки пула коннектов для установки подключений каждым приложением, использующим подключение к хранилищам. Это может привести к созданию большого числа коннектов к LDAP.

Через конфигурационный файл blitz.conf можно настроить параметры начального и максимального числа коннектов в разрезе различных приложений Blitz Identity Provider (например, для консоли управления задать меньшие значения коннектов в пуле, чем для сервиса аутентификации). Для этого в блоке blitz.prod.local.id-stores в настройках соответствующего хранилища наряду с настройками initialConnections и maxConnections можно создать настройки вида initialConnections#BLITZ_APP и maxConnections#BLITZ_APP, где в качестве BLITZ_APP указывается имя соответствующего приложения (blitz-console, blitz-idp, blitz-registration, blitz-recovery).

Пример настройки, когда для консоли управления задается меньший размер пула коннектов, чем для остальных приложений:

"id-stores" : {
  "list" : [
    {
      "type" : "LDAP",
      …
      "initialConnections" : 10,
      "initialConnections#blitz-console" : 1,
      "maxConnections" : 20,
      "maxConnections#blitz-console" : 1
    }
  ]
}

При выполнении запросов в LDAP хранилище атрибутов Blitz Identity Provider берет имеющееся соединение с LDAP-каталогом из пула соединений. После выполнения запроса Blitz Identity Provider не закрывает соединение, а возвращает его обратно в пул соединений для возможности повторного использования. Такой порядок взаимодействия с LDAP обеспечивает высокую производительность, но требует длительное время поддерживать соединения с LDAP-каталогом открытыми. Настройки межсетевых экранов или самих LDAP каталогов могут препятствовать длительному сохранению открытых соединений приложений Blitz Identity Provider с LDAP-каталогом.

TCP-соединения Blitz Identity Provider с LDAP-каталогом могут быть закрыты без согласованного разрыва соединения, так что в LDAP каталоге соединение будет закрыто, а Blitz Identity Provider об этом уведомлен не будет. При попытке использования такого соединения из пула может возникнуть длительный таймаут, прежде чем Blitz Identity Provider расценит соединение как закрытое и исключит его из пула соединений. Чтобы такая ситуация не влияла на пользователей, в Blitz Identity Provider предусмотрен алгоритм периодической проверки действительности открытых LDAP соединений. С периодом healthCheckInterval (в миллисекундах) выполняется проверка состояния соединения, а время таймаута при отсутствии ответа LDAP-каталога на запрос задается параметров connectionTimeout (в миллисекундах). Сам описанный режим оптимального взаимодействия с пулом соединений по умолчанию включен (настройка useSyncMode в значении false). В случае нестабильной работы соединений с LDAP-каталогом рекомендуется попробовать включить синхронный режим взаимодействия с каталогом (установить useSyncMode в значении true).

Примеры рекомендуемых настроек приведены ниже:

"id-stores" : {
  "list" : [
    {
      "type" : "LDAP",
      …
      "connectionTimeout" : 3000,
      "healthCheckInterval" : 300000,
      "useSyncMode" : false
    }
  ]
}

В случае подключения к Blitz Identity Provider одновременно нескольких хранилищ атрибутов может возникнуть такая ситуация, что при идентификации и аутентификации пользователя по логину и паролю в нескольких хранилищах может обнаружиться несколько учетных записей, возможно принадлежащих разным людям, с совпадающими логинами. Необходимо избегать такой ситуации при внедрении Blitz Identity Provider, и по умолчанию при выявлении такой ситуации Blitz Identity Provider при выявленных дублях будет выдавать пользователю ошибку входа, указывающую на наличие некорректной ситуации с учетной записью пользователя. Тем не менее, в ряде случае может возникнуть ситуация, когда при внедрении намеренно допускают, что по одному логину может быть найдено несколько учетных записей разных пользователей в разных хранилищах. В этом случае можно указать в блоке настроек blitz.prod.local.idp.login режим firstSucceded в настройке authStrategy. В этом случае все найденные учетные записи будут проверены, и к какой из них первой подойдет пароль пользователя, с этой учетной записью и будет выполнен вход.

Пример настройки:

"login" : {
  "authStrategy" : {
    "mode" : "firstSucceeded"
  },
  …
}

База геоданных#

Можно подключить к Blitz Identity Provider базу данных в формате mmdb с геоданными. В этом случае Blitz Identity Provider при регистрации событий безопасности, а также при запоминании устройств и браузеров пользователя дополнительно к сохранению IP адреса будет записывать соответствующие IP-адресу данным о стране, регионе и городе, а также широту, долготу и радиусу точности, полученные из базы геоданных.

Сохраненные геоданные будут показываться администратору в консоли управления. Также можно включить отображение геоданных пользователю в «Личном кабинете» и включить их в тексты уведомлений, отправляемых по SMS или email.

Для подключения базы данных с геоданными необходимо выложить на серверах с Blitz Identity Provider файл формата mmdb с базой данных, а также создать блок настроек blitz.prod.local.idp.geoIp со следующими настройки в блоке driver:

type – тип базы с геоданными. Поддерживается только тип geoIp2-db;
path – путь на сервере к файлу с базой геоданных в формате mmdb.

Пример настроек:

"geoIp": {
    "driver": {
        "type": "geoIp2-db",
        "path": "geoIp/GeoIP2-City.mmdb"
    }
}

Использование нескольких СУБД#

В Blitz Identity Provider можно настроить одновременное использование СУБД Couchbase Sever и СУБД PostgreSQL для хранения разных типов объектов. Для этого необходимо в блоке настроек blitz.prod.local.idp.stores задать следующие настройки:

default_type – используемая по умолчанию СУБД. Возможные значения: cb – Couchbase Server, jdbc – PostgreSQL или иная реляционная СУБД с поддержкой JDBC;
list-of-types – идентификаторы классов объектов Blitz Identity Provider и используемые для размещения соответствующих им объектов СУБД (cb или jdbc). Включать в настройку нужно только те классы объектов, которые размещаются в СУБД, отличной от указанной в default_type. Доступны следующие классы объектов:
- user-store – атрибуты учетных записей;
- access-token-store – маркеры безопасности;
- refresh-token-store – маркеры обновления;
- id-ext-store – привязки внешних поставщиков идентификации;
- device-code-store – коды подтверждения для OAuth 2.0 Device Authorization Grant;
- access-list-store – выданные пользователем разрешения приложениям;
- blitz-action-store –коды подтверждения контактов (sms, email);
- oath-token-store – привязки HOTP и TOTP генераторов разовых паролей;
- oath-load-proc-store – история загрузок описаний аппаратных HOTP и TOTP генераторов разовых паролей;
- confirmation-request-store – запросы разовых паролей;
- reg-context-store – контекст регистрации пользователей;
- reg-context-storef – контекст регистрации пользователей;
- id-store-maker – встроенное хранилище идентификаторов пользователей;
- rcv-ctx-store – контекст восстановления паролей пользователей;
- db-client-store – динамические клиенты;
- db-client-storef – динамические клиенты;
- initial-token-store – IAT маркеры;
- user-agent-store – устройства (браузеры) пользователей;
- web-authn-key-store – ключи безопасности;
- audit-store – события безопасности;
- task-store – асинхронные задачи.
utils – перечень модулей с утилитами, необходимых для используемого типа СУБД: modules.CouchbaseModule – для Couchbase Server, modules.JDBCModule – для PostgreSQL.

Пример настроек совместного использования двух СУБД:

"stores" : {
  "default-type" : "jdbc",
  "list-of-types" : {
    "access-token-store" : "cb",
    "refresh-token-store" : "cb",
    "user-agent-store" : "cb"
   },
  "utils" : [
    "modules.CouchbaseModule",
    "modules.JDBCModule"
  ]
}