Варианты установки¶
Таблица репозиториев NEOMSA APIM:
Ручная установка¶
Установка среды выполнения API Manager¶
Чтобы установить NEOMSA APIM на сервер вручную, необходимо выполнить действия, перечисленные ниже.
Загрузка дистрибутива APIM
-
Перейдите в репозиторий <RAW_REPOSITORY>, войдите в предоставленную учётную запись, загрузите ZIP-архив neomsa-apim-4.6.0.zip, чтобы загрузить дистрибутив API Manager в виде ZIP-файла.
-
Извлеките файл архива в специальный каталог для API Manager, который в дальнейшем будет именоваться <APIM-HOME>.
Настройка JAVA_HOME
Для запуска продукта необходим Java Development Kit (JDK).
Необходимо настроить переменную среды JAVA_HOME так, чтобы она указывала на каталог, в котором на компьютере установлен Java Development Kit (JDK).
Информация: Переменные среды — это системные переменные, доступные всем процессам, работающим в операционной системе.
В Linux/OS X
-
В домашней директории откройте файл BASHRC (файл .bash_profile на Mac) с помощью редакторов: vi, emacs, pico или mcedit.
-
Если в вашей системе установлен JDK 11, добавьте следующие две строки в конец файла, заменив /usr/java/jdk-11.0.x их фактическим каталогом, в котором установлен JDK.
-
Сохраните файл.
Информация: Если вы не знаете, как работать с текстовыми редакторами в SSH-сессии Linux, выполните следующую команду: cat >> .bashrc. вставьте строку из буфера обмена и нажмите «Ctrl+D».
-
Чтобы проверить правильность установки переменной JAVA_HOME, выполните следующую команду.
Настройка свойств системы
Если вам необходимо задать дополнительные системные свойства при запуске сервера, вы можете использовать следующие методы:
-
Установите свойства из скрипта: Это лучший способ, так как он гарантирует, что свойства будут установлены каждый раз при запуске сервера. Чтобы избежать необходимости изменять скрипт каждый раз при обновлении, создайте свой собственный скрипт запуска, который добавляет нужные свойства, вместо редактирования оригинального скрипта NEOMSA.
-
Установите свойства из внешнего реестра: если вы хотите получить доступ к свойствам из внешнего реестра, вы можете написать код на Java для считывания свойств из внешнего реестра во время выполнения. Храните конфиденциальные данные (например, логин и пароль для подключения к реестру) в файле свойств, а не в коде Java, и используйте безопасное хранилище для защиты этого файла.
Информация: При использовании SUSE Linux он игнорирует /etc/resolv.conf и смотрит только на файл /etc/hosts. Это означает, что сервер выдаст исключение при запуске, если вы не указали ничего, кроме localhost. Чтобы избежать этой ошибки, добавьте следующую строку выше 127.0.0.1 localhost в /etc/hosts файл: <ip_address><machine_name> localhost.
Запуск среды выполнения API Manager¶
Следуйте этим шагам, чтобы запустить NEOMSA APIM и получить доступ к его веб-порталам: Консоли управления (Management Console), Публикатору API (API Publisher) и Порталу разработчиков (Developer Portal).
Прежде чем начать
Загрузите и установите сервер API Manager.
Запуск сервера API-M
Для запуска сервера выполните следующие действия.
- Откройте командную строку.
| На Linux/Mac OS | Установите SSH-подключение к серверу, войдите в текстовую консоль Linux или откройте окно терминала. |
|---|---|
-
Перейдите к папке <APIM-HOME>/bin из командной строки.
-
Выполните одну из команд, приведённых ниже.
-
Чтобы запустить сервер на MacOS/Linux
-
Чтобы запустить сервер в фоновом режиме на macOS/Linux:
-
Когда сервер успешно запустится, в логах появится сообщение: "NEOMSA Carbon started in 'n' seconds"
Доступ к веб-порталам
После запуска сервера все веб-порталы также активируются. URL-адреса порталов будут указаны в логах запуска сервера.
Обратите внимание, что сервер работает по умолчанию на localhost. Сервер по умолчанию работает на localhost. Вы можете использовать эти URL для доступа к веб-порталам с любого компьютера в вашей локальной сети. Если вы используете тот же компьютер, где установлен сервер, просто введите localhost вместо IP-адреса.
Чтобы войти на веб-портал:
- Скопируйте URL-адрес веб-портала в свой браузер.
Примечание: Веб-браузер обычно отображает сообщение о «незащищенном соединении», требующее вашего подтверждения, прежде чем вы сможете продолжить.
- Введите свое логин и пароль для входа.
Примечание Логин и пароль по умолчанию —admin.
Остановка сервера API-M
-
Чтобы остановить сервер APIM, перейдите в терминал и нажмите Ctrl+C.
-
Чтобы остановить сервер APIM в фоновом режиме:
На macOS/Linux
Примечание: Для получения дополнительных параметров, которые можно использовать с командами запуска, добавьте -help после команды запуска, как показано ниже.
Запуск API Manager как службы Linux Service¶
Предупреждение:
Следующие инструкции неприменимы к дистрибутивам Red Hat Linux, таким как Fedora, поскольку эти дистрибутивы содержат пакет chkconfig вместо пакета update-rc.d для управления службами.
- Для поддержки ОС Linux на базе Red Hat вам необходимо использовать chkconfig для регистрации службы и добавления информации о них в уровни выполнения chkconfig. Для получения дополнительной информации см. chkconfig.
Примечание
Прежде чем начать:
-
Ознакомьтесь с матрицей совместимости , чтобы проверить совместимые версии JDK.
-
Настройте переменную среды JAVA_HOME.
Настройка CARBON_HOME
Извлеките NEOMSA в каталог на вашем компьютере и установите переменную среды CARBON_HOME в распакованную директорию
Запуск продукта как службы Linux
-
Чтобы запустить продукт в качестве службы, создайте скрипт запуска и добавьте его в последовательность загрузки. Базовая структура сценария запуска состоит из трех частей (т.е. запуск, остановка и перезапуск) следующим образом:
Ниже приведен пример скрипта. <APIM-HOME> Он может отличаться в зависимости от каталога продукта NEOMSA.
#! /bin/sh
export JAVA_HOME="/usr/lib/jvm/ jdk-11.0.x"
startcmd='<APIM-HOME>/bin/api-manager.sh start > /dev/null &'
restartcmd='<APIM-HOME>/bin/api-manager.sh restart > /dev/null &'
stopcmd='<APIM-HOME>/bin/api-manager.sh stop > /dev/null &'
case "$1" in
start)
echo "Starting the NEOMSA APIM Server ..."
su -c "${startcmd}" user1
;;
restart)
echo "Re-starting the NEOMSA APIM Server ..."
su -c "${restartcmd}" user1
;;
stop)
echo "Stopping the NEOMSA APIM Server ..."
su -c "${stopcmd}" user1
;;
*)
echo "Usage: $0 {start|stop|restart}"
exit 1
esac
В приведенном выше скрипте сервер запускается как пользователь с именем user1, а не как пользователь root. Например, su -c "${startcmd}" user1
- Добавьте скрипт в каталог /etc/init.d/
Информация: Если вы хотите сохранить скрипт в другом месте, отличном от /etc/init.d/, вы можете добавить ссылку на скрипт в /etc/init.d/и сохранить сам скрипт в другом месте. Допустим, имя вашего скрипта prodserver и находится в папке /opt/NEOMSA/, выполните следующие команды для добавления ссылки /etc/init.d/
-
Сделать исполняемым: sudo chmod a+x /opt/ NEOMSA /prodserver
-
Добавить ссылку в /etc/init.d/:sudo ln -snf /opt/ NEOMSA /prodserver /etc/init.d/prodserver
-
Установите скрипт для соответствующих уровней запуска с помощью команды update-rc.d. Например, задайте команду для скрипта, показанного в шаге 1:
Опция defaults в приведенной выше команде заставляет службу запускаться на уровнях выполнения 2, 3, 4 и 5 и останавливаться на уровнях выполнения 0, 1 и 6.
Уровень выполнения — это режим работы в Linux (или других Unix-подобных операционных системах). На сервере Linux есть несколько уровней выполнения, и каждый из этих уровней выполнения представлен однозначным целым числом. Каждый уровень выполнения обозначает различную конфигурацию системы и обеспечивает доступ к различным комбинациям процессов.
- Теперь вы можете запускать, останавливать и перезапускать сервер с помощью команды service <service name>{start|stop|restart}
Вам будет необходимо ввести пароль пользователя (или root), который использовался для запуска службы.
Kubernetes¶
Следуйте приведенным ниже инструкциям, чтобы с помощью ресурсов Kubernetes (K8s) и Helm развернуть NEOMSA APIM на базе контейнеров.
| Необходимые условия Учетная запись от HELM/DOCKER репозитория NEOMSA APIM Установленный Helm и клиент Kubernetes, чтобы выполнить шаги, описанные в данном руководстве. Развернутый кластер Kubernetes. Установленный контроллер NGINX Ingress. Установленный в кластере nfs-provisioner (либо другой Storage Class) Добавленный репозиторий чартов NEOMSA APIM Helm. Подготовленные БД (см. пункт 3.1) |
|---|
| helm repo add neomsa-apim <HELM_REPOSITORY> --username <USER> --password <PASSWORD> && helm repo update |
|---|
- Изучите values.yml чарта необходимой топологии.
| helm show values <HELM_REPOSITORY>/<CHART_NAME> |
|---|
| neomsaApim: neomsaAnalytics: enabled: false neomsaAPMtelemetry: enabled: false tracerName: "otlp" host: <APM_HOST> port: 8200 tracerProperties: keyName: "api-key" keyValue: "<API-KEY>" neomsaLogstash: host: <LOGSTASH_HOST> port: 5044 neomsaLog4j: policiesTimeInterval: 1 policiesSize: 1000MB strategyMax: 3 antiaffinity: enabled: false labelSelector: key: instanceType deployment: persistentRuntimeArtifacts: storageClass: "nfs-client" apacheSolrIndexing: enabled: false capacity: carbonDatabase: 50M solrIndexedData: 50M ingress: certificateSecret: do-neoflex-cert am: dockerRegistry: <DOCKER_REPOSITORY> imageName: "neomsa-apim" imageTag: "4.6.0" imagePullPolicy: Always livenessProbe: initialDelaySeconds: 180 periodSeconds: 10 readinessProbe: initialDelaySeconds: 180 periodSeconds: 10 resources: requests: memory: "2Gi" cpu: "2000m" limits: memory: "4Gi" cpu: "2000m" jvm: heap: memory: xms: "2048m" xmx: "3072m" ingress: management: tls: enabled: true enabled: true hostname: "apim-neomsa.<YOUR_DOMAIN>" annotations: kubernetes.io/ingress.class: "nginx" nginx.ingress.kubernetes.io/backend-protocol: "HTTPS" nginx.ingress.kubernetes.io/ssl-passthrough: 'false' nginx.ingress.kubernetes.io/affinity: "cookie" nginx.ingress.kubernetes.io/session-cookie-name: "route" nginx.ingress.kubernetes.io/session-cookie-hash: "sha1" gateway: tls: enabled: true enabled: true hostname: "gateway-neomsa.<YOUR_DOMAIN>" annotations: kubernetes.io/ingress.class: "nginx" nginx.ingress.kubernetes.io/backend-protocol: "HTTPS" nginx.ingress.kubernetes.io/ssl-passthrough: 'false' websub: tls: enabled: true enabled: true hostname: "websub-neomsa.<YOUR_DOMAIN>" annotations: kubernetes.io/ingress.class: "nginx" nginx.ingress.kubernetes.io/backend-protocol: "HTTPS" nginx.ingress.kubernetes.io/ssl-passthrough: 'false' websocket: tls: enabled: true enabled: true hostname: "websocket-neomsa.<YOUR_DOMAIN>" annotations: kubernetes.io/ingress.class: "nginx" nginx.ingress.kubernetes.io/backend-protocol: "HTTPS" nginx.ingress.kubernetes.io/ssl-passthrough: 'false' db: hostname: <DATABASE_HOSTNAME> port: 5432 type: "postgre" driver: org.postgresql.Driver driver_url: https://repo1.maven.org/maven2/org/postgresql/postgresql/42.7.1/postgresql-42.7.1.jar apim: username: <USERNAME> password: <PASSWORD> url: jdbc:postgresql://<DATABASE_HOSTNAME>:5432/NEOMSA_APIM_DB?useSSL=false&autoReconnect=true&requireSSL=false&verifyServerCertificate=false apim_shared: username: <USERNAME> password: <PASSWORD> url: jdbc:postgresql://<DATABASE_HOSTNAME>:5432/NEOMSA_APIM_SHARED_DB?useSSL=false&autoReconnect=true&requireSSL=false&verifyServerCertificate=false mi: dockerRegistry: <DOCKER_REPOSITORY> imageName: "neomsa-mi" imageTag: "4.6.0" replicas: 1 strategy: rollingUpdate: maxSurge: 1 maxUnavailable: 0 startupProbe: initialDelaySeconds: 180 periodSeconds: 5 failureThreshold: 8 livenessProbe: initialDelaySeconds: 600 periodSeconds: 10 readinessProbe: initialDelaySeconds: 180 periodSeconds: 10 resources: requests: memory: "512Mi" cpu: "1000m" limits: memory: "1Gi" cpu: "1000m" envs: synapseTest: enabled: false testServiceEnabled: true ingress: className: "" management: hostname: "mi-neomsa.<YOUR_DOMAIN>" annotations: kubernetes.io/ingress.class: "nginx" nginx.ingress.kubernetes.io/backend-protocol: "HTTPS" kubernetes: serviceAccount: "neomsa-apim-single-node-svc-account" |
|---|
- Создайте секрет в кластере Kubernetes при помощи следующей команды:
kubectl create secret docker-registry <SECRET_NAME> --docker-username=<USER> --docker-password=<PASSWORD> --namespace <NAMESPACE> --docker-server=registry.neomsa.ru
- Установите helm-chart с необходимыми параметрами.
| helm install <RELEASE_NAME> <HELM_REPOSITORY>/<CHART_NAME> --namespace <NAMESPACE> --set key1=value1 --set keyN=valueN |
|---|
- Консоль управления доступом.
Получите внешний IP-адрес (EXTERNAL-IP) ресурсов Ingress, указав его в списке Kubernetes Ingresses.
| kubectl get ing -n <NAMESPACE> |
|---|
Пример:
| НАЗВАНИЕ | ХОСТ | АДРЕС | ПОРТЫ | ВРЕМЯ |
|---|---|---|---|---|
| neomsa-apim-single-node-am-gateway-ingress | gateway-neomsa.<YOUR_DOMAIN> | <EXTERNAL-IP> | 80, 443 | 7m |
| neomsa-apim-single-node-am-ingress | apim-neomsa.<YOUR_DOMAIN> | <EXTERNAL-IP> | 80, 443 | 7m |
| neomsa-apim-single-node-am-websub-ingress | websub-neomsa.<YOUR_DOMAIN> | <EXTERNAL-IP> | 80, 443 | 7m |
Добавьте указанные выше хосты либо как A записи на DNS-сервере, либо в качестве записей в файл /etc/hosts следующим образом:
| <EXTERNAL-IP> gateway-neomsa.<YOUR_DOMAIN> <EXTERNAL-IP> apim-neomsa.<YOUR_DOMAIN> <EXTERNAL-IP> websub-neomsa.<YOUR_DOMAIN> |
|---|
Попробуйте перейти из вашего браузера по следующим адресам:
https://apim-neomsa.<YOUR_DOMAIN>/carbon,
https://apim-neomsa.<YOUR_DOMAIN>/publisher,
https://apim-neomsa.<YOUR_DOMAIN>/devportal
Ansible¶
В этом разделе описаны сценарии Ansible для установки и настройки NEOMSA APIM .
Загрузите пакет поставки из репозитория <RAW_REPOSITORY> на ansible-мастере, у которого должен доступ до серверов, на которые будет происходить установка.
| Структура директорий |
|---|
| . ├── db_scripts │ └── 4.6.0 │ ├── postgresql_db.sql │ └── postgresql_shared_db.sql ├── dev_allinone │ ├── group_vars │ │ ├── neomsa-apim.yml │ │ ├── neomsa-micro-integrator.yml │ │ └── haproxy.yml │ ├── host_vars │ │ ├── neomsa-micro-integrator_1.yml │ │ ├── neomsa-micro-integrator_2.yml │ │ ├── neomsa-apim_1.yml │ │ └── neomsa-apim_2.yml │ └── inventory ├── dev_allinone_ha │ ├── group_vars │ ├── host_vars │ └── inventory ├── dev_distributed │ ├── group_vars │ ├── host_vars │ └── inventory ├── dev_distributed_multidc │ ├── group_vars │ ├── host_vars │ └── inventory ├── docs ├── files │ ├── lib │ │ └── amazon-corretto-17.0.6.10.1-linux-x64.tar.gz │ ├── packs │ │ ├── neomsa-apim-4.6.0.zip │ │ └── neomsa-mi-4.5.0.zip │ ├── system │ │ └── etc │ │ ├── security │ │ │ └── limits.conf │ │ └── sysctl.conf │ └── misc ├── roles │ ├── neomsa-apim │ │ ├── tasks │ │ └── templates │ ├── neomsa-apim-control-plane │ │ ├── tasks │ │ └── templates │ ├── neomsa-apim-gateway │ │ ├── tasks │ │ └── templates │ ├── neomsa-apim-tm │ │ ├── tasks │ │ └── templates │ ├── micro-integrator │ │ ├── tasks │ │ └── templates │ ├── haproxy │ │ ├── tasks │ │ └── templates │ └── common │ └── tasks ├── allinone.yml ├── allinone_ha.yml ├── distributed.yml └── distributed_multidc.yml |
Локальное копирование пакетов
Пакеты могут быть скопированы в локальную директорию или загружены из удаленного места.
Скопируйте следующие файлы в каталог files/packs.
- Пакет NEOMSA APIM (.zip) (будет предоставлен в файлах поставки)
Скопируйте следующие файлы в каталог files/lib.
Если вам необходимо скопировать на сервера какие-либо ещё файлы, поместите их в каталог files/misc. Для включения копирования этих файлов необходимо раскомментировать список misc_file_list в yaml-файлах в разделе group_vars и добавить в список нужные файлы.
Загрузка из удаленного репозитория
Для загрузки пакетов из удалённого репозитория, в group_vars измените значения следующих переменных во всех группах:
-
Значение pack_location должно быть изменено с «local» на «remote».
-
Значение remote_jdk должно быть изменено на URL, с которого должен быть загружен JDK.
-
Значение remote_pack должно быть изменено на URL, с которого должен быть загружен пакет.
Запуск скриптов NEOMSA APIM Ansible¶
Предварительно, на серверах, на которых установлена система безопасности Selinux, эту систему необходимо отключить:
Проверьте текущее состояние SELinux. Для этого выполните команду:
sestatus
Если параметр SELinux status имеет значение enabled, отключите SELinux. Для этого выполните команду:
setenforce 0
Проверьте параметры запуска SELinux при загрузке системы. Для этого выполните команду:
cat /etc/selinux/config
Если параметр SELINUX имеет значение enforcing, отключите запуск SELinux при загрузке системы. Для этого в файле /etc/selinux/config укажите SELINUX=disabled вместо SELINUX=enforcing.
Запуск существующих скриптов без настройки
Следующие инструкции можно использовать для развертывания стандартной системы APIM «все в одном» («all-in-one»), чтобы протестировать продукт и провести демонстрацию.
В данной конфигурации скрипты Ansible установят шаблон NEOMSA APIM на одной ноде. Для развертывания шаблона необходимо заменить [ip_address] и [ssh_user], указанные в файле инвентаризации (inventrory) в папке dev_allinone, на IP того узла, где будет размещен NEOMSA APIM . Пример приведен ниже.
| [apim] apim_1 ansible_host=192.0.2.10 ansible_user=tech_user |
|---|
Выполните следующую команду, чтобы запустить скрипты. Используйте -K,чтобы указать пароль для получения прав root. Настройте become_method: в ansible.cfg, если используете альтернативу sudo. Если ваш хост позволяет использовать sudo без пароля, опустите аргумент -K.
ansible-playbook -K -i dev_allinone allinone.yml
Если вам нужно изменить приведенные конфигурации, измените параметризованные значения в yaml-файлах group_varsи host_vars.
Настройка дополнительных скриптов NEOMSA APIM Ansible¶
Шаблоны, используемые скриптами Ansible, имеют формат j2, чтобы обеспечить возможность параметризации.
Файл deployment.toml.j2 добавляется в roles/apim/templates/carbon-home/repository/conf/, чтобы обеспечить возможность настройки. Вы также можете добавить любые другие настройки в custom.yml под задачами каждой роли.
Шаг 1
Раскомментируйте следующую строку в файле main.yml для роли, которую вы хотите настроить.
| - import_tasks: custom.yml |
|---|
Шаг 2
Добавьте конфигурации в файл custom.yml. Пример приведен ниже.
| - name: "Copy custom file" template: src: path/to/example/file/example.xml.j2 dest: destination/example.xml.j2 when: "(inventory_hostname in groups['am'])" |
|---|
3.Тюнинг производительности
Конфигурации системы могут быть изменены с помощью Ansible для оптимизации производительности на уровне ОС. Настройка производительности может быть включена путем изменения значения enable_performance_tuning в dev_<название паттерна>/group_vars/apim.yml на true.
Системные файлы, которые будут обновляться при включении настройки производительности, доступны в файлах files/system. Обновите значения конфигурации в соответствии с требованиями вашего развертывания.
- Для оптимизации производительности сети и операционной системы настройте следующие параметры в /etc/sysctl.conf файле Linux. Эти настройки определяют больший диапазон портов, более эффективное значение времени ожидания TCP-соединения и ряд других важных параметров на уровне операционной системы.
net.ipv4.tcp_fin_timeout = 30
fs.file-max = 2097152
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_tw_reuse = 1
net.core.rmem_default = 524288
net.core.wmem_default = 524288
net.core.rmem_max = 67108864
net.core.wmem_max = 67108864
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.ipv4.ip_local_port_range = 1024 65535
- Чтобы изменить количество разрешенных открытых файлов для пользователей системы, настройте следующие параметры в /etc/security/limits.conf файле Linux
(обязательно включите начальный символ *).
* soft nofile 4096
* hard nofile 65535
- Чтобы изменить максимальное количество процессов, которые вашему пользователю разрешено запускать в данный момент времени, настройте следующие параметры в /etc/security/limits.conf файле Linux (обязательно включите начальный символ *). Для каждого запускаемого вами экземпляра Carbon server потребуется до 1024 потоков (с настройкой пула потоков по умолчанию). Следовательно, вам необходимо увеличить значение nproc на 1024 для каждого Carbon
* soft nproc 20000
* hard nproc 20000
Паттерны развертывания¶
Предоставляемые роли ansible helm-чарты содержат 4 паттерна установки APIM в различных конфигурациях.
В схемах (кроме allinone, в этой схеме Micro Integrator разворачивается в единственном экземпляре) также разворачивается Micro Integrator в режиме active-active.
Ansible
Настройка адреса БД производится в переменной database_hostname, в файлах dev_<название шаблона>/group_vars/<apim, micro-integrator>.yml
Если Micro Integrator не требуется, следует закомментировать следующие строчки в плейбуке <название паттерна>.yml:
| - name: Apply Micro Integrator default configuration to a micro-integrator node hosts: - micro-integrator roles: - micro-integrator |
|---|
Helm
Настройка адреса БД производится в следующих переменных:
neomsaApim.deployment.am.db.apim_shared.url
neomsaApim.deployment.am.db.apim.url
Если Micro Integrator не требуется, нужно выставить параметр neomsaApim.deployment.mi.replicas в значение 0.
1. All in one
В данном примере APIM разворачивается в одноузловом режиме всё-в-одном.
Ansible
После изменения переменных в папке dev_allinone запуск можно осуществить следующей командой:
ansible-playbook allinone.yml -i dev_allinone/inventory
Helm
После изменения переменных в файле values.yaml запуск можно осуществить следующей командой:
helm install <RELEASE_NAME> <HELM_REPOSITORY>/neomsa-apim-allinone —namespace <NAMESPACE>
2. All in one HA
В этой конфигурации добавляется второй инстанс APIM всё-в-одном, а также балансировщик нагрузки (при использовании ansible).
Ansible
После изменения переменных в папке dev_allinone_ha запуск можно осуществить следующей командой:
ansible-playbook allinone_ha.yml -i dev_allinone_ha/inventory
Helm
После изменения переменных в файле values.yaml запуск можно осуществить следующей командой:
helm install <RELEASE_NAME> <HELM_REPOSITORY>/neomsa-apim-allinone_ha —namespace <NAMESPACE>
3. Distributed
В этой конфигурации происходит разделение нод APIM по функциональности: Панель управления (control-plane), Шлюз (gateway), Управление трафиком (traffic-manager).
Ansible
После изменения переменных в папке dev_distributed запуск можно осуществить следующей командой:
ansible-playbook distributed.yml -i dev_distributed/inventory
Helm
После изменения переменных в файле values.yaml запуск можно осуществить следующей командой:
helm install <RELEASE_NAME> <HELM_REPOSITORY>/neomsa-apim-distributed —namespace <NAMESPACE>
4. Distributed MultiDC
В этой конфигурации, помимо разделения инстансов APIM по функциональности, установка производится на 2 кластера, для георезервирования.
Ansible
ansible-playbook distributed_multidc.yml -i dev_distributed_multidc/inventory
Ports Offset
Для установки нескольких инстансов APIM на одну ноду можно использовать параметр ports_offset в host_vars, который передвигает выделяемые порты. Например, порт веб-интерфейса по-умолчанию 9443, при значении posts_offset «1», порт изменится на 9444, при значении «2», порт установится на 9445.
В примерах конфигураций Distributed cluster и Distributed MultiDC компоненты Control Plane, Gateway и Traffic Manager разворачиваются на одной ВМ, для этого использован параметр ports offset. Во всех конфигурациях, где из-за этого изменился порт, указан комментарий "offset port+<значение offset>" (Control Plane без изменений, Gateway+1, Traffic Manager +2)
Helm
Так как в этом паттерне развертывания используется два кластера, настройки разделены на два файла: values-geo1.yaml и values-geo2.yaml.
Обратите внимание на параметр «neomsaApim.deployment.am.secondRegion.cpHostname», этот параметр должен указывать на адрес другого кластера (в настройках кластера 1 — на имя хоста кластера 2, в настройках кластера 2 — на имя хоста кластера 1).
После изменения переменных в файлах values-geo1.yaml и values-geo2.yaml запуск можно осуществить следующей командой:
helm install <RELEASE_NAME> <HELM_REPOSITORY>/neomsa-apim-distributed —namespace <NAMESPACE> –f values-geo1.yaml
И, переключившись на контекст второго кластера, произвести установку, указав второй файл с переменными:
helm install <RELEASE_NAME> <HELM_REPOSITORY>/neomsa-apim-distributed —namespace <NAMESPACE> –f values-geo2.yaml
Настройка API Manager¶
Настройка менеджера ключей (Key Manager)¶
Key Manager обрабатывает все операции, связанные с клиентами, безопасностью и токенами доступа. В типичном развертывании API Manager в производственной среде различные компоненты взаимодействуют с компонентом Key Manager для выполнения различных задач. API Gateway подключается к Key Manager для проверки действительности токенов OAuth, подписок и вызовов API. Когда подписчик создает токен доступа к приложению с помощью Developer Portal. Этот портал вызывает Key Manager для создания приложения OAuth и получает токен доступа.
При запуске сервера, шлюз извлекает всю метаинформацию о проверке подписки (это: API, политики API, шаблоны URL, приложения, ключи приложений, политики приложений, подписки и политики подписки), из базы данных и сохраняет их в памяти. Поэтому, когда требуется проверить токен, API Gateway использует хранилище данных в памяти и проверяет данные токена.
Key Manager отделяет управление клиентом OAuth и токенами доступа от остальных своих операций, чтобы можно было подключить стороннего поставщика OAuth для управления клиентами OAuth и токенами доступа. При работе с внешним Key Manager необходимо настроить конфигурации сервера авторизации в портале администратора NEOMSA APIM , добавив новый Key Manager.
Управление ростом данных и повышение производительности¶
NEOMSA APIM при использовании будет хранить метаданные и данные времени выполнения в своих подключенных базах данных. Например, он хранит API, приложения, подписки и токены, созданные пользователями. Метаданные, связанные с приложениями и API, не записываются в базы данных часто. Однако, поскольку данные времени выполнения зависят от различных факторов, таких как количество пользователей, количество подключенных приложений и шаблоны использования, значительная нагрузка на систему приведет к тому, что данные о времени выполнения будут накапливаться медленно с течением времени. В результате может наблюдаться значительный рост объема данных в таблицах, что негативно сказывается на производительности.
Недействительные токены доступа, отозванные токены доступа, журналы транзакций реестра, коды авторизации и сеансы пользователей — вот некоторые из данных времени выполнения, которые хранятся в этих базах данных. При внимательном анализе этих данных становится очевидным, что не всегда необходимо их хранить, кроме случаев, связанных с аудитом. Поэтому эти данные можно периодически очищать.
NEOMSA APIM предоставляет два метода очистки.
-
Регулярная очистка
-
Глубокая очистка
Регулярная очистка помогает поддерживать порядок и замедляет накопление неиспользуемых токенов. Однако во время пиковых нагрузок она может оказаться менее эффективной из-за возможных задержек в обработке запросов.
Предупреждение: Глубокая очистка удаляет неиспользуемые токены, сеансы и данные реестра, а также предотвращает непрерывный рост таблиц, что может повысить производительность на производственных серверах. Выберите подходящий метод очистки в зависимости от уровня трафика сервера.
Регулярная очистка
Эта очистка выполняется внутри продукта. Она очищает неиспользуемые данные, связанные с токенами, во время выполнения. Это процесс очистки на основе событий, который включает очистку определенных записей на основе определенных действий пользователя. Например, когда токен доступа отзывается, токен будет выбран из таблицы IDN_OAUTH2_ACCESS_TOKEN и перемещен в таблицу для аудита IDN_OAUTH2_ACCESS_TOKEN_AUDIT. Помимо отозванных токенов, в этой таблице также накапливаются неактивные и просроченные токены. Эта таблица не используется NEOMSA APIM . Эти токены хранятся в базе данных для целей регистрации и аудита, но со временем они могут оказать негативное влияние на производительность сервера. Поэтому рекомендуется их очищать.
Примечание: Начиная с версии NEOMSA APIM 2.6.0, он по умолчанию настроен на запуск очистки токенов во время генерации токенов, обновления токенов и отзыва токенов. Поэтому, когда состояние токена (TOKEN_STATE) изменяется во время любого из последних упомянутых процессов для токенов, которые были в состоянии ACTIVE ранее, по умолчанию такие токены будут удалены из таблицы IDN_OAUTH2_ACCESS_TOKEN и сохранены в таблице аудита. Поэтому вам не нужно вручную очищать неиспользуемые токены, как указано ниже, начиная с версии API-M 2.6.0. Однако вам необходимо настроить NEOMSA API Manager для выполнения регулярной очистки.
Настройка NEOMSA APIM для выполнения регулярной очистки
NEOMSA APIM a запускает очистку токенов в следующих случаях.
-
Генерация токенов
-
Обновление токена
-
Отзыв токена
Примечание: Регулярная процедура очистки включена по умолчанию и очищает токены Inactive, Revoked и Expired. Если вы отключили эту процедуру и через некоторое время хотите включить эту процедуру очистки, лучше очистить таблицу токенов доступа с помощью процесса глубокой очистки , а затем включить эту функцию.
Чтобы включить или отключить очистку токенов, откройте файл <APIM-HOME>/repository/conf/deployment.toml и внесите следующие изменения. (Добавьте конфигурацию, если ее нет в файле deployment.toml)
| Свойство | Описание |
|---|---|
| enable | Установите это свойство: true чтобы включить очистку токена. Установите это свойство: false чтобы отключить очистку токена. |
| retain_access_tokens_for_auditing | Установите это свойство: true чтобы переместить старые, недействительные токены в таблицу аудита, когда включена очистка токенов. Установите это свойство: false если вы не хотите хранить старые токены в таблице аудита. |
В этом методе очистки все оставшиеся данные токенов, данные сеансов и данные реестра могут быть очищены с помощью отдельных хранимых процедур для каждого типа данных. Неиспользуемые данные периодически анализируются и удаляются с помощью хранимой процедуры, которая выполняется в отношении базы данных. В процессе глубокой очистки валидность данных проверяется в каждой записи. Если обнаружены неиспользуемые или старые данные, хранимая процедура очистит их. Имеется три хранимых процедуры, которые можно использовать для выполнения следующих трех видов очистки.
-
Очистка токенов
-
Очистка сеанса
-
Очистка реестра
Включение глубокой очистки (очистка токенов, сеансов и реестра)
Это приведет к удалению старых и недействительных токенов, сеансов и кодов аутентификации, которые невозможно очистить с помощью встроенного процесса очистки продукта.
Примечание: Безопасно запускать эти шаги в режиме только для чтения или в то время, когда трафик на сервере низкий. Однако последнее не является обязательным, если вы оцениваете или тестируете продукт. Однако, если вы запускаете производственное развертывание с большим объемом трафика, рекомендуется выполнять эти действия периодически, поскольку количество неиспользованных токенов, сеансов и т. д. может быть большим.
Сделайте резервную копию работающей базы данных.
- При желании можно настроить дамп базы данных в тестовой среде и проверить его на наличие проблем.
Дополнительную информацию о настройке дампа базы данных можно найти в официальной документации MySQL, SQL Server и Oracle.
Примечание: NEOMSA рекомендует протестировать скрипты очистки и хранимые процедуры перед их запуском или настройкой на сервере рабочей базы данных.
- Выберите здесь подходящий сценарий очистки, соответствующий вашей базе данных, и запустите его в рабочей базе данных.
Это делает резервную копию необходимых таблиц, отключает обновления SQL и очищает базу данных от неиспользуемых токенов. Однако при запуске скрипта в рабочей среде убедитесь, что скрипт был протестирован хотя бы один раз в более низкой среде.
Выберите скрипт token-cleanup для очистки токенов, скрипт для очистки данных сеанса sessiondata-cleanup и скрипт для очистки неиспользуемых данных в реестре registry-cleanup.
- После завершения очистки запустите NEOMSA APIM и тщательно протестируйте его на наличие каких-либо проблем.
Очистка базы данных реестра
Создание и обновление API, а также добавление тегов и рейтингов приводит к добавлению различных свойств реестра в базу данных реестра (Registry DB) в NEOMSA API-M. Когда Registry Versioning включено, старые свойства сохраняются в базе данных, что приводит к ненужному росту записей в таблицах реестра в базе данных. Это напрямую влияет на производительность продукта, если количество записей превышает определенное количество. Из-за этого ограничения управление версиями реестра по умолчанию отключено в NEOMSA APIM , чтобы предотвратить ненужный рост базы данных.
Вы можете очистить следующие таблицы в базе данных реестра, не влияя на функциональность продукта. - REG_LOG - REG_PROPERTY - REG_RESOURCE_PROPERTY - REG_TAG - REG_RESOURCE_TAG
Информация:Вы всегда можете сделать резервную копию базы данных реестра перед очисткой в качестве меры предосторожности на случай возникновения проблем во время очистки.
Прежде чем начать...
Не забудьте выключить сервер и остановить все транзакции БД перед очисткой базы данных. Это необходимо для предотвращения любых несоответствий, которые могут возникнуть с новыми данными, добавляемыми в БД во время очистки.
Ниже приведены скрипты очистки таблиц базы данных реестра.
Очистка таблицы REG_LOG
Типы БД: H2, DB2, MySQL, MSSQL, Oracle и PostgreSQL.
CREATE TABLE REG_LOG_IDS_TO_KEEP (
REG_LOG_ID INTEGER,
REG_TENANT_ID INTEGER
);
INSERT INTO REG_LOG_IDS_TO_KEEP (REG_LOG_ID, REG_TENANT_ID)
SELECT MAX(REG_LOG_ID) AS REG_LOG_ID, REG_TENANT_ID FROM REG_LOG GROUP BY REG_PATH, REG_TENANT_ID;
DELETE FROM REG_LOG WHERE REG_LOG_ID NOT IN (SELECT REG_LOG_ID FROM REG_LOG_IDS_TO_KEEP);
DROP TABLE REG_LOG_IDS_TO_KEEP;
DELETE FROM REG_LOG WHERE REG_ACTION = 7;
Очистка таблиц REG_PROPERTY и REG_RESOURCE_PROPERTY
Типы БД: H2, MSSQL и PostgreSQL
CREATE TABLE TEMP_REG_RESOURCE_PROPERTY_ID(REG_PROPERTY_ID INTEGER);
-- Extract resource property (ID) created when versioning is disabled --
INSERT INTO TEMP_REG_RESOURCE_PROPERTY_ID(REG_PROPERTY_ID)
SELECT REG_PROPERTY_ID
FROM REG_RESOURCE_PROPERTY
WHERE REG_PATH_ID IN
(SELECT REG_PATH_ID
FROM REG_RESOURCE);
-- Extract resource property (ID) created when versioning is enabled --
INSERT INTO TEMP_REG_RESOURCE_PROPERTY_ID(REG_PROPERTY_ID)
SELECT REG_PROPERTY_ID
FROM REG_RESOURCE_PROPERTY
WHERE REG_VERSION IN
(SELECT REG_VERSION
FROM REG_RESOURCE);
-- Drop the foreign key constraint --
ALTER TABLE REG_RESOURCE_PROPERTY DROP CONSTRAINT REG_RESOURCE_PROPERTY_FK_BY_TAG_ID;
-- delete all unwanted REG_RESOURCE_PROPERTY entries --
DELETE
FROM REG_RESOURCE_PROPERTY
WHERE REG_PROPERTY_ID NOT IN
(SELECT REG_PROPERTY_ID
FROM TEMP_REG_RESOURCE_PROPERTY_ID);
-- delete all unwanted REG_PROPERTY entries --
DELETE
FROM REG_PROPERTY
WHERE REG_ID NOT IN
(SELECT REG_PROPERTY_ID
FROM TEMP_REG_RESOURCE_PROPERTY_ID);
-- Insert back the foreign key constraint --
ALTER TABLE REG_RESOURCE_PROPERTY ADD CONSTRAINT REG_RESOURCE_PROPERTY_FK_BY_TAG_ID FOREIGN KEY (REG_PROPERTY_ID, REG_TENANT_ID) REFERENCES REG_PROPERTY (REG_ID, REG_TENANT_ID);
-- drop temporary table --
DROP TABLE TEMP_REG_RESOURCE_PROPERTY_ID;
Очистка таблиц REG_TAG и REG_RESOURCE_TAG
Типы БД: H2, MSSQL и PostgreSQL
CREATE TABLE TEMP_REG_RESOURCE_TAG_ID(REG_TAG_ID INTEGER);
-- Extract resource tag (ID) created when versioning is disabled --
INSERT INTO TEMP_REG_RESOURCE_TAG_ID(REG_TAG_ID)
SELECT REG_TAG_ID
FROM REG_RESOURCE_TAG
WHERE REG_PATH_ID IN
(SELECT REG_PATH_ID
FROM REG_RESOURCE);
-- Extract resource tag (ID) created when versioning is enabled --
INSERT INTO TEMP_REG_RESOURCE_TAG_ID(REG_TAG_ID)
SELECT REG_TAG_ID
FROM REG_RESOURCE_TAG
WHERE REG_VERSION IN
(SELECT REG_VERSION
FROM REG_RESOURCE);
-- Remove the foreign key constraint --
ALTER TABLE REG_RESOURCE_TAG DROP CONSTRAINT REG_RESOURCE_TAG_FK_BY_TAG_ID;
-- delete all unwanted REG_RESOURCE_TAG entries --
DELETE
FROM REG_RESOURCE_TAG
WHERE REG_TAG_ID NOT IN
(SELECT REG_TAG_ID
FROM TEMP_REG_RESOURCE_TAG_ID);
-- delete all unwanted REG_TAG entries --
DELETE
FROM REG_TAG
WHERE REG_ID NOT IN
(SELECT REG_TAG_ID
FROM TEMP_REG_RESOURCE_TAG_ID);
-- add the foreign key constraint back --
ALTER TABLE REG_RESOURCE_TAG ADD CONSTRAINT REG_RESOURCE_TAG_FK_BY_TAG_ID FOREIGN KEY (REG_TAG_ID, REG_TENANT_ID) REFERENCES REG_TAG (REG_ID, REG_TENANT_ID);
-- drop temporary table --
DROP TABLE TEMP_REG_RESOURCE_TAG_ID;
Безопасность¶
Поддержка логинов и паролей¶
В этом разделе объясняется, как изменить свои учетные данные, восстановить пароль и настроить свой вход.
Изменить учетные данные суперадминистратора
Чтобы изменить пароль администратора по умолчанию, следуйте инструкциям:
-
Перейдите к <APIM-HOME>/repository/conf/deployment.toml файлу и измените учетные данные пользователя, как показано ниже.
Примечание
Есть ли в вашем имени пользователя или пароле специальные символы?
- Вышеуказанные учетные данные применяются к соответствующим файлам конфигурации XML, таким как user-mgt.xml.
Если вы указываете пароли внутри XML-файлов, вам следует быть внимательным при определении специальных символов в именах пользователей и паролях. Согласно спецификации XML (https://www.w3.org/TR/xml/#sec-cdata-sect/), некоторые специальные символы могут нарушить конфигурацию. Например, символ амперсанда (&) не должен появляться в буквальной форме в XML-файлах. Это может вызвать исключение Java Null Pointer. Вы должны обернуть его с помощью CDATA, как показано ниже, или удалить символ:
-
Не используйте символ £ в пароле администратора, так как это может вызвать исключение переполнения буфера. Это происходит из-за ограничения, когда символ £ имеет два значения в качестве своего байтового представления.
-
Указанные выше учетные данные применяются к файлу jndi.properties.
-
Невозможно использовать @ { }символы в имени пользователя или пароле.
-
Также невозможно использовать знак процента (%) в пароле. При построении URL-адреса подключения анализируется URL-адрес с учетными данными. Это исключение анализа происходит, поскольку знак процента (%) действует как экранирующий символ при анализе URL-адреса. Если требуется знак процента (%) в строке подключения, используйте соответствующий символ кодировки для знака процента (%) в строке подключения. Например, если вам нужно передать adm%in в качестве пароля, то символ % должен быть закодирован соответствующим ему символом кодировки URL-адреса. Поэтому вам нужно отправить его как adm%25in. Список возможных шаблонов анализа URL-адресов см. в справочнике по кодировке URL-адресов . Добавьте следующую конфигурацию.
-
Поэтому, если у вас есть специальные символы, добавьте следующие конфигурации. Если у вас есть специальные символы, не забывайте заключать значения в тег CDATA в конфигурациях super_admin и кодировать значения в конфигурациях apim.throttling.jms.
[super_admin]
username = "your-name"
password = "<![CDATA[your-password]]>"
[apim.throttling.jms]
username = "your-name"
password = "your-encoded-password"
пример конфигурации deployment.toml
Примечание
Обратите внимание, что указанный выше пароль записывается в основное хранилище пользователей при первом запуске сервера. После этого пароль будет проверяться из основного хранилища пользователей, а не из файла конфигурации. Поэтому, если вам нужно изменить пароль администратора, сохраненный в хранилище пользователей, вы не можете просто изменить учетные данные, как указано выше. Чтобы изменить пароль суперадминистратора, вы должны использовать опцию Изменить пароль из консоли управления.
Настройте вход по электронной почте
-
Выполните «Аутентификация электронной почты».
-
Определите полное имя пользователя с доменом клиента в разделах файла, связанных с регулированием APIM <APIM-HOME>/repository/conf/deployment.toml.
Если вы находитесь в режиме суперарендатора, имя пользователя должно иметь следующий формат:
<email>@carbon.super
[tenant_mgt]
enable_email_domain= true
[apim.throttling]
username = "$ref{super_admin.username}@carbon.super"
[apim.throttling.policy_deploy]
username = "$ref{super_admin.username}@carbon.super"
[apim.throttling.jms]
username="admin!neomsa_apim.com!carbon.super"
password = "$ref{super_admin.password}"
- Следуйте инструкциям ниже, если вы включили регулярное выражение для проверки имен пользователей на шаге 1.
Вам необходимо вручную создать пользователя по умолчанию с действительным именем пользователя электронной почты вместо пользователя apim_reserved_user по умолчанию для каждого арендатора.
Этот пользователь является внутренним пользователем, созданным для обработки валидаций подписок между арендаторами. Поэтому, если вы включили функцию валидации подписок между арендаторами, вам необходимо настроить созданное выше имя пользователя в deployment.toml для поля default_reserved_username вместо пользователя apim_reserved_user по умолчанию, как показано ниже.
[user_store]
type = "database_unique_id"
username_java_regex = '^[a-zA-Z0-9.-]+@[a-zA-Z0-9.-]+.[a-zA-Z]{2,4}'
username_java_script_regex = '^[a-zA-Z0-9.-]+@[a-zA-Z0-9.-]+.[a-zA-Z]{2,4}$'
[apim.devportal]
enable_cross_tenant_subscriptions = true
default_reserved_username = "apim_reserved_user"
| Элемент | Описание |
|---|---|
| [tenant_mgt] enable_email_domain | Это свойство определяет, активирована ли аутентификация электронной почты. |
| [apim.throttling] username | Когда функция входа по электронной почте включена, суперарендатор будет прикреплен к имени пользователя. Это свойство облегчает последнее упомянутое требование. |
| [apim.throttling.policy_deploy] username | Укажите имя пользователя, необходимое для развертывания политик регулирования. |
| [apim.throttling.jms] username | Укажите имя пользователя в URL-адресе подключения JMS. Примечание Символ "@" является зарезервированным символом в компоненте обмена сообщениями NEOMSA. Поэтому при указании имени пользователя в URL-адресе подключения JMS в разделе apim.throttling.jms.username в файле <APIM-HOME>/repository/conf/deployment.toml символы "@" следует заменить на символ "!". Пример показан ниже. [apim.throttling.jms] username="admin!neomsa-apim.com!carbon.super" |
- Перезагрузите сервер.
пример конфигурации deployment.toml
[tenant_mgt]
enable_email_domain= true
[super_admin]
username = "admin@neomsa_apim.com"
password = "admin"
create_admin_account = true
[apim.throttling]
username = "admin@neomsa_apim.com@carbon.super"
[apim.throttling.jms]
username = "admin!neomsa_apim.com!carbon.super"
[user_store]
type = "database_unique_id"
username_java_regex = '^[a-zA-Z0-9.-]+@[a-zA-Z0-9.-]+.[a-zA-Z]{2,4}'
username_java_script_regex = '^[a-zA-Z0-9.-]+@[a-zA-Z0-9.-]+.[a-zA-Z]{2,4}$'
[apim.devportal]
enable_cross_tenant_subscriptions = true
default_reserved_username = "default@neomsa_apim.com"
Настройка хранилища ключей в APIM¶
Продукты NEOMSA используют асимметричную криптографию по умолчанию для аутентификации и шифрования данных. В асимметричной криптографии хранилища ключей (с парами ключей и сертификатами) создаются и хранятся для продукта. Хранилище ключей — это репозиторий, где могут храниться закрытые ключи и сертификаты. Можно иметь несколько хранилищ ключей, чтобы ключи, используемые для разных вариантов использования, оставались уникальными.
В NEOMSA APIM используются три различных хранилища ключей.
-
Первичное хранилище ключей
-
Вторичное хранилище ключей (подключения TLS)
-
Внутреннее хранилище ключей
Первичное хранилище ключей используется для подписи и шифрования данных, которые открыты извне. Примерами использования являются подпись ответа SAML, подпись токена OAuth ID и подпись JWT.
Вторичное хранилище ключей используется для аутентификации связи через SSL/TLS. Оно используется в различных транспортах, используемых NEOMSA API Manager, включая транспорт сервлетов (используется для веб-приложений), транспорт Synapse (используется в шлюзе), thrift, binary и JMS.
Внутреннее хранилище ключей используется для шифрования внутренних критически важных данных, включая пароли и другую конфиденциальную информацию в файлах конфигурации.
Файл хранилища ключей wso2carbon.jks, который поставляется со всеми продуктами NEOMSA, используется как хранилище ключей по умолчанию для всех функций. Однако в производственной среде рекомендуется создавать новые хранилища ключей с новыми ключами и сертификатами. Если вы создали новое хранилище ключей и обновили файл client-truststore.jks, вам необходимо обновить файл <APIM-HOME>/repository/conf/deployment.toml, чтобы хранилище ключей заработало.
Информация Если вы хотите изменить данные хранилища доверенных сертификатов по умолчанию, вы можете сделать это, добавив конфигурации в поле [truststore] в <APIM-HOME>/repository/conf/deployment.toml. Ознакомьтесь с примером ниже, который определяет хранилище доверенных сертификатов type как «JKS» (Java KeyStore), хранилище доверенных сертификатов file_name как «modified-client-truststore.jks» и password как «modified_password».
Важно
При изменении пароля ключа и пароля хранилища ключей необходимо обязательно обновить следующие конфигурации в deployment.toml, чтобы избежать ошибок, связанных с хранилищем ключей.
[keystore.tls]
file_name = "wso2carbon.jks"
type = "JKS"
password = "<password1>"
alias = "wso2carbon"
key_password = "<password1>"
[keystore.primary]
file_name = "wso2carbon.jks"
type = "JKS"
password = "<password1>"
alias = "wso2carbon"
key_password = "<password1>"
[keystore.internal]
file_name = "wso2carbon.jks"
type = "JKS"
password = "<password1>"
alias = "wso2carbon"
key_password = "<password1>"
Настройка первичного хранилища ключей
По умолчанию первичное хранилище ключей настроено с помощью wso2carbon.jks. Чтобы настроить первичное хранилище ключей, откройте <APIM-HOME>/repository/conf/deployment.toml и добавьте указанные ниже конфигурации.
[keystore.primary]
file_name = "keystore.jks"
type = "JKS"
password = "passwd12#"
alias = "mydomain"
key_password = "passwd12#"
Элементы вышеуказанной конфигурации описаны ниже:
| Элемент | Описание |
|---|---|
| file_name | Имя файла хранилища ключей. Файл должен быть расположен в <APIM-HOME>/repository/resources/security |
| type | Тип хранилища ключей. Поддерживаемые типы хранилищ ключей: JKS и PKCS12 |
| password | Пароль хранилища ключей |
| alias | алиас приватного ключа |
| key_password | Пароль приватного ключа |
Важно
Ваш пароль закрытого ключа (key_password) и пароль хранилища ключей (password) должны быть одинаковыми. Это связано с ограничением некоторых внутренних компонентов, используемых NEOMSA APIM .
По умолчанию первичное хранилище ключей, настроенное, как указано выше, используется для внутреннего шифрования данных (шифрования данных во внутренних хранилищах данных и файлах конфигурации), а также для подписи сообщений, которые передаются внешним сторонам. Другими словами, если мы определим только первичное хранилище ключей, оно будет использоваться как вторичное хранилище ключей (TLS) и внутреннее хранилище ключей. Однако иногда бывает необходимо иметь отдельные хранилища ключей для соединений SSL/TSL, обмена сообщениями с внешними сторонами (например, JWT, SAML, подписание OIDC id_token) и для шифрования информации во внутренних хранилищах данных. Это связано с тем, что для подписи сообщений и внешних коммуникаций сертификаты хранилища ключей необходимо часто обновлять. Однако для шифрования информации во внутренних хранилищах данных сертификаты хранилища ключей не следует часто менять, поскольку уже зашифрованные данные станут непригодными для использования каждый раз при изменении сертификата.
Настройка вторичного хранилища ключей для TLS-подключений
Чтобы настроить отдельное хранилище ключей в качестве вторичного хранилища ключей, добавьте указанные ниже конфигурации в deployment.toml.
[keystore.tls]
file_name = "tls_keystore.jks"
type = "JKS"
password = "passwd12#"
alias = "mydomain"
key_password = "passwd12#"
Настройка внутреннего хранилища ключей
Настройка отдельного внутреннего хранилища ключей позволяет вам сохранять сертификат, используемый для этих шифрований, неизменным, в то время как сертификат, используемый для подписи, изменяется. Для этого добавьте следующие конфигурации в deployment.toml.
[keystore.internal]
file_name = "internal_keystore.jks"
type = "JKS"
password = "passwd12#"
alias = "mydomain"
key_password = "passwd12#"
Предупреждение
Использование совершенно нового хранилища ключей для внутреннего шифрования данных в существующем развертывании сделает уже зашифрованные данные недоступными. В таких случаях потребуется соответствующая миграция данных. Следовательно, если вы уже некоторое время использовали одно и то же хранилище ключей как для первичного, так и для внутреннего хранилища ключей, а затем решили использовать отдельное внутреннее хранилище ключей, используйте текущее хранилище ключей для внутреннего хранилища ключей и вместо этого используйте новое хранилище ключей для первичного хранилища ключей. Это позволяет избежать ненужной миграции данных.
[keystore.primary]
file_name = "new_keystore.jks"
type = "JKS"
password = "passwd12#"
alias = "mydomain"
key_password = "passwd12#"
[keystore.internal]
file_name = "existing_keystore.jks"
type = "JKS"
password = "passwd12#"
alias = "mydomain"
key_password = "passwd12#"
Рекомендации по настройке хранилищ ключей
При настройке хранилищ ключей следуйте приведенным ниже рекомендациям.
-
Поддерживайте одно основное хранилище ключей для шифрования конфиденциальных внутренних данных, таких как пароли администратора и любая другая конфиденциальная информация, обнаруженная как на уровне продукта, так и на уровне функций продукта в файлах конфигурации/конфигурации. Обратите внимание, что основное хранилище ключей также будет использоваться для подписи сообщений, когда продукт взаимодействует с внешними сторонами (например, SAML, OIDC id_token signing).
-
Рекомендуется иметь отдельные хранилища ключей для шифрования конфиденциальных внутренних данных/информации.
-
Поддерживайте еще одно вторичное хранилище ключей, содержащее сертификат открытого ключа сервера для аутентификации связи по протоколу SSL/TLS (для HTTP-подключений как уровня Tomcat, так и уровня Axis2).
-
Если ваше развертывание содержит несколько продуктов, экземпляры одного и того же продукта должны использовать одно и то же хранилище ключей для SSL. Разные продукты могут использовать разные хранилища ключей для SSL, но это не обязательно.
-
Рекомендуется использовать хранилище ключей с сертификатом от центра сертификации (CA) для связи по SSL; однако это не обязательно. Даже самоподписанный сертификат может быть достаточным, если ему доверяют клиенты
-
Хранилище ключей, используемое для SSL, должно содержать тот же пароль для хранилища ключей и закрытого ключа.
-
Внутреннее хранилище ключей может быть самоподписанным. Использование хранилища ключей с сертификатом от CA не имеет смысла для этой цели, поскольку оно не используется для какой-либо внешней коммуникации.
-
Публичный ключ сертификата основного хранилища должен иметь назначение "Data Encipherment" (шифрование данных), чтобы позволить прямое шифрование необработанных данных с использованием его публичного ключа. Это назначение уже включено в самоподписанный сертификат, который содержится в стандартном хранилище wso2carbon.jks. Если назначение "Data Encipherment" отсутствует в вашем публичном ключе, при попытке шифрования данных может возникнуть следующая ошибка:
Exception in thread "main" org.wso2.ciphertool.CipherToolException: Error initializing Cipher at org.wso2.ciphertool.CipherTool.handleException(CipherTool.java:861) at org.wso2.ciphertool.CipherTool.initCipher(CipherTool.java:202) at org.wso2.ciphertool.CipherTool.main(CipherTool.java:80) Caused by: java.security.InvalidKeyException: Wrong key usage at javax.crypto.Cipher.init(DashoA13..) at javax.crypto.Cipher.init(DashoA13..) at org.wso2.ciphertool.CipherTool.initCipher(CipherTool.java:200) ... 1 more -
Если у вас уже есть необходимые хранилища ключей для вашего продукта, вы можете сгенерировать сертификаты, подписанные CA, и импортировать их в хранилище ключей. Не рекомендуется создавать новые хранилища ключей с целью замены сертификатов в хранилище ключей.
-
Если вы столкнулись со следующей ошибкой после изменения хранилища ключей по умолчанию, войдите в консоль Carbon, перейдите в местоположение реестра /_system/config/repository/esb/inbound и удалите ресурс inbound-endpoints. После удаления перезапустите сервер.
Включение проверки имени хоста¶
Если проверка имени хоста отключена для вашего продукта, имена хостов (к которым обращается определенный клиент) не будут проверяться на соответствие именам хостов, указанным в сертификате SSL-сертификате продукта. Если проверка имени хоста включена, вы сможете настроить, как фильтруются имена хостов во время процесса проверки.
Примечание Важно! Обязательно включите проверку имени хоста для вашей производственной среды. Это необходимо для предотвращения проблем безопасности в производственной среде.
Настройка проверки имени хоста
Проверка имени хоста отключена по умолчанию. Это делается с помощью свойств org.opensaml.httpclient.https.disableHostnameVerification и httpclient.hostnameVerifier в скрипте запуска продукта (api-manager.sh для Linux и api-manager.bat для Windows), как показано ниже. Скрипт запуска продукта хранится в каталоге <APIM-HOME>/bin. Это свойство будет действовать во время запуска сервера.
-Dorg.opensaml.httpclient.https.disableHostnameVerification=true \
-Dhttpclient.hostnameVerifier=AllowAll \
Строгая проверка имени хоста
При применении строгой проверки имени хоста необходимо изменить конфигурацию в файле портала site/public/conf/settings.js издателя и администратора, а также в файле site/public/theme/setting.js портала разработчика.
Примечание
Значения, которые вы можете использовать с этим свойством httpclient.hostnameVerifier, объясняются ниже. Обратите внимание, что эти значения будут вести себя так же, как параметры проверки имени хоста Synapse.
- DefaultAndLocalhost: Это значение включено по умолчанию. Это означает, что все имена хостов, за исключением перечисленных ниже, будут проверены на соответствие именам хостов, указанным в сертификате SSL продукта. То есть, следующие имена хостов будут разрешены независимо от сертификата сервера.
локальный хост
localhost.localdomain
127.0.0.1
::1
Обратите внимание, что если подстановочный символ используется для указания имени хоста в сертификате SSL (например, *. foo.com), все поддомены *. foo.com также включаются. Это имя хоста, которое соответствует поддомену *. foo.com, также будет разрешено для доступа.
-
Strict: Когда этот режим включен, имена хостов будут строго проверяться на соответствие имени хоста, указанному в сертификате SSL продукта. Например, если в качестве имени хоста в сертификате указано "*.foo.com", то только имена хостов на том же уровне будут авторизованы сервером. То есть такие поддомены, как «a.b.foo.com», не будут авторизованы.
-
AllowAll: эта опция отключает проверку имени хоста для сервера. Обратите внимание, что это не рекомендуется в производственной настройке и должно использоваться только для демонстраций и тестирования.
Настройка проверки имени хоста для WebSockets
Проверка имени хоста WebSocket включена по умолчанию. Чтобы отключить проверку имени хоста для WebSockets, необходимо добавить следующую конфигурацию в файл deployment.toml в директории <APIM-HOME>/repository/conf.
Включение диспетчера безопасности Java (Java Security Manager)¶
Внимание
Java Security Manager объявлен устаревшим начиная с JDK 17 и отключён начиная с JDK 24. На JDK 21 он ещё работает, но при запуске выводит предупреждения. Включайте его, только если этого требуют политики безопасности вашей организации.
Java Security Manager используется для определения различных политик безопасности, которые предотвращают выполнение ненадежного кода в вашей системе. Включение Java Security Manager для продуктов NEOMSA активирует разрешения Java, которые находятся в файле <APIM-HOME>/repository/conf/sec.policy. Вы изменяете этот файл, чтобы изменить разрешения безопасности Java по мере необходимости.
Прежде чем начать
-
Убедитесь, что у вас установлена Java 11.
-
Обратите внимание, что вам необходимо использовать хранилище ключей для подписи JAR-файлов с помощью менеджера безопасности Java. В этом примере вы будете использовать хранилище ключей по умолчанию в вашем продукте NEOMSA (wso2carbon.jks).
Ниже показано, как включить Java Security Manager для продуктов NEOMSA.
-
Загрузите продукт NEOMSA в любое место (например в папку, <APIM-HOME>/user/<product-pack>).
-
Запустите скрипт запуска в папке <APIM-HOME>/bin. Для Linux это api-manager.sh. После того, как продукт будет запущен и заработает, выключите сервер.
-
Чтобы подписать JAR-файлы в вашем продукте, вам нужен ключ. Вы можете сгенерировать новое хранилище ключей (с новым ключом), выполнив команду keytool, указанную ниже. Обратите внимание, что новое хранилище ключей создается в каталоге, из которого вы выполняете команду keytool.
Теперь у вас есть новое хранилище ключей (signkeystore.jks) с новым сертификатом открытого ключа (signFiles).
- По умолчанию продукты NEOMSA используют wso2carbon.jks хранилище ключей по умолчанию для подписи JAR-файлов. Это хранилище ключей хранится в каталоге <APIM-HOME>/repository/resources/security. Поэтому вам необходимо добавить сертификат signFiles открытого ключа, который вы создали ранее, в хранилище ключей wso2carbon.jks.
Сначала экспортируйте сертификат signFiles открытого ключа из хранилище ключей signkeystore.jks, выполнив следующую команду:
Затем импортируйте тот же сертификат signFiles в хранилище ключей wso2carbon.jks, выполнив команду, указанную ниже. Обязательно укажите правильный путь к каталогу файла вашего продукта wso2carbon.jks.
$ keytool -import -alias signFiles -file sign-cert.cer -keystore <PATH_to_APIM-HOME>/repository/resources/security/wso2carbon.jks
Enter keystore password:
Owner: CN=John, OU=Engineering, O=NEOMSA_APIM, L=Colombo, ST=Western, C=LK
Issuer: CN=John, OU=Engineering, O=NEOMSA_APIM, L=Colombo, ST=Western, C=LK
Serial number: 5486f3b0
Valid from: Tue Dec 09 18:35:52 IST 2014 until: Fri Dec 06 18:35:52 IST 2024
Certificate fingerprints:
MD5: 54:13:FD:06:6F:C9:A6:BC:EE:DF:73:A9:88:CC:02:EC
SHA1: AE:37:2A:9E:66:86:12:68:28:88:12:A0:85:50:B1:D1:21:BD:49:52
Signature algorithm name: SHA1withRSA
Version: 3
Trust this certificate? [no]: yes
Certificate was added to keystore
Примечание Обратите внимание, что NEOMSA больше не рекомендует использовать MD5 для подписи JAR из-за криптографических ограничений.
- Подготовьте скрипты для подписи JAR-файлов и предоставьте им требуемое разрешение (например, sudo chmod 755 signJar.sh). Например скрипт, signJar.sh, приведенный ниже, можно использовать для подписи каждого JAR-файла по отдельности, или вы можете использовать скрипт signJars.sh, который запускает цикл для чтения всех JAR-файлов и их подписи.
скрипт signJar.sh
#!/bin/bash
set -e
jarfile=$1
keystore_file="signkeystore.jks"
keystore_keyalias='signFiles'
keystore_storepass='neomsa123'
keystore_keypass='neomsa123'
signjar="$JAVA_HOME/bin/jarsigner -keystore $keystore_file -storepass $keystore_storepass -keypass $keystore_keypass"
verifyjar="$JAVA_HOME/bin/jarsigner -keystore $keystore_file -verify"
echo "Signing $jarfile"
$signjar $jarfile $keystore_keyalias
echo "Verifying $jarfile"
$verifyjar $jarfile
# Check whether the verification is successful.
if [ $? -eq 1 ]
then
echo "Verification failed for $jarfile"
fi
скрипт signJars.sh
#!/bin/bash
if [[ ! -d $1 ]]; then
echo "Please specify a target directory"
exit 1
fi
for jarfile in `find . -type f -iname \*.jar`
do
./signJar.sh $jarfile
done
-
Выполните следующие команды, чтобы подписать JAR-файлы в вашем продукте:
Примечание Каждый раз, когда вы добавляете внешний JAR в продукт NEOMSA, подписывайте их вручную, используя приведенные выше инструкции, чтобы Java Security Manager был эффективным. Вы добавляете внешние JAR на сервер при расширении продукта, применении патчей и т. д.
-
Откройте скрипт запуска в папке <APIM-HOME>/bin. Для Linux это api-manager.sh.
-
Добавьте следующие системные свойства в скрипт запуска и сохраните файл. Добавьте их перед строкой org.wso2.carbon.bootstrap.Bootstrap $*.
-Djava.security.manager=org.wso2.carbon.bootstrap.CarbonSecurityManager \ -Djava.security.policy=$CARBON_HOME/repository/conf/sec.policy \ -Drestricted.packages=sun.,com.sun.xml.internal.ws.,com.sun.xml.internal.bind.,com.sun.imageio.,org.wso2.carbon. \ -Ddenied.system.properties=javax.net.ssl.trustStore,javax.net.ssl.trustStorePassword,denied.system.properties \ -
Создайте файл sec.policy с требуемыми политиками безопасности в папке <APIM-HOME>/repository/conf и запустите сервер. Запуск сервера вводит sec.policy в действие разрешения Java, определенные в файле.
Пример файла sec.policy приведен ниже. Он включает в себя в основном разрешения уровня NEOMSA Carbon.
keystore "file:${user.dir}/repository/resources/security/wso2carbon.jks", "JKS";
grant {
permission java.net.SocketPermission "*:1-65535", "connect,resolve";
permission java.lang.RuntimePermission "accessClassInPackage.org.wso2.carbon.context";
permission java.lang.RuntimePermission "accessClassInPackage.org.wso2.carbon.registry.api";
permission java.lang.RuntimePermission "accessClassInPackage.org.wso2.carbon.registry.core";
permission java.lang.RuntimePermission "accessClassInPackage.org.wso2.carbon.user.api";
permission java.lang.RuntimePermission "accessClassInPackage.org.wso2.carbon.user.core";
permission java.lang.RuntimePermission "accessClassInPackage.org.wso2.carbon.authenticator.stub";
permission java.lang.RuntimePermission "accessClassInPackage.org.wso2.carbon.core.common";
permission java.lang.management.ManagementPermission "control";
permission java.lang.RuntimePermission "getClassLoader";
permission java.lang.RuntimePermission "setContextClassLoader";
permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
permission java.lang.RuntimePermission "accessDeclaredMembers";
permission java.util.PropertyPermission "*", "read";
permission java.lang.RuntimePermission "accessClassInPackage.sun.misc";
permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util";
permission java.lang.RuntimePermission "modifyThreadGroup";
permission java.io.FilePermission "*", "read";
};
grant signedBy "signfiles" {
permission java.security.AllPermission;
};
grant codeBase "file:${user.dir}/repository/deployment/server/-" {
permission java.security.AllPermission;
};
grant signedBy "signfiles", codeBase "file:${user.dir}/bin/" {
permission java.security.AllPermission;
};
grant codeBase "file:${java.home}/lib/-" {
permission java.security.AllPermission;
};
grant codeBase "file:${java.home}/jre/lib/ext/-" {
permission java.security.AllPermission;
};
grant codeBase "file:${java.home}/../lib/-" {
permission java.security.AllPermission;
};
grant codeBase "file:${java.home}/lib/ext/-" {
permission java.security.AllPermission;
};
grant codeBase "file:${java.home}/../lib/-" {
permission java.security.AllPermission;
};
grant codeBase "file:${java.home}/lib/ext/-" {
permission java.security.AllPermission;
};
Настройка безопасности на транспортном уровне¶
Ниже приведены различные конфигурации безопасности транспортного уровня, которые требуются для NEOMSA APIM .
Отключение слабых шифров
Шифр — это алгоритм для выполнения шифрования или дешифрования. Когда вы устанавливаете sslprotocol TLS для своего сервера, TLS и шифры по умолчанию включаются без учета стойкости шифров. Это представляет собой риск безопасности, поскольку слабые шифры, также известные как EXPORT- шифры, могут сделать вашу систему уязвимой для атак, таких как атака Logjam на обмен ключами Diffie-Hellman. Атака Logjam также называется атакой Man-in-the-Middle. Она понижает шифрование вашего соединения до менее защищенного уровня (например, 512 бит), который можно расшифровать с достаточной вычислительной мощностью.
Чтобы предотвратить эти типы атак, рекомендуется отключить слабые шифры. Вы можете включить только те шифры, которые вы хотите, чтобы сервер поддерживал, указав их в виде списка через запятую в атрибуте ciphers. Также, если вы не добавите этот атрибут или оставите его пустым, браузер будет поддерживать все шифры SSL от JSSE. Это включит слабые шифры.
Отключение слабых шифров для транспорта Tomcat
-
Откройте файл <APIM-HOME>/repository/conf/deployment.toml.
-
Сделайте резервную копию файла deployment.toml и остановите сервер Carbon.
-
Добавьте в файл следующую конфигурацию deployment.toml, добавив список шифров, которые должен поддерживать ваш сервер, следующим образом: ciphers=",".
[transport.https.sslHostConfig.properties] ciphers="TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384, TLS_DHE_DSS_WITH_AES_256_GCM_SHA384, TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_DSS_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_DHE_DSS_WITH_AES_256_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_DSS_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, TLS_ECDH_ECDSA_WITH_RC4_128_SHA, TLS_ECDH_RSA_WITH_RC4_128_SHA, TLS_EMPTY_RENEGOTIATION_INFO_SCSV" -
Запустите сервер.
-
Чтобы убедиться, что все конфигурации настроены правильно, загрузите и запустите testsslserver.jar.
Примечание
При запуске обратите внимание на следующее testsslserver.jar:
- Раздел «Поддерживаемые наборы шифров» в выходных данных не содержит ЭКСПОРТНЫХ шифров.
- При использовании поддерживаемых наборов шифров статус атаки BEAST будет отображаться как уязвимый. Обратите внимание, что это уязвимость на стороне клиента, вызванная протоколом TLSv1. Вы можете сделать статус BEAST защищенным, удалив TLSv1, что сделает клиентов с TLSv1 непригодными для использования. Поэтому рекомендуется исправить это со стороны клиента.
```bash
$ java -jar testsslserver.jar localhost 9443
```
Информация. Начиная с Firefox 39.0, браузер не позволяет получать доступ к веб-сайтам, поддерживающим DHE с ключами менее 1023 бит (не только DHE_EXPORT). 768/1024 бит считаются слишком маленькими и уязвимыми для атак, если у хакера достаточно вычислительных ресурсов.
Примечание.
-
Для использования AES-256 необходимо установить файлы Java JCE Unlimited Strength Jurisdiction Policy. Загрузите их с http://www.oracle.com/technetwork/java/javase/downloads/index.html, если в вашей установке Java они не установлены.
-
Начиная с Java 7, необходимо установить свойство jdk.certpath.disabledAlgorithms в файле <JAVA_HOME>/jre/lib/security/java.security на jdk.certpath.disabledAlgorithms=MD2, DSA, RSA keySize < 2048. Он отклоняет все алгоритмы с размером ключа менее 2048 для MD2, DSA и RSA.
Настройка шифров транспортного уровня PassThrough и версий TLS
- Чтобы включить предпочтительные шифры, добавьте в файл конфигурацию, указанную ниже <APIM-HOME>/repository/conf/deployment.toml.
Формат
[transport.passthru_https.listener.parameters]
PreferredCiphers = "<CIPHER_LIST>"
Пример
[transport.passthru_https.listener.parameters]
PreferredCiphers = "TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384"
- Чтобы включить протоколы HTTP (версии TLS), добавьте в файл конфигурации, указанные ниже <APIM-HOME>/repository/conf/deployment.toml.
Формат
[transport.passthru_https.listener.parameters]
HttpsProtocols = "<TLS_VERSION_LIST>"
Пример
[transport.passthru_https.listener.parameters]
HttpsProtocols = "TLSv1.2,TLSv1.3"
Изменение имени сервера в заголовках HTTP-ответа
По умолчанию все продукты NEOMSA передают "NEOMSA APIM Carbon Server" в качестве значения сервера в заголовках HTTP при отправке ответов HTTP. Это означает, что информация о стеке продуктов NEOMSA будет раскрыта через ответы HTTP. Рекомендуется изменить это, настроив имя сервера в файле deployment.toml.
-
Откройте файл <APIM-HOME>/repository/conf/deployment.toml.
-
Добавьте новое имя сервера, используя свойство server (в соответствующей конфигурации коннектора Tomcat):
Примечание. Рекомендуется отключить HTTP-транспорт в производственной настройке API Manager. Использование токена Bearer через HTTP является нарушением спецификации OAuth и может привести к уязвимостям безопасности.
API Manager имеет два HTTP-транспорта.
-
Passthru (API-трафик) Транспорт
-
Servlet (трафик пользовательского интерфейса и доступ к службе администратора) Транспорт
Чтобы отключить эти транспорты, смотрите приведенные ниже инструкции.
Отключение сквозного транспорта
Добавьте следующую конфигурацию в файл deployment.toml (хранится в папке <APIM-HOME>/repository/conf).
Примечание. Закомментируйте или удалите запись http_endpoint в файле deployment.toml (хранится в папке <APIM-HOME>/repository/conf). Это делается для того, чтобы избежать ошибки, которая возникает при добавлении указанной выше конфигурации.
[[apim.gateway.environment]]
name = "Default"
type = "hybrid"
display_in_api_console = true
description = "This is a hybrid gateway that handles both production and sandbox token traffic."
show_as_token_endpoint_url = true
service_url = "https://localhost:${mgt.transport.https.port}/services/"
username= "${admin.username}"
password= "${admin.password}"
ws_endpoint = "ws://[api-gateway-host]:9099"
wss_endpoint = "wss://[api-gateway-host]:8099"
http_endpoint = "http://[api-gateway-host]:${http.nio.port}"
https_endpoint = "https://[api-gateway-host]:${https.nio.port}"
Отключение транспорта servlet
Добавьте следующую конфигурацию в файл deployment.toml (хранится в папке <APIM-HOME>/repository/conf).
Добавьте следующую конфигурацию в файл deployment.toml (хранится в папке <APIM-HOME>/repository/conf).
Добавьте следующую конфигурацию в файл deployment.toml (хранится в папке <APIM-HOME>/repository/conf).
Управление учетными записями пользователей¶
В данном разделе объясняется, как управлять учетными записями пользователей, связанными с порталом разработчика, издателя и порталом администратора.
Включить восстановление пароля
Функция восстановления пароля не работает из коробки, поскольку необходимо настроить сервер электронной почты для отправки письма о восстановлении пароля. Обратите внимание, что вам необходимо создать пароль приложения специально для использования этой функции. Действия для этого приведены в таблице ниже.
Чтобы включить функцию восстановления пароля для портала разработчика, издателя и портала администратора, выполните следующие действия:
-
Выключите сервер, если он работает.
-
Откройте файл <APIM-HOME>/repository/conf/deployment.toml.
-
Добавьте следующие свойства для настройки почтового сервера.
| Свойство | Описание |
|---|---|
| from_address | Адрес электронной почты, который вы используете для отправки писем. |
| username | Адрес электронной почты, используемый для аутентификации почтового сервера. Это может быть тот же адрес электронной почты, что и from_address. |
| password | Пароль приложения, используемый для аутентификации почтового сервера. Следуйте инструкциям здесь, чтобы создать его. |
| signature | Подпись отправителя счета. |
- Перезапустите сервер.
Блокировка аккаунта
Вы можете заблокировать учетные записи пользователей с помощью функции восстановления учетных записей и управления учетными данными, предустановленной в NEOMSA API Manager. Блокировка учетных записей применима к учетным записям пользователей, связанным с Developer Portal, Publisher и Admin Portal.
Блокировка учетной записи из-за неудачных попыток входа в систему
Следующие шаги показывают, как включить блокировку учетной записи.
-
Войдите в консоль управления (https://<API-M_HOST>:<API-M_PORT>/carbon), используя учетные данные администратора.
-
Нажмите Resident в разделе Identity Providers на вкладке «Главная» .
-
Разверните вкладку «Login Attempts Security» .
-
Разверните вкладку Account Lock и отметьте галочкой опцию Lock user accounts on maximum failed attempts . Нажмите Update, чтобы сохранить изменения.
Информация. Если вы настроили модуль отправки электронной почты, и если адрес электронной почты заблокированного пользователя указан в его профиле правильно, он/она получит электронное письмо с сообщением о том, что учетная запись заблокирована.
- После разблокировки учетной записи вам будет отправлено еще одно электронное письмо.
Блокировка учетной записи администратором
Административный пользователь может заблокировать и разблокировать учетную запись конкретного пользователя через консоль управления.
-
Войдите в консоль управления (https://<API-M_HOST>:<API-M_PORT>/carbon), используя учетные данные администратора.
-
Перейдите в раздел «Claims» > «Список» на главной вкладке выберите http://wso2.org/claims.
-
Разверните заявку «Account Locked» и нажмите «Edit» .
- Установите чекбокс Supported by Default и нажмите Update . Это делается для того, чтобы в профиле пользователя появился статус «Account Locked» .
-
Перейдите в раздел Users and Roles > Список > Users в главном меню и нажмите на Профиль пользователя, которого вы хотите заблокировать.
-
Установите флажок напротив поля «Account Locked» , чтобы заблокировать учетную запись для пользователя, и нажмите «Update».
Политика паролей
Изменить политику паролей
Вы можете определить свою собственную политику паролей для порталов разработчиков, издателей и администраторов, определив один или оба из следующих параметров.
Пароль для хранения пользователя RegEx
Пример:
[user_store]
type = "database_unique_id"
[user_store.properties]
PasswordJavaRegEx = "^[\\S]{6,30}$"
Политики паролей управления идентификацией
Вы можете определить пользовательские политики паролей для портала разработчиков, регистрации пользователей издателя. Откройте файл <APIM-HOME>/repository/conf/deployment.toml и добавьте конфигурацию политики паролей на основе ваших предпочтений, как показано ниже.
[identity_mgt.events.schemes]
passwordPolicy.properties.enable = true
passwordPolicy.properties.'min.length' = 4
passwordPolicy.properties.'max.length' = 10
passwordPolicy.properties.pattern = "^((?=.*\\\\d)(?=.*[a-z])(?=.*[A-Z])(?=.*[!@#$%&*])).{0,100}$"
passwordPolicy.properties.errorMsg = "Password pattern policy violated. Password should contain a digit[0-9], a lower case letter[a-z], an upper case letter[A-Z], one of !@#$%&* characters"
passwordPolicy.properties.'class.PasswordLengthPolicy' = "org.wso2.carbon.identity.mgt.policy.password.DefaultPasswordLengthPolicy"
passwordPolicy.properties.'class.PasswordNamePolicy' = "org.wso2.carbon.identity.mgt.policy.password.DefaultPasswordNamePolicy"
passwordPolicy.properties.'class.PasswordPatternPolicy' = "org.wso2.carbon.identity.mgt.policy.password.DefaultPasswordPatternPolicy"
Примечание
-
Политику паролей, установленную политиками паролей управления идентификацией через файл конфигурации, можно переопределить с помощью консоли управления для каждого арендатора.
-
При смене пароля новый пароль будет проверен на соответствие паролю хранилища пользователя RegEx и условиям, налагаемым политикой паролей Identity Management. Поэтому вы не сможете изменить свой пароль, если эти условия/шаблоны RegEx установлены таким образом, что они конфликтуют друг с другом.
Отображение рекомендаций по политике паролей на портале разработчиков
Список правил политики можно отобразить на странице изменения пароля, которая появляется на портале разработчиков.
-
Включить инструкции по смене пароля в файле settings.json.
-
Откройте файл <APIM-HOME>/repository/deployment/server/webapps/devportal/site/public/theme/settings.json.
-
Отредактируйте конфигурацию следующим образом:
-
-
Перечислите свои индивидуальные рекомендации ниже policyList.
Примечание. Если список рекомендаций пуст, в пользовательском интерфейсе смены пароля не будет отображаться раздел рекомендаций по политике паролей.
Отключение анонимного доступа к порталу разработчиков
По умолчанию анонимный доступ к порталу разработчика включен. Поэтому пользователям не нужно проходить аутентификацию путем входа в систему при доступе к порталу разработчика в NEOMSA APIM . Однако при необходимости вы можете отключить анонимный доступ к порталу разработчика, чтобы запретить анонимным пользователям доступ к порталу разработчика. Если анонимный доступ отключен, пользователям не будет разрешен доступ к пользовательскому интерфейсу портала разработчика без соответствующих данных для входа или токена доступа.
Чтобы отключить анонимный доступ к порталу разработчиков для конкретного арендатора, следуйте инструкциям ниже:
- Войдите в консоль администратора NEOMSA API-M как администратор клиента.
https://<API-M_host>:<API-M_port>/admin
-
Перейдите в Settings > Advanced.
-
Добавьте поле с именем EnableAnonymous и значением, false как показано ниже.
Примечание. Чтобы глобально отключить анонимный доступ, добавьте в файл следующее <APIM-HOME>/repository/conf/deployment.toml.
-
Перезагрузите сервер или подождите 15 минут, пока не истечет срок действия кэша реестра.
-
Перейдите на портал разработчиков.
https://<APIM_host>:<APIM_port>/devportal
Если вы ранее не прошли аутентификацию, войдя на портал разработчиков, вы будете автоматически перенаправлены на страницу входа.
Информация. Если у вас многопользовательская среда, то при переходе на https://<APIM_host>:<APIM_port>/devportal, вам будет предложено сначала выбрать арендатора. При выборе арендатора, если для этого арендатора отключен анонимный режим (выполнив указанные выше шаги), вы будете перенаправлены на страницу входа, если вы ранее не аутентифицировали себя, войдя в Developer Portal.
Обеспечение безопасности веб-порталов¶
Среда выполнения NEOMSA APIM содержит следующие веб-порталы/приложения: Консоль управления, API Publisher и Портал разработчиков. Ознакомьтесь с приведенными ниже темами, чтобы настроить эти порталы для лучшей безопасности перед их использованием.
Обновить SSL-сертификаты
Веб-порталы APIM основаны на протоколе HTTPS, который является комбинацией протоколов HTTP и SSL. Этот протокол обычно используется для шифрования трафика от клиента к серверу в целях безопасности.
Сертификат SSL по умолчанию этих веб-порталов используется только для шифрования и не подтверждает подлинность сервера. Поэтому при попытке доступа к этим порталам обычно отображается предупреждение о ненадежном соединении. Чтобы получить доступ к порталам с использованием этого сертификата по умолчанию, сначала следует «принять» сертификат.
Если вы используете браузер Mozilla Firefox, то требуется принять сертификат в первый раз, после чего сертификат сохраняется в базе данных браузера и помечается как доверенный. В других браузерах предупреждение о небезопасном соединении может отображаться каждый раз при доступе к серверу.
Вы можете использовать сертификат по умолчанию для тестирования или для запуска веб-порталов во внутренних сетях вашей компании. Если вы хотите сделать эти порталы доступными для внешних пользователей, ваша организация должна получить сертификат, подписанный известным центром сертификации, который подтверждает, что сервер имеет имя, с которого к нему осуществляется доступ, и что этот сервер принадлежит данной организации.
Настройка тайм-аута сеанса
Если вы оставите консоль управления без присмотра на определенное время, сеанс входа в систему истечет. Значение тайм-аута по умолчанию составляет 15 минут, но вы можете изменить его, добавив следующие конфигурации в deployment.toml (хранится в папке <APIM-HOME>/repository/conf/):
Вы можете настроить время ожидания сеанса для других веб-порталов ( портал издателя и разработчика), изменив следующую конфигурацию в deployment.toml (хранится в папке <APIM-HOME>/repository/conf/):
Вы можете ограничить доступ к консоли управления среды выполнения APIM, связав консоль управления с выбранными IP-адресами. Обратите внимание, что вы можете ограничить доступ только к консоли управления или ограничить доступ ко всем веб-порталам, как описано ниже.
-
Чтобы контролировать доступ только к консоли управления, добавьте в файл следующую конфигурацию <APIM-HOME>/repository/conf/deployment.toml:
Это добавит RemoteAddrValve Tomcat в файл <APIM-HOME>/repository/conf/tomcat/carbon/META-INF/context.xml, и он будет применяться только к консоли управления Carbon, и, таким образом, все внешние запросы к консоли управления будут блокироваться.
-
Чтобы контролировать доступ ко всем веб-приложениям, развернутым на вашем сервере, добавьте в файл следующую конфигурацию <APIM-HOME>/repository/conf/deployment.toml:
Это добавит RemoteAddrValve Tomcat в файл <APIM-HOME>/repository/conf/tomcat/context.xml, и он будет применяться к каждому веб-приложению, размещенному на сервере Carbon. Таким образом, все внешние запросы к любому веб-приложению будут заблокированы.
-
Вы также можете ограничить доступ к определенным сервлетам в веб-приложении, добавив в файл следующую конфигурацию <APIM-HOME>/repository/conf/deployment.toml:
Это добавит Remote Address Filter в файл web.xml (хранящийся в каталоге <APIM-HOME>/repository/conf/tomcat/) путем сопоставления этого фильтра с URL сервлета. В Remote Address Filter, который вы добавляете, вы можете указать IP-адреса, которым должен быть разрешен доступ к сервлету.
Приведенный выше пример конфигурации deployment.toml иллюстрирует, как доступ к странице управления (/carbon/admin/login.jsp) предоставляется только одному IP-адресу.
Обойти учетные данные клиента, сделав PKCE обязательным
Вы можете обойти Client Secret в Devportal и веб-порталах Publisher в NEOMSA APIM . Выполните следующие шаги:
-
Обход секретного ключа клиента для веб-портала
-
Сделать PKCE обязательным для веб-портала
-
Сначала перейдите в консоль управления (carbon/admin) и войдите в систему как администратор.
-
С левой стороны выберите Service Providers и List.
Примечание
При попытке входа в Devportal или Publisher для этого портала будет создан поставщик услуг. Вы можете просмотреть этих поставщиков услуг в приведенном выше list. Например, apim_devportal для Devportal.
-
Отредактируйте поставщика услуг, которого необходимо изменить (Devportal или Publisher), и выберите Inbound Authentication Configuration.
-
Выберите OAuth/OpenID Connect Configuration. Вы сможете просмотреть ключ и секрет клиента OAuth.
-
Затем выберите Edit. Это перенаправит вас на форму Update application settings.
-
Выберите PKCE Mandatory и Allow authentication without the client secret из формы.
Примечание/ Обязательно выберите оба варианта. Не рекомендуется обходить Client Secret, не сделав PKCE обязательным, иначе это не сработает.
- Нажмите Update.
После выполнения вышеуказанных шагов соответствующий веб-портал больше не будет использовать Client Secret для аутентификации.
Включить JWT для веб-порталов
По умолчанию веб-порталы генерируют токены во время входа. Вы можете изменить это на JWT, добавив следующую конфигурацию в файл <APIM-HOME>/repository/conf/deployment.toml
[transport.https.properties]
maxHttpHeaderSize = "12288"
[apim.oauth_config]
enable_jwt_for_portals = true
[oauth]
add_tenant_domain_to_access_token = true
Если у вас уже есть развернутое решение, выполните следующие дополнительные шаги:
-
Сначала перейдите в консоль управления (carbon/admin) и войдите в систему как администратор.
-
С левой стороны выберите Service Providers и Список.
Примечание. При попытке входа в Devportal или Publisher для этого портала будет создан поставщик услуг. Вы можете просмотреть этих поставщиков услуг в приведенном выше списке. Например, apim_devportal для Devportal.
-
Отредактируйте поставщика услуг, которого необходимо изменить (Devportal или Publisher), и выберите Inbound Authentication Configuration.
-
Выберите OAuth/OpenID Connect Configuration. Вы сможете просмотреть ключ и секрет клиента OAuth.
-
Затем выберите Edit. Это перенаправит вас на форму Update application settings.
-
Выберите JWT под Token Issuer.
-
Нажмите Update.
-
Вернитесь к 2 шагу Service Providers и нажмите edit.
-
Разверните Local & Outbound Authentication Configuration и выберите Use user store domain in local subject identifier.
-
Сохраните изменения.
Настройка хранилищ пользователей¶
Хранилище пользователей — это база данных, в которой хранится информация о пользователях и/или ролях пользователей. Информация о пользователях включает имя пользователя, пароль, имя, фамилию, адрес электронной почты и т. д. По умолчанию для этой цели в NEOMSA APIM есть встроенная база данных H2.
Разрешения и другая информация, связанная с авторизацией, хранится в отдельной базе данных, называемой базой данных управления пользователями, которая по умолчанию также является H2. Однако пользователи также имеют возможность подключаться к внешним хранилищам.
Пользовательские хранилища можно настроить для работы в одном из следующих режимов.
Хранилище пользователей работает в режиме чтения/записи . В режиме чтения/записи API Manager выполняет чтение/запись в хранилище пользователей.
Хранилище пользователей работает в режиме только для чтения- В режиме только для чтения API Manager не изменяет никаких данных в хранилище пользователей. Вместо этого роли и разрешения хранятся в отдельной базе данных, а пользователи и роли считываются из настроенного пользовательского хранилища только для чтения.
Настройка основного хранилища пользователей¶
В этом разделе описывается процесс настройки основного хранилища пользовательских данных для вашей системы.
Функциональность управления пользователями предоставляется по умолчанию во всех продуктах NEOMSA APIM на базе Carbon и настраивается в deployment.toml файле, расположенном в соответствующем <APIM-HOME>/repository/conf/каталоге. Изменения будут автоматически применены и к файлу user-mgt.xml в <APIM-HOME>/repository/conf/этом же каталоге.
Этот файл поставляется с конфигурациями менеджера хранилища пользователей для всех возможных типов хранилищ пользователей (JDBC, LDAP/Active Directory только для чтения, LDAP с возможностью чтения и записи и Active Directory с возможностью чтения и записи). Приведенные ниже инструкции объясняют, как настроить основное хранилище пользователей для сервера APIM.
Основное хранилище пользователей в продуктах NEOMSA APIM по умолчанию настраивается как хранилище пользователей JDBC в файле user-mgt.xml, которое считывает/записывает данные во внутреннюю базу данных сервера продукта. Эта внутренняя база данных обычно по умолчанию использует протокол H2. Эта база данных используется как менеджером авторизации (для управления данными аутентификации пользователей), так и менеджером хранилища пользователей (для определения пользователей и ролей).
Обратите внимание, что СУБД, используемая в конфигурации по умолчанию, может оставаться той же базой данных, что и для хранения информации об авторизации.
Вместо использования встроенной базы данных вы можете настроить отдельное хранилище и сконфигурировать его как основное хранилище пользователей. Поскольку хранилище пользователей, к которому вы хотите подключиться, может иметь схемы, отличающиеся от схем, доступных во встроенном хранилище пользователей, потребуется процесс адаптации. Необходимые адаптации выполняются в зависимости от типа хранилища пользователей. Поддерживаются следующие типы основных хранилищ пользователей.
| Тип хранилища пользователя | Класс менеджера хранилища пользователя | Описание |
|---|---|---|
| read_only_ldap | org.wso2.carbon.user.core.ldap.ReadOnlyLDAPUserStoreManager | Используйте read_only_ldap для выполнения операций только для чтения с внешними хранилищами пользователей LDAP |
| read_write_ldap | org.wso2.carbon.user.core.ldap.ReadWriteLDAPUserStoreManager | Используйте read_write_ldap для внешних хранилищ пользователей LDAP для выполнения операций чтения и записи |
| active_directory | org.wso2.carbon.user.core.ldap.ActiveDirectoryUserStoreManager | Используйте active_directory для настройки службы домена Active Directory (AD DS) или облегченной службы каталогов Active Directory (AD LDS). Может использоваться только для операций чтения/записи. Если вам необходимо использовать AD только для чтения, необходимо использовать read_only_ldap. |
| БД | org.wso2.carbon.user.core.jdbc.JDBCUserStoreManager | Используется database как для внутренних, так и для внешних хранилищ пользователей JDBC. Это конфигурация хранилища пользователей, которая задается по умолчанию |
Необходимый тип можно определить в соответствующем [user_store] разделе файла <APIM-HOME>/repository/conf/deployment.toml:
[user_store]
type = "database_unique_id"
Для настройки необходимого типа основного хранилища пользователей следуйте инструкциям в приведенных ниже разделах.
Настройка JDBC хранилища пользователей¶
Хранилища пользователей JDBC можно настроить с помощью раздела конфигурации [user_store] в файле /repository/conf/deployment.toml. Ядро пользователя подключается к двум базам данных (по умолчанию используется одна и та же база данных):
-
База данных управления пользователями - это база данных, в которой хранится информация об авторизации.
-
База данных пользовательских данных - это база данных, в которой хранятся данные о пользователях/ролях.
Вы можете использовать конфигурацию по умолчанию или изменить её одним из следующих способов:
-
Вы можете настроить две отдельные базы данных для менеджера авторизации и менеджера хранилища пользователей.
-
В производственной среде не рекомендуется использовать базу данных H2 по умолчанию. Поэтому вы можете заменить её другой СУБД.
Важно: прежде чем начать, убедитесь, что СУБД, которую вы хотите использовать в качестве хранилища пользователей JDBC, правильно настроена для вашей системы. Затем выполните приведенные ниже шаги, чтобы настроить хранилище пользователей JDBC в качестве основного хранилища пользователей в вашем продукте.
Шаг 1: Настройка менеджера хранилища пользователей JDBC
- Для настройки хранилища пользователей JDBC в качестве основного хранилища пользователей необходимо указать значение database для конфигурации user_store.type в <APIM-HOME>/repository/conf/deployment.toml файле:
[user_store]
type = "database_unique_id"
- По умолчанию NEOMSA APIM использует JDBC-менеджер хранилищ пользователей. Это внутренняя СУБД. Если вы хотите подключиться к внешней СУБД для database-типа хранилища пользователей, вам потребуется определить следующие параметры конфигурации вместе с типом хранилища пользователей:
user_store.properties]
TenantManager = "org.wso2.carbon.user.core.tenant.JDBCTenantManager"
data_source = "WSO2USER_DB"
Disabled = false
MaxUserNameListLength = 100
MaxRoleNameListLength = 100
UserRolesCacheEnabled = true
PasswordDigest = "SHA-256"
ReadGroups = true
ReadOnly = false
IsEmailUserName = false
DomainCalculation = "default"
StoreSaltedPassword = true
WriteGroups = false
UserNameUniqueAcrossTenants = false
PasswordJavaRegEx = "^[\S]{5,30}$"
PasswordJavaScriptRegEx = "^[\S]{5,30}$"
UsernameJavaRegEx = "^[\S]{5,30}$"
UsernameJavaScriptRegEx = "^[\S]{5,30}$"
RolenameJavaRegEx = "^[\S]{5,30}$"
RolenameJavaScriptRegEx = "^[\S]{5,30}$"
SCIMEnabled = false
SelectUserSQL = "SELECT * FROM UM_USER WHERE UM_USER_NAME=? AND UM_TENANT_ID=?"
GetRoleListSQL = "SELECT UM_ROLE_NAME, UM_TENANT_ID, UM_SHARED_ROLE FROM UM_ROLE WHERE UM_ROLE_NAME LIKE ? AND UM_TENANT_ID=? AND UM_SHARED_ROLE ='0' ORDER BY UM_ROLE_NAME"
GetSharedRoleListSQL = "SELECT UM_ROLE_NAME, UM_TENANT_ID, UM_SHARED_ROLE FROM UM_ROLE WHERE UM_ROLE_NAME LIKE ? AND UM_SHARED_ROLE ='1' ORDER BY UM_ROLE_NAME"
UserFilterSQL = "SELECT UM_USER_NAME FROM UM_USER WHERE UM_USER_NAME LIKE ? AND UM_TENANT_ID=? ORDER BY UM_USER_NAME"
UserRoleSQL = "SELECT UM_ROLE_NAME FROM UM_USER_ROLE, UM_ROLE, UM_USER WHERE UM_USER.UM_USER_NAME=? AND UM_USER.UM_ID=UM_USER_ROLE.UM_USER_ID AND UM_ROLE.UM_ID=UM_USER_ROLE.UM_ROLE_ID AND UM_USER_ROLE.UM_TENANT_ID=? AND UM_ROLE.UM_TENANT_ID=? AND UM_USER.UM_TENANT_ID=?"
UserSharedRoleSQL = "SELECT UM_ROLE_NAME, UM_ROLE.UM_TENANT_ID, UM_SHARED_ROLE FROM UM_SHARED_USER_ROLE INNER JOIN UM_USER ON UM_SHARED_USER_ROLE.UM_USER_ID = UM_USER.UM_ID INNER JOIN UM_ROLE ON UM_SHARED_USER_ROLE.UM_ROLE_ID = UM_ROLE.UM_ID WHERE UM_USER.UM_USER_NAME = ? AND UM_SHARED_USER_ROLE.UM_USER_TENANT_ID = UM_USER.UM_TENANT_ID AND UM_SHARED_USER_ROLE.UM_ROLE_TENANT_ID = UM_ROLE.UM_TENANT_ID AND UM_SHARED_USER_ROLE.UM_USER_TENANT_ID = ?"
IsRoleExistingSQL = "SELECT UM_ID FROM UM_ROLE WHERE UM_ROLE_NAME=? AND UM_TENANT_ID=?"
GetUserListOfRoleSQL = "SELECT UM_USER_NAME FROM UM_USER_ROLE, UM_ROLE, UM_USER WHERE UM_ROLE.UM_ROLE_NAME=? AND UM_USER.UM_ID=UM_USER_ROLE.UM_USER_ID AND UM_ROLE.UM_ID=UM_USER_ROLE.UM_ROLE_ID AND UM_USER_ROLE.UM_TENANT_ID=? AND UM_ROLE.UM_TENANT_ID=? AND UM_USER.UM_TENANT_ID=?"
GetUserListOfSharedRoleSQL = "SELECT UM_USER_NAME FROM UM_SHARED_USER_ROLE INNER JOIN UM_USER ON UM_SHARED_USER_ROLE.UM_USER_ID = UM_USER.UM_ID INNER JOIN UM_ROLE ON UM_SHARED_USER_ROLE.UM_ROLE_ID = UM_ROLE.UM_ID WHERE UM_ROLE.UM_ROLE_NAME= ? AND UM_SHARED_USER_ROLE.UM_USER_TENANT_ID = UM_USER.UM_TENANT_ID AND UM_SHARED_USER_ROLE.UM_ROLE_TENANT_ID = UM_ROLE.UM_TENANT_ID"
IsUserExistingSQL = "SELECT UM_ID FROM UM_USER WHERE UM_USER_NAME=? AND UM_TENANT_ID=?"
GetUserPropertiesForProfileSQL = "SELECT UM_ATTR_NAME, UM_ATTR_VALUE FROM UM_USER_ATTRIBUTE, UM_USER WHERE UM_USER.UM_ID = UM_USER_ATTRIBUTE.UM_USER_ID AND UM_USER.UM_USER_NAME=? AND UM_PROFILE_ID=? AND UM_USER_ATTRIBUTE.UM_TENANT_ID=? AND UM_USER.UM_TENANT_ID=?"
GetUserPropertyForProfileSQL = "SELECT UM_ATTR_VALUE FROM UM_USER_ATTRIBUTE, UM_USER WHERE UM_USER.UM_ID = UM_USER_ATTRIBUTE.UM_USER_ID AND UM_USER.UM_USER_NAME=? AND UM_ATTR_NAME=? AND UM_PROFILE_ID=? AND UM_USER_ATTRIBUTE.UM_TENANT_ID=? AND UM_USER.UM_TENANT_ID=?"
GetUserLisForPropertySQL = "SELECT UM_USER_NAME FROM UM_USER, UM_USER_ATTRIBUTE WHERE UM_USER_ATTRIBUTE.UM_USER_ID = UM_USER.UM_ID AND UM_USER_ATTRIBUTE.UM_ATTR_NAME =? AND UM_USER_ATTRIBUTE.UM_ATTR_VALUE LIKE ? AND UM_USER_ATTRIBUTE.UM_PROFILE_ID=? AND UM_USER_ATTRIBUTE.UM_TENANT_ID=? AND UM_USER.UM_TENANT_ID=?"
GetProfileNamesSQL = "SELECT DISTINCT UM_PROFILE_ID FROM UM_USER_ATTRIBUTE WHERE UM_TENANT_ID=?"
GetUserProfileNamesSQL = "SELECT DISTINCT UM_PROFILE_ID FROM UM_USER_ATTRIBUTE WHERE UM_USER_ID=(SELECT UM_ID FROM UM_USER WHERE UM_USER_NAME=? AND UM_TENANT_ID=?) AND UM_TENANT_ID=?"
GetUserIDFromUserNameSQL = "SELECT UM_ID FROM UM_USER WHERE UM_USER_NAME=? AND UM_TENANT_ID=?"
GetUserNameFromTenantIDSQL = "SELECT UM_USER_NAME FROM UM_USER WHERE UM_TENANT_ID=?"
GetTenantIDFromUserNameSQL = "SELECT UM_TENANT_ID FROM UM_USER WHERE UM_USER_NAME=?"
AddUserSQL = "INSERT INTO UM_USER (UM_USER_NAME, UM_USER_PASSWORD, UM_SALT_VALUE, UM_REQUIRE_CHANGE, UM_CHANGED_TIME, UM_TENANT_ID) VALUES (?, ?, ?, ?, ?, ?)"
AddUserToRoleSQL = "INSERT INTO UM_USER_ROLE (UM_USER_ID, UM_ROLE_ID, UM_TENANT_ID) VALUES ((SELECT UM_ID FROM UM_USER WHERE UM_USER_NAME=? AND UM_TENANT_ID=?),(SELECT UM_ID FROM UM_ROLE WHERE UM_ROLE_NAME=? AND UM_TENANT_ID=?), ?)"
AddRoleSQL = "INSERT INTO UM_ROLE (UM_ROLE_NAME, UM_TENANT_ID) VALUES (?, ?)"
AddSharedRoleSQL = "UPDATE UM_ROLE SET UM_SHARED_ROLE = ? WHERE UM_ROLE_NAME = ? AND UM_TENANT_ID = ?"
AddRoleToUserSQL = "INSERT INTO UM_USER_ROLE (UM_ROLE_ID, UM_USER_ID, UM_TENANT_ID) VALUES ((SELECT UM_ID FROM UM_ROLE WHERE UM_ROLE_NAME=? AND UM_TENANT_ID=?),(SELECT UM_ID FROM UM_USER WHERE UM_USER_NAME=? AND UM_TENANT_ID=?), ?)"
AddSharedRoleToUserSQL = "INSERT INTO UM_SHARED_USER_ROLE (UM_ROLE_ID, UM_USER_ID, UM_USER_TENANT_ID, UM_ROLE_TENANT_ID) VALUES ((SELECT UM_ID FROM UM_ROLE WHERE UM_ROLE_NAME=? AND UM_TENANT_ID=?),(SELECT UM_ID FROM UM_USER WHERE UM_USER_NAME=? AND UM_TENANT_ID=?), ?, ?)"
RemoveUserFromSharedRoleSQL = "DELETE FROM UM_SHARED_USER_ROLE WHERE UM_ROLE_ID=(SELECT UM_ID FROM UM_ROLE WHERE UM_ROLE_NAME=? AND UM_TENANT_ID=?) AND UM_USER_ID=(SELECT UM_ID FROM UM_USER WHERE UM_USER_NAME=? AND UM_TENANT_ID=?) AND UM_USER_TENANT_ID=? AND UM_ROLE_TENANT_ID = ?"
RemoveUserFromRoleSQL = "DELETE FROM UM_USER_ROLE WHERE UM_USER_ID=(SELECT UM_ID FROM UM_USER WHERE UM_USER_NAME=? AND UM_TENANT_ID=?) AND UM_ROLE_ID=(SELECT UM_ID FROM UM_ROLE WHERE UM_ROLE_NAME=? AND UM_TENANT_ID=?) AND UM_TENANT_ID=?"
RemoveRoleFromUserSQL = "DELETE FROM UM_USER_ROLE WHERE UM_ROLE_ID=(SELECT UM_ID FROM UM_ROLE WHERE UM_ROLE_NAME=? AND UM_TENANT_ID=?) AND UM_USER_ID=(SELECT UM_ID FROM UM_USER WHERE UM_USER_NAME=? AND UM_TENANT_ID=?) AND UM_TENANT_ID=?"
DeleteRoleSQL = "DELETE FROM UM_ROLE WHERE UM_ROLE_NAME = ? AND UM_TENANT_ID=?"
OnDeleteRoleRemoveUserRoleMappingSQL = "DELETE FROM UM_USER_ROLE WHERE UM_ROLE_ID=(SELECT UM_ID FROM UM_ROLE WHERE UM_ROLE_NAME=? AND UM_TENANT_ID=?) AND UM_TENANT_ID=?"
DeleteUserSQL = "DELETE FROM UM_USER WHERE UM_USER_NAME = ? AND UM_TENANT_ID=?"
OnDeleteUserRemoveUserRoleMappingSQL = "DELETE FROM UM_USER_ROLE WHERE UM_USER_ID=(SELECT UM_ID FROM UM_USER WHERE UM_USER_NAME=? AND UM_TENANT_ID=?) AND UM_TENANT_ID=?"
OnDeleteUserRemoveUserAttributeSQL = "DELETE FROM UM_USER_ATTRIBUTE WHERE UM_USER_ID=(SELECT UM_ID FROM UM_USER WHERE UM_USER_NAME=? AND UM_TENANT_ID=?) AND UM_TENANT_ID=?"
UpdateUserPasswordSQL = "UPDATE UM_USER SET UM_USER_PASSWORD= ?, UM_SALT_VALUE=?, UM_REQUIRE_CHANGE=?, UM_CHANGED_TIME=? WHERE UM_USER_NAME= ? AND UM_TENANT_ID=?"
UpdateRoleNameSQL = "UPDATE UM_ROLE set UM_ROLE_NAME=? WHERE UM_ROLE_NAME = ? AND UM_TENANT_ID=?"
AddUserPropertySQL = "INSERT INTO UM_USER_ATTRIBUTE (UM_USER_ID, UM_ATTR_NAME, UM_ATTR_VALUE, UM_PROFILE_ID, UM_TENANT_ID) VALUES ((SELECT UM_ID FROM UM_USER WHERE UM_USER_NAME=? AND UM_TENANT_ID=?), ?, ?, ?, ?)"
UpdateUserPropertySQL = "UPDATE UM_USER_ATTRIBUTE SET UM_ATTR_VALUE=? WHERE UM_USER_ID=(SELECT UM_ID FROM UM_USER WHERE UM_USER_NAME=? AND UM_TENANT_ID=?) AND UM_ATTR_NAME=? AND UM_PROFILE_ID=? AND UM_TENANT_ID=?"
DeleteUserPropertySQL = "DELETE FROM UM_USER_ATTRIBUTE WHERE UM_USER_ID=(SELECT UM_ID FROM UM_USER WHERE UM_USER_NAME=? AND UM_TENANT_ID=?) AND UM_ATTR_NAME=? AND UM_PROFILE_ID=? AND UM_TENANT_ID=?"
UserNameUniqueAcrossTenantsSQL = "SELECT UM_ID FROM UM_USER WHERE UM_USER_NAME=?"
IsDomainExistingSQL = "SELECT UM_DOMAIN_ID FROM UM_DOMAIN WHERE UM_DOMAIN_NAME=? AND UM_TENANT_ID=?"
AddDomainSQL = "INSERT INTO UM_DOMAIN (UM_DOMAIN_NAME, UM_TENANT_ID) VALUES (?, ?)"
AddUserToRoleSQL-mssql = "INSERT INTO UM_USER_ROLE (UM_USER_ID, UM_ROLE_ID, UM_TENANT_ID) SELECT (SELECT UM_ID FROM UM_USER WHERE UM_USER_NAME=? AND UM_TENANT_ID=?),(SELECT UM_ID FROM UM_ROLE WHERE UM_ROLE_NAME=? AND UM_TENANT_ID=?),(?)"
AddRoleToUserSQL-mssql = "INSERT INTO UM_USER_ROLE (UM_ROLE_ID, UM_USER_ID, UM_TENANT_ID) SELECT (SELECT UM_ID FROM UM_ROLE WHERE UM_ROLE_NAME=? AND UM_TENANT_ID=?),(SELECT UM_ID FROM UM_USER WHERE UM_USER_NAME=? AND UM_TENANT_ID=?), (?)"
AddUserPropertySQL-mssql = "INSERT INTO UM_USER_ATTRIBUTE (UM_USER_ID, UM_ATTR_NAME, UM_ATTR_VALUE, UM_PROFILE_ID, UM_TENANT_ID) SELECT (SELECT UM_ID FROM UM_USER WHERE UM_USER_NAME=? AND UM_TENANT_ID=?), (?), (?), (?), (?)"
AddUserToRoleSQL-openedge = "INSERT INTO UM_USER_ROLE (UM_USER_ID, UM_ROLE_ID, UM_TENANT_ID) SELECT UU.UM_ID, UR.UM_ID, ? FROM UM_USER UU, UM_ROLE UR WHERE UU.UM_USER_NAME=? AND UU.UM_TENANT_ID=? AND UR.UM_ROLE_NAME=? AND UR.UM_TENANT_ID=?"
AddRoleToUserSQL-openedge = "INSERT INTO UM_USER_ROLE (UM_ROLE_ID, UM_USER_ID, UM_TENANT_ID) SELECT UR.UM_ID, UU.UM_ID, ? FROM UM_ROLE UR, UM_USER UU WHERE UR.UM_ROLE_NAME=? AND UR.UM_TENANT_ID=? AND UU.UM_USER_NAME=? AND UU.UM_TENANT_ID=?"
AddUserPropertySQL-openedge = "INSERT INTO UM_USER_ATTRIBUTE (UM_USER_ID, UM_ATTR_NAME, UM_ATTR_VALUE, UM_PROFILE_ID, UM_TENANT_ID) SELECT UM_ID, ?, ?, ?, ? FROM UM_USER WHERE UM_USER_NAME=? AND UM_TENANT_ID=?"
Description = "This is an external JDBC primary user store"
UserCoreCacheTimeOut = 5
Обратите внимание: пример конфигурации внешнего хранилища пользователей JDBC включает свойства, относящиеся к различным SQL-запросам. Это связано с тем, что схема внешнего хранилища пользователей может отличаться, и эти корректировки необходимо внести для упрощения конфигурации с продуктами NEOMSA APIM.
- Добавьте свойство PasswordHashMethod в UserStoreManager конфигурацию JDBCUserStoreManager. Например:
[user_store.properties]
ReadGroupsPasswordHashMethod = "SHA"
Свойство PasswordHashMethod определяет способ хранения пароля. Обычно оно принимает следующие значения:
- **SHA** — использует метод дайджеста SHA.
- **MD5** — Использует метод расщепления MD5.
- **PLAIN\_TEXT** — Пароли в открытом текстовом виде.
Кроме того, оно также поддерживает все методы обработки дайджестов, описанные в http://docs.oracle.com/javase/6/docs/api/java/security/MessageDigest.html .
- Если вы настраиваете внешнее хранилище пользователей JDBC, вам необходимо установить следующее свойство в значение 'true', чтобы иметь возможность создавать роли в основном хранилище пользователей:
[user_store.properties]
WriteGroups = false
Шаг 2: Обновление системного администратора
Администратор — это суперпользователь, который сможет управлять всеми остальными пользователями, ролями и разрешениями в системе с помощью консоли управления продукта. Поэтому пользователь, обладающий правами администратора, должен быть сохранен в хранилище пользователей при первом запуске системы. Если хранилище пользователей JDBC доступно только для чтения, то в качестве суперпользователя всегда следует использовать идентификатор пользователя, уже существующий в хранилище.
В противном случае, если хранилище пользователей JDBC доступно для записи, у вас есть возможность создать нового администратора в хранилище пользователей при первом запуске системы. Эти две альтернативные конфигурации можно выполнить, как описано ниже.
- Если хранилище пользователей доступно только для чтения, найдите действительного пользователя, который уже существует в СУБД. Например, предположим, что хранилище пользователей содержит пользователя: "adminUser". Обновите раздел username конфигурации super_admin файла deployment.toml, как показано ниже. Вам не нужно обновлять элемент password, поскольку он уже установлен в хранилище пользователей. Поскольку пользователь уже существует в хранилище пользователей, и хранилище пользователей доступно только для чтения, в create_admin_account следует установить значение false:
[super_admin]
username = "adminUser"
password = "XXXXXX"
create_admin_account = false
- Если хранилище доступно для записи, вы можете добавить суперпользователя в хранилище пользователей. Поэтому в create_admin_account следует установить значение true, как показано ниже:
[super_admin]
username = "adminUser"
password = "adminpass"
create_admin_account = true
В разделе конфигурации области установите значение свойства MultiTenantRealmConfigBuilder, org.wso2.carbon.user.core.config.multitenancy.SimpleRealmConfigBuilder, чтобы создавать конфигурации области, специфичные для каждого арендатора.
Например:
[realm_manager.properties]
MultiTenantRealmConfigBuilder = "org.wso2.carbon.user.core.config.multitenancy.SimpleRealmConfigBuilder"
Шаг 3: Обновление источников данных
При настройке СУБД для вашей системы необходимо создать соответствующий источник данных, который позволит системе подключаться к базе данных. Источник данных для внутренней базы данных H2, поставляемой по умолчанию, настраивается в файле deployment.toml, который находится в соответствующем <APIM-HOME>/repository/conf каталоге.
- Если вы заменили базу данных по умолчанию на новую СУБД, которую теперь используете в качестве хранилища пользователей JDBC, вам необходимо обновить файл, deployment.toml, добавив в него соответствующую информацию. Это можно сделать, добавив конфигурацию, database.user как показано ниже:
[database.user]
type = "h2"
url = "jdbc:h2:./repository/database/WSO2USER_DB;DB_CLOSE_ON_EXIT=FALSE"
username = "wso2carbon"
password = "wso2carbon"
[database.user.pool_options]
maxActive = 50
maxWait = 60000
testOnBorrow = true
validationInterval = 30000
defaultAutoCommit = true
-
Теперь необходимо связать конфигурацию источника данных и конфигурацию СУБД менеджера хранилища пользователей.
-
По умолчанию для сохранения информации об авторизации пользователей используется база данных SHARED_DB. Также по умолчанию она используется в качестве источника данных для основного хранилища пользователей JDBC. Если вы хотите изменить как базу данных управления пользователями, так и основное хранилище пользователей, следующей конфигурации будет достаточно:
[realm_manager]
data_source = "WSO2USER_DB"
- Однако, если вы настроили внешнюю СУБД в качестве основного хранилища пользователей, вместо общей СУБД для управления пользователями и хранилища пользователей, вам необходимо настроить источник данных для этого внешнего хранилища пользователей следующим образом:
[user_store.properties]
data_source = "WSO2USER_DB"
Примечание: данная конфигурация уже добавлена в конфигурацию внешнего основного хранилища пользователей, указанную на втором шаге.
Шаг 4: Запуск сервера
-
Добавьте JDBC-драйвер в classpath, скопировав его JAR-файл в соответствующую <APIM-HOME>/repository/components/lib директорию.
-
Запустите сервер.
Настройка LDAP хранилища пользователей с возможностью чтения и записи¶
Предполагается, что вы уже настроили хранилище пользователей LDAP с возможностью чтения и записи. Выполните следующие шаги, чтобы настроить его в качестве основного хранилища пользователей в NEOMSA APIM:
-
Шаг 1: настройка менеджера хранилища пользователей LDAP с возможностью чтения и записи.
-
Шаг 2: обновление системного администратора
-
Шаг 3: запуск сервера
Шаг 1: Настройка менеджера хранилища пользователей LDAP с возможностью чтения и записи
Ниже приведены минимальные параметры конфигурации, необходимые для настройки менеджера хранилища пользователей LDAP с возможностью чтения и записи:
| Название конфигурации | Отображаемое имя | Описание |
|---|---|---|
| type | userstore Type | Это тип используемого менеджера хранилища пользователей. Для менеджера хранилища пользователей LDAP с возможностью чтения и записи это значение должно быть `read_write_ldap_unique_id`. |
| base_dn | User Search Base | Это обозначает DN контекста или объекта, под которым хранятся записи пользователей в хранилище пользователей. При поиске пользователей хранилище пользователей начинает поиск с этого места в каталоге. Примеры значений: ou=Users,dc=example,dc=local |
Ниже перечислены минимальные свойства хранилища пользователей, которые необходимо указать для настройки менеджера хранилища пользователей LDAP с возможностью чтения и записи:
| Идентификатор объекта недвижимости | Основное свойство хранилища пользователей | Вторичное хранилище пользовательских данных | Описание |
|---|---|---|---|
| ConnectionURL | connection_url | Connection URL | URL-адрес подключения к серверу хранилища пользователей. Примеры значений: ldap://ldap1.example.local:389 ldaps://ldap2.example.local:639 Если вы подключаетесь через LDAPS (защищенный LDAP), необходимо импортировать сертификат хранилища пользователей в файл client-truststore.jks продукта APIM. |
| ConnectionName | connection_name | Connection Name | Имя пользователя, используемое для подключения к хранилищу пользователей и выполнения различных операций. Этот пользователь не обязательно должен быть администратором в хранилище пользователей или иметь роль администратора в используемом вами продукте APIM, но этот пользователь ОБЯЗАТЕЛЬНО должен иметь разрешения на чтение списка пользователей и атрибутов пользователей, а также на выполнение операций поиска в хранилище пользователей. Указанное вами значение используется в качестве атрибута DN (Distinguish Name) пользователя, имеющего достаточные права для выполнения операций с пользователями и ролями в LDAP. Это свойство является обязательным. Примеры значений: uid=admin,ou=system |
| ConnectionPassword | connection_password | Connection Password | Пароль для пользователя ConnectionName. |
Замените user_store конфигурацию по умолчанию в файле <APIM-HOME>/repository/conf/deployment.toml в соответствии с конфигурацией вашего LDAP-сервера. Пример конфигурации приведен ниже:
[user_store]
type = "read_write_ldap_unique_id"
base_dn = "ou=system"
connection_url = "ldap://localhost:10389"
connection_name = "uid=admin,ou=system"
connection_password = "admin"
Помимо вышеперечисленных свойств, NEOMSA APIM также поддерживает расширенные конфигурации LDAP.
Свойства, используемые в менеджере хранилища пользователей LDAP с возможностью чтения и записи
Любое из следующих свойств можно настроить для PRIMARY-хранилища пользователей, добавив его в файл <APIM-HOME>/repository/conf/deployment.toml следующим образом:
[user_store]
<Property-Name> = <Property-Value>
Например:
[user_store]
read_groups = true
Примечание: в приведенной ниже таблице в столбце Primary Userstore Property указаны PRIMARY-свойства хранилища пользователей, которые можно настроить в deployment.toml файле. В столбце Secondary Userstore Property указаны свойства, которые можно настроить для дополнительного хранилища пользователей через консоль управления.
| Property Id | Primary Userstore Property | Secondary Userstore Property | Описание |
|---|---|---|---|
| UserEntryObjectClass | user_entry_object_class | User Entry Object Class | Класс объекта, используемый для создания записей пользователей. По умолчанию: identityPerson (это пользовательский класс объекта, определенный в APIM Identity Server) |
| UserNameAttribute | user_name_attribute | Username Attribute | Уникальный идентификационный атрибут, представляющий собой имя пользователя. Аутентификация пользователей может осуществляться с помощью адреса электронной почты, UID и т. д. Значение атрибута считается именем пользователя. По умолчанию: uid |
| UserIDAttribute | user_id_attribute | User ID Attribute | Атрибут, используемый для уникальной идентификации записи пользователя. Значение этого атрибута считается уникальным идентификатором пользователя. По умолчанию: scimId |
| UserNameSearchFilter | user_name_search_filter | User Search Filter | Критерии фильтрации, используемые для поиска конкретной записи пользователя. По умолчанию: (&(objectClass=identityPerson)(uid=?)) |
| UserNameListFilter | user_name_list_filter | User List Filter | Критерии фильтрации для поиска записей пользователей в хранилище пользователей. Этот запрос или фильтр используется при поиске пользователей с различными атрибутами поиска. По умолчанию: (objectClass=identityPerson). В этом случае поиск отображает только объекты, созданные на основе класса объектов person |
| UserDNPattern | user_dn_pattern | User DN Pattern | Шаблон для DN пользователя, который можно определить для улучшения поиска. Когда в хранилище пользователей LDAP много записей о пользователях, определение UserDNPattern оказывает большее влияние на производительность, поскольку LDAP не нужно проходить по всему дереву, чтобы найти пользователей. Пример значений: uid={0},ou=Users,dc=example,dc=local |
| DisplayNameAttribute | display_name_attribute | Display name attribute | Это необязательное свойство. Атрибут «Отображаемое имя» — это имя, под которым пользователи будут отображаться в списке пользователей в консоли управления. По умолчанию: blank |
| ReadGroups | read_groups | Read Groups | Если параметр WriteGroups установлен в значение false, это указывает, следует ли считывать группы из хранилища пользователей. Если эта функция отключена путем установки значения false, ни одна из групп в хранилище пользователей не может быть прочитана, и следующие параметры конфигурации групп НЕ являются обязательными: GroupSearchBase, GroupNameListFilter или GroupNameAttribute. По умолчанию: true Возможные значения: true: читать группы из хранилища пользователей false: не читать группы из хранилища пользователей |
| WriteGroups | write_groups | Write Groups | Указывает, следует ли записывать группы в хранилище пользователей. По умолчанию: true. Возможные значения: true: записывать группы в хранилище пользователей; false: не записывать группы в хранилище пользователей, поэтому могут быть созданы только внутренние роли. В зависимости от значения свойства ReadGroups, будет ли оно считывать существующие группы из хранилища пользователей или нет |
| UserSearchBase | user_search_base | User Search Base | DN контекста или объекта, под которым хранятся пользователи в хранилище пользователей. При поиске пользователей хранилище начинает поиск с этого места в каталоге. По умолчанию: ou=Users,dc=example,dc=local |
| GroupSearchBase | group_search_base | Group Search Base | DN контекста или объекта, под которым хранятся записи групп в хранилище пользователей. При поиске групп хранилище пользователей начинает поиск с этого места в каталоге. По умолчанию: ou=Groups,dc=example,dc=local |
| GroupEntryObjectClass | group_entry_object_class | Group Entry Object Class | Класс объекта, используемый для создания записей группы. По умолчанию: groupOfNames |
| GroupNameAttribute | group_name_attribute | Group Name Attribute | Атрибут, используемый для уникальной идентификации записи группы. Этот атрибут следует рассматривать как название группы. По умолчанию: cn |
| GroupNameSearchFilter | group_name_search_filter | Group Search Filter | Критерии фильтрации, используемые для поиска записи в определенной группе. По умолчанию: (&(objectClass=groupOfNames)(cn=?)) |
| GroupNameListFilter | group_name_list_filter | Group List Filter | Критерии фильтрации для поиска групповых записей в хранилище пользователей. Этот запрос или фильтр используется при поиске групп с различными атрибутами поиска. По умолчанию: ((objectClass=groupOfNames)) В этом случае операция поиска предоставляет только объекты, созданные из класса объектов groupOfName. |
| RoleDNPattern | role_dn_pattern | Role DN Pattern | Шаблон для DN группы, который можно определить для улучшения поиска. Когда в хранилище пользователей LDAP много записей о группах, определение RoleDNPattern оказывает большее влияние на производительность, поскольку LDAP не нужно проходить по всему дереву, чтобы найти группу. Пример значений: cn={0},ou=Groups,dc=example,dc=local |
| MembershipAttribute | membership_attribute | Membership Attribute | Определяет атрибут, содержащий отличительные имена (DN) пользовательских объектов, входящих в группу. По умолчанию: member |
| MemberOfAttribute | member_of_attribute | Member Of Attribute | Определите атрибут, содержащий отличительные имена (DN) групповых объектов, к которым назначен пользователь. Возможные значения: memberOf |
| BackLinksEnabled | back_links_enabled | Enable Back Links | Определяет, включена ли поддержка обратных ссылок. Если вы используете атрибуты MemberOfAttribute, это значение следует установить на 'true'. По умолчанию: false |
| UsernameJavaRegEx | username_java_regex | Username RegEx (Java) | Регулярное выражение, используемое серверными компонентами для проверки имени пользователя. По умолчанию допускается длина строк, содержащих непустые символы, от 3 до 30 символов. В свойствах RegEx можно указать диапазоны букв, цифр, а также диапазоны значений ASCII. По умолчанию: [a-zA-Z0-9._-|//]{3,30}$ |
| UsernameJava ScriptRegEx |
username_java_ script_regex |
Username RegEx (Javascript) | Регулярное выражение, используемое компонентами интерфейса для проверки имени пользователя. По умолчанию: ^[\S]{3,30}$ |
| UsernameJavaReg ExViolationErrorMsg |
username_java_reg_ ex_violation_error_msg |
Username RegEx Violation Error Message | Сообщение об ошибке, если имя пользователя не соответствует шаблону UsernameJavaRegEx По умолчанию: Username pattern policy violated |
| PasswordJavaRegEx | password_java_regex | Password RegEx (Java) | Регулярное выражение, используемое серверными компонентами для проверки паролей. По умолчанию допускается длина строк, содержащих непустые символы, от 5 до 30 символов. В свойствах RegEx можно указать диапазоны букв, цифр, а также диапазоны значений ASCII. По умолчанию: ^[\S]{5,30}$ |
| PasswordJava ScriptRegEx |
password_java_ script_regex |
Password RegEx (Javascript) | Регулярное выражение, используемое компонентами интерфейса для проверки паролей. По умолчанию: ^[\S]{5,30}$ |
| PasswordJavaReg ExViolationErrorMsg |
password_java_reg ex_violation_error_msg |
Password RegEx Violation Error Message | Сообщение об ошибке, если пароль не соответствует регулярным выражениям JavaJava. По умолчанию длина пароля должна быть от 5 до 30 символов |
| RolenameJavaRegEx | rolename_java_regex | Role Name RegEx (Java) | Регулярное выражение, используемое серверными компонентами для проверки имен ролей. По умолчанию допускается длина строк, содержащих непустые символы, от 3 до 30 символов. В свойствах RegEx можно указать диапазоны букв, цифр, а также диапазоны значений ASCII. По умолчанию: [a-zA-Z0-9._-|//]{3,30}$ |
| PasswordHashMethod | password_hash_method | Password Hashing Algorithm | Указывает алгоритм хеширования паролей, используемый для хеширования пароля перед сохранением в хранилище пользователя. Возможные значения: SHA — использует метод дайджеста SHA. SHA-1, SHA-256. MD5 — использует метод дайджеста MD5. PLAIN_TEXT — пароли в открытом виде (по умолчанию). Если вы просто настроите SHA, он будет считаться SHA-1. Всегда лучше настраивать алгоритм с более высоким битовым значением, так как размер бита дайджеста увеличится. Большинство LDAP-серверов (таких как OpenLDAP, OpenDJ, AD, ApacheDS и т. д.) поддерживают хранение паролей в виде salted hashed values (SSHA). Поэтому NEOMSA APIM просто передает пароль в подключенное хранилище пользователей в виде открытого текста. Затем хранилище пользователей LDAP может хранить его в виде хешированного значения. Чтобы передать открытый текст на LDAP-сервер, необходимо установить PasswordHashMethod в значение “PLAIN_TEXT”. Но если ваш LDAP не поддерживает хранение паролей пользователей в виде хешированных значений, вы можете настроить сервер APIM для хеширования пароля и передачи хешированного пароля на LDAP-сервер. В этом случае вам необходимо настроить свойство PasswordHashMethod с использованием SHA (SHA-1), SHA-256, SHA-512. Обратите внимание, что сервер APIM не может создать пароль с хешированием (SSHA) для передачи в LDAP. |
| MultiAttributeSeparator | multi_attribute_separator | Multiple Attribute Separator | Это свойство используется для определения символа, разделяющего несколько атрибутов. Это гарантирует, что он не будет отображаться как часть значения. Обычно для разделения нескольких атрибутов используется запятая («,»), но вы можете определить «,,,» или «...» или аналогичную последовательность символов. По умолчанию: «,» |
| MaxUserName ListLength |
max_user_name _list_length |
Maximum User List Length | Этот параметр управляет количеством пользователей, отображаемых в хранилище пользователей продукта. Это полезно, когда у вас большое количество пользователей, и вы не хотите отображать их всех. Установка этого свойства в 0 отображает всех пользователей. Значение по умолчанию: 100. В некоторых хранилищах пользователей существуют политики, ограничивающие количество записей, которые могут быть возвращены запросом. Установка значения 0 отобразит максимальное количество результатов, возвращаемых хранилищем пользователей. Если вам нужно увеличить это значение, необходимо установить его на уровне хранилища пользователей. Например: в Active Directory есть свойство MaxPageSize со значением по умолчанию 1000 |
| MaxRoleName ListLength |
max_role_name _list_length |
Maximum Role List Length | Этот параметр управляет количеством ролей, отображаемых в хранилище пользователей продукта. Это полезно, когда у вас большое количество ролей, и вы не хотите отображать их все. Установка этого параметра в 0 отображает все роли. Значение по умолчанию: 100. В некоторых хранилищах пользователей существуют политики, ограничивающие количество записей, которые могут быть возвращены запросом. Установка значения 0 отобразит максимальное количество результатов, возвращаемых хранилищем пользователей. Если вам нужно увеличить это значение, необходимо установить его на уровне хранилища пользователей. Например: в Active Directory есть свойство MaxPageSize со значением по умолчанию 1000. |
| kdcEnabled | kdc_enabled | Enable KDC | Если ваше хранилище пользователей способно выступать в качестве центра распространения ключей Kerberos (KDC) и вы хотите включить эту функцию, установите для этого свойства значение true. Значение по умолчанию: false |
| UserRoles CacheEnabled |
user_roles _cache_enabled |
Enable User Role Cache | Этот параметр указывает, следует ли кэшировать список ролей пользователя. По умолчанию: true. Возможные значения: false: установите значение false, если роли пользователя изменяются внешними средствами, и эти изменения должны мгновенно отражаться в экземпляре Carbon. По умолчанию: true |
| ConnectionPooling Enabled |
connection_pooling _enabled |
Enable LDAP Connection Pooling | Определяет, включено ли объединение соединений LDAP. Возможные значения: True: Включить объединение соединений. Включение повысит производительность. False: Отключить объединение соединений. По умолчанию: false |
| LDAPConnectionTimeout | ldap_connection_timeout | LDAP Connection Timeout | Тайм-аут при установлении первоначального LDAP-соединения. Задается в миллисекундах. По умолчанию: 5000 |
| ReadTimeout | read_timeout | LDAP Read Timeout | Значение этого свойства - это время ожидания чтения в миллисекундах для операций LDAP. Если поставщик LDAP не может получить ответ LDAP в течение этого периода, он прерывает попытку чтения. Целое число должно быть больше нуля. Целое число меньше или равное нулю означает, что время ожидания чтения не указано, что эквивалентно бесконечному ожиданию ответа до его получения. По умолчанию: не настроено |
| MembershipAttributeRange | membership_attribute_range | Membership Attribute Range | Это позволяет определить максимальное количество пользователей роли, возвращаемое хранилищем пользователей LDAP/AD. Это не зависит от максимального размера страницы хранилища пользователей. По умолчанию: не настроено |
| RetryAttempts | retry_attempts | Retry Attempts | Повторите запрос на аутентификацию, если истекло время ожидания. По умолчанию: не настроено |
Ниже приведены некоторые ключевые моменты, которые следует учитывать:
- Для чтения и записи в хранилище пользователей LDAP важно убедиться, что свойства ReadGroups и WriteGroups в файле <APIM-HOME>/repository/conf/deployment.toml установлены в значение true.
WriteGroups = "true"
ReadGroups = "true"
- Укажите атрибут, который будет использоваться в качестве имени пользователя. Обычно это cn либо uid. В идеале UserNameAttribute и UserNameSearchFilter должны ссылаться на один и тот же атрибут. Если вы не уверены, какой атрибут доступен в вашем хранилище пользователей, обратитесь к администратору LDAP.
UserNameAttribute = "uid"
- Укажите следующие свойства, необходимые для подключения к LDAP с целью выполнения различных задач:
ConnectionURL = "ldap://localhost:<LDAPServerPort>"
ConnectionName = "uid=admin,ou=system"
ConnectionPassword = "admin"
Примечание: если вы используете ldaps (защищенный LDAP) для подключения к LDAP, вам необходимо установить параметр ConnectionURL как показано ниже:
ConnectionURL = "ldaps://ldap1.example.local:636"
Также необходимо включить пул соединений для LDAPS-соединений при запуске сервера, что повысит его производительность.
-
В продуктах NEOMSA APIM на базе Carbon 4.5.x можно установить LDAPConnectionTimeout. Если соединение с LDAP остается неактивным в течение времени (в миллисекундах), указанного этим свойством, соединение будет разорвано.
-
Установите свойство ReadGroups в значение «true», если разрешено чтение ролей из этого хранилища пользователей. Если это свойство имеет значение «true», необходимо также указать значения и для свойств GroupSearchBase, GroupSearchFilter и GroupNameAttribute. Если свойство установлено в значение «false», из хранилища пользователей можно читать только пользователей. Вы можете настроить чтение ролей из хранилища пользователей, считывая сопоставление пользователя/роли на основе членства или атрибута обратной ссылки, как показано ниже. Чтобы прочитать сопоставление пользователя/роли на основе членства (это используется в ApacheDirectory и OpenLDAP):
- Включите свойство ReadGroups:
ReadGroups = "true"
- Установите свойство GroupSearchBase, указав имя каталога, где хранятся роли. Роли, созданные с помощью консоли управления вашего продукта, будут храниться в этом каталоге. Кроме того, при поиске групп LDAP он будет начинать поиск с этого каталога. Например:
GroupSearchBase = "ou=system,CN=Users,DC=example,DC=local"
- Установите атрибуты GroupSearchFilter и GroupNameAttributes. Например:
GroupSearchFilter = "(objectClass=groupOfNames)"
GroupNameAttribute = "cn"
- Установите MembershipAttribute, как показано ниже:
MembershipAttribute = "member"
Для чтения ролей на основе атрибута обратной ссылки используйте следующий фрагмент кода вместо приведенного выше:
ReadGroups = "false"
GroupSearchBase = "ou=system"
GroupSearchFilter = "(objectClass=groupOfNames)"
GroupNameAttribute = "cn"
MembershipAttribute = "member"
BackLinksEnabled = "true"
MembershipOfAttribute = "memberOf"
Шаг 2: Обновление системного администратора
Администратор - это суперпользователь, который сможет управлять всеми остальными пользователями, ролями и разрешениями в системе с помощью консоли управления продукта. Поэтому пользователь, обладающий правами администратора, должен быть сохранен в хранилище пользователей при первом запуске системы. Поскольку в хранилище пользователей LDAP можно записывать данные, у вас есть возможность создать нового администратора в хранилище пользователей при первом запуске системы. В качестве альтернативы вы также можете использовать идентификатор пользователя, уже существующий в LDAP.
Эти две альтернативные конфигурации могут быть выполнены, как описано ниже.
- Если вы используете пользователя, который уже есть в LDAP, найдите действительного пользователя, который уже находится в хранилище пользователей. Например, допустимое имя пользователя — AdminSOA. Добавьте в файл deployment.toml следующую конфигурацию, как показано ниже. Вам не нужно обновлять элемент пароля, так как он уже установлен в хранилище пользователей:
[super_admin]
username = "AdminSOA"
admin_role = "admin"
create_admin_account = false
- Если вы создаете нового администратора в хранилище пользователей при запуске системы, вы можете добавить в него пользователя с правами суперпользователя. Добавьте в deployment.toml файл следующую конфигурацию, как показано ниже.
[super_admin]
username = "AdminSOA"
admin_role = "admin"
create_admin_account = true
password = "admin"
Шаг 3: Запуск сервера
Запустите сервер и попробуйте войти в систему под учетной записью администратора, указанной на шаге 2.
Настройка LDAP хранилища пользователей только для чтения¶
Предполагается, что вы уже настроили хранилище пользователей LDAP только для чтения. Выполните следующие шаги, чтобы настроить его в качестве основного хранилища пользователей в NEOMSA APIM:
-
Шаг 1: Настройка менеджера хранилища пользователей LDAP/AD только для чтения
-
Шаг 2: Обновление системного администратора
-
Шаг 3: Запуск сервера
Обратите внимание: APIM совместим с несколькими хранилищами пользователей. Вместо использования встроенного хранилища пользователей вы можете установить собственное хранилище пользователей в качестве основного.
Шаг 1: Настройка менеджера хранилища пользователей LDAP/AD только для чтения
Ниже приведены минимальные параметры конфигурации, необходимые для настройки менеджера хранилища пользователей LDAP только для чтения.
| Название конфигурации | Отображаемое имя | Описание |
|---|---|---|
| type | userstore Type | Указывает на тип используемого нами менеджера хранилища пользователей. Для менеджера хранилища пользователей LDAP только для чтения это значение должно быть read_only_ldap_unique_id. |
| base_dn | User Search Base | DN контекста или объекта, под которым хранятся записи пользователей в хранилище пользователей. При поиске пользователей хранилище пользователей начинает поиск с этого места в каталоге. Примеры значений: ou=Users,dc=example,dc=local |
Ниже перечислены минимальные свойства хранилища пользователей, которые необходимо указать для настройки менеджера хранилища пользователей LDAP с возможностью только чтения:
| Идентификатор объекта недвижимости | Основное свойство хранилища пользователей | Вторичное хранилище пользовательских данных | Описание |
|---|---|---|---|
| ConnectionURL | connection_url | Connection URL | URL-адрес подключения к серверу хранилища пользователей. Примеры значений: ldap://ldap1.example.local:389 ldaps://ldap2.example.local:639 Если вы подключаетесь через LDAPS (защищенный LDAP), необходимо импортировать сертификат хранилища пользователей в файл client-truststore.jks продукта APIM. |
| ConnectionName | connection_name | Connection Name | Имя пользователя, используемое для подключения к хранилищу пользователей и выполнения различных операций. Этот пользователь не обязательно должен быть администратором в хранилище пользователей или иметь роль администратора в используемом вами продукте APIM, но этот пользователь ОБЯЗАТЕЛЬНО должен иметь разрешения на чтение списка пользователей и атрибутов пользователей, а также на выполнение операций поиска в хранилище пользователей. Указанное вами значение используется в качестве атрибута DN (Distinguish Name) пользователя, имеющего достаточные права для выполнения операций с пользователями и ролями в LDAP. Это свойство является обязательным. Примеры значений: uid=admin,ou=system |
| ConnectionPassword | connection_password | Connection Password | Пароль для пользователя ConnectionName. |
Замените user_store конфигурацию по умолчанию в файле <APIM-HOME>/repository/conf/deployment.toml в соответствии с конфигурацией вашего LDAP-сервера. Пример конфигурации приведен ниже:
[user_store]
type = "read_only_ldap_unique_id"
base_dn = "ou=system"
connection_url = "ldap://localhost:10389"
connection_name = "uid=admin,ou=system"
connection_password = "admin"
Помимо вышеперечисленных свойств, NEOMSA APIM также поддерживает расширенные конфигурации LDAP.
Свойства, используемые в менеджере хранилища пользователей LDAP с возможностью только чтения
Перечень свойств в менеджере хранилища пользователей LDAP с возможностью только чтения идентичен списку свойств, используемых в менеджере хранилища пользователей LDAP с возможностью чтения и записи и приведен в соответствующей таблице в разделе 3.2.7.3 Настройка LDAP хранилища пользователей с возможностью чтения и записи.
Дополнительно доступно свойство SCIMEnabled:
| Property Id | Primary Userstore Property | Secondary Userstore Property | Описание |
|---|---|---|---|
| SCIMEnabled | scim_enabled | Enable SCIM | Параметр позволяет настроить поддержку хранилища пользователей для SCIM-проведения. Возможные значения: True - поддержка SCIM-проведения в хранилище пользователей. False - хранилище пользователей не поддерживает SCIM-проведение. Значение по умолчанию: true. |
Любое из свойств можно настроить для PRIMARY-хранилища пользователей, добавив его в файл <APIM-HOME>/repository/conf/deployment.toml следующим образом:
[user_store]
<Property-Name> = <Property-Value>
Например:
[user_store]
read_groups = true
Ниже приведены некоторые ключевые моменты, которые следует учитывать:
- Обновите данные подключения в соответствии с вашим хранилищем пользователей. Например:
ConnectionURL="ldap://localhost:10390"
Для Active Directory URL-адрес подключения должен иметь следующий формат:
ConnectionURL="ldap://<AD host-ip>:<AD_listen_port>"
Примечание: если вы используете ldaps (защищенный LDAP) для подключения к LDAP/Active Directory:
- Вам необходимо установить параметр ConnectionURL как показано ниже:
ConnectionURL="ldaps://ldap1.example.local:636"
-
Для Active Directory необходимо импортировать сертификат Active Directory в client-truststore.jks.
-
Также необходимо включить пул соединений для LDAPS-соединений при запуске сервера, что повысит его производительность.
-
Получите у администратора LDAP/Active Directory данные пользователя, имеющего разрешение на чтение всех пользователей/атрибутов и выполнение поиска в хранилище пользователей. Например, если привилегированный пользователь — admin и пароль — admin, обновите следующие разделы конфигурации хранилища пользователей, как показано ниже:
ConnectionName="uid=admin,ou=system"
ConnectionPassword="admin"
Обратите внимание, что этот пользователь НЕ обязательно должен быть системным администратором, которого вы здесь определили.
- Укажите имя каталога UserSearchBase, где хранятся пользователи. При поиске пользователей LDAP начнет поиск с этого каталога.
UserSearchBase="ou=system"
- Укажите атрибут, который будет использоваться в качестве имени пользователя, обычно это `cn` либо `uid` для LDAP. В идеале UserNameAttribute и UserNameSearchFilter должны ссылаться на один и тот же атрибут. Если вы не уверены, какой атрибут доступен в вашем хранилище пользователей, обратитесь к администратору LDAP/Active Directory. Например:
UserNameAttribute="uid"
UserNameSearchFilter="(&(objectClass=person)(uid=?))"
-
Установите свойство ReadGroups в значение «true», если разрешено чтение ролей из этого хранилища пользователей. Если это свойство имеет значение «true», необходимо также указать значения и для свойств GroupSearchBase, GroupSearchFilter и GroupNameAttribute. Если свойство установлено в значение «false», из хранилища пользователей можно читать только пользователей. Вы можете настроить чтение ролей из хранилища пользователей, считывая сопоставление пользователя/роли на основе членства или атрибута обратной ссылки, как показано ниже. Чтобы прочитать сопоставление пользователя/роли на основе членства (это используется в ApacheDirectory и OpenLDAP):
- Включите свойство ReadGroups:
ReadGroups = "true"
- Установите свойство GroupSearchBase, указав имя каталога, где хранятся роли. Роли, созданные с помощью консоли управления вашего продукта, будут храниться в этом каталоге. Кроме того, при поиске групп LDAP он будет начинать поиск с этого каталога. Например:
GroupSearchBase = "ou=system,CN=Users,DC=example,DC=local"
- Установите атрибуты GroupSearchFilter и GroupNameAttributes. Например:
GroupSearchFilter = "(objectClass=groupOfNames)"
GroupNameAttribute = "cn"
- Установите MembershipAttribute, как показано ниже:
MembershipAttribute = "member"
Для чтения ролей на основе атрибута обратной ссылки используйте следующий фрагмент кода вместо приведенного выше:
ReadGroups = "true"
GroupSearchBase="ou=system,CN=Users,DC=example,DC=local"
GroupSearchFilter = "(objectClass=groupOfNames)"
GroupNameAttribute = "cn"
MembershipAttribute = "member"
BackLinksEnabled = "false"
MembershipOfAttribute = "memberOf"
-
Для Active Directory можно использовать параметр Referral="follow" для включения переадресации запросов внутри хранилища пользователей. Хранилище пользователей AD может быть разделено на несколько доменов. Однако, согласно конфигурациям хранилища пользователей в файле deployment.toml, мы подключаемся только к одному из доменов. Поэтому, когда в хранилище пользователей поступает запрос на объект, свойство Referral="follow" гарантирует, что для поиска запрошенного объекта будут выполнены поиски во всех доменах каталога.
-
Вы можете установить свойство LDAPConnectionTimeout. Если соединение с LDAP остается неактивным в течение времени (в миллисекундах), указанного этим свойством, соединение будет разорвано.
Ниже приведён пример <APIM-HOME>/repository/conf/deployment.toml-файла user_store_properties, содержащего данные только для чтения, относящиеся к LDAP:
[user_store.properties]
ConnectionURL="ldap://localhost:10390"
ConnectionName="uid=admin,ou=system"
ConnectionPassword="admin"
AnonymousBind="false"
UserNameAttribute="uid"
UserNameSearchFilter="(&(objectClass=person)(uid=?))"
ReadGroups="true"
GroupSearchBase="ou=system,CN=Users,DC=example,DC=local"
GroupNameAttribute="cn"
GroupNameSearchFilter="(&(objectClass=groupOfNames)(cn=?))"
GroupNameListFilter="(objectClass=groupOfNames)"
MembershipAttribute="member"
BackLinksEnabled="false"
UsernameJavaRegEx="[a-zA-Z0-9._\-|//]{3,30}$"
PasswordJavaRegEx="^[\S]{5,30}$"
SCIMEnabled="true"
PasswordHashMethod="PLAIN_TEXT"
MultiAttributeSeparator=","
MaxUserNameListLength="100"
MaxRoleNameListLength="100"
UserRolesCacheEnabled="true"
LDAPConnectionTimeout=5000
ReplaceEscapeCharactersAtUserLogin="true"
ConnectionRetryDelay="120000"
GroupSearchFilter="(objectClass=groupOfNames)"
UserEntryObjectClass="identityPerson"
IsBulkImportSupported="true"
defaultRealmName="WSO2.ORG"
EmptyRolesAllowed="true"
UserSearchBase="ou=Users,dc=example,dc=local"
ConnectionPoolingEnabled="false"
StartTLSEnabled="false"
WriteGroups="true"
RolenameJavaRegEx="[a-zA-Z0-9._\-|//]{3,30}$"
GroupEntryObjectClass="groupOfNames"
EnableMaxUserLimitForSCIM="false"
PasswordJavaRegExViolationErrorMsg="Password length should be within 5 to 30 characters"
PasswordJavaScriptRegEx="^[\S]{5,30}$"
UsernameJavaRegExViolationErrorMsg="Username pattern policy violated"
UserNameListFilter="(objectClass=person)"
UsernameJavaScriptRegEx="^[\S]{3,30}$"
kdcEnabled="false"
Шаг 2: Обновление системного администратора
Администратор - это суперпользователь , который сможет управлять всеми остальными пользователями, ролями и разрешениями в системе с помощью консоли управления продукта. Поэтому пользователь, обладающий правами администратора, должен быть сохранен в хранилище пользователей при первом запуске системы. По умолчанию система создаст пользователя-администратора в LDAP с правами администратора. Но это невозможно, если хранилище пользователей LDAP доступно только для чтения. Поэтому эту возможность следует отключить в файле <APIM-HOME>/repository/conf/deployment.toml следующим образом:
[super_admin]
username = "AdminSOA"
admin_role = "admin"
create_admin_account = false
-
create_admin_account: Этот параметр следует установить в значение 'False', поскольку в этом случае создание пользователей и ролей в хранилище пользователей только для чтения будет запрещено.
-
admin_role: Указанная здесь роль администратора должна уже существовать в хранилище пользователей только для чтения. В противном случае необходимо указать внутреннюю роль, которая будет сохранена во внутренней базе данных системы при первом запуске системы.
-
Имя пользователя: Поскольку мы настраиваем LDAP только для чтения в качестве основного хранилища пользователей, пользователь, имеющий права администратора, должен быть сохранен в хранилище пользователей при первом запуске системы. Например, допустимое имя пользователя — AdminSOA. Обновите раздел username вашей конфигурации, как показано выше. Вам не нужно обновлять элемент пароля, поскольку он уже установлен в хранилище пользователей.
Если хранилище пользователей доступно для записи, вы можете добавить пользователя-суперпользователя в хранилище пользователей. Поэтому параметр create_admin_account следует установить в значение true, как показано ниже.
[super_admin]
username = "admin"
admin_role = "admin"
create_admin_account = true
Шаг 3: Запуск сервера
Запустите сервер и попробуйте войти в систему под указанным вами именем администратора. Пароль — это пароль администратора на LDAP-сервере.
Настройка Active Directory хранилища пользователей с возможностью чтения и записи¶
Выполните следующие шаги, чтобы настроить внешний Active Directory в качестве основного хранилища пользователей:
-
Шаг 1: Настройка внешнего менеджера хранилища пользователей Active Directory.
-
Шаг 2: Обновление системного администратора
-
Шаг 3: Запуск сервера
Шаг 1: Настройка внешнего менеджера хранилища пользователей Active Directory
- Перейдите в <APIM-HOME>/repository/conf, чтобы открыть deployment.toml-файл и выполнить настройку параметра user_store_properties. Ниже приведен пример конфигурации хранилища пользователей Active Directory для чтения и записи:
[user_store.properties]
TenantManager="org.wso2.carbon.user.core.tenant.CommonHybridLDAPTenantManager"
ConnectionURL="ldaps://ldap2.example.local:639"
ConnectionName="CN=admin,CN=Users,DC=example,DC=local"
ConnectionPassword="A1b2c3d4"
AnonymousBind="false"
UserSearchBase="CN=Users,DC=example,DC=local"
UserEntryObjectClass="user"
UserNameAttribute="cn"
UserNameSearchFilter="(&(objectClass=user)(cn=?))"
UserNameListFilter="(&(objectClass=user)(!(sn=Service)))"
ReadGroups="true"
WriteGroups="true"
GroupSearchBase="CN=Users,DC=example,DC=local"
GroupEntryObjectClass="group"
GroupNameAttribute="cn"
GroupNameSearchFilter="(&(objectClass=group)(cn=?))"
GroupNameListFilter="(objectcategory=group)"
MembershipAttribute="member"
MemberOfAttribute="memberOf"
BackLinksEnabled="true"
Referral="follow"
UsernameJavaRegEx="[a-zA-Z0-9._\-|//]{3,30}$"
UsernameJavaScriptRegEx="^[\S]{3,30}$"
UsernameJavaRegExViolationErrorMsg="Username pattern policy violated"
PasswordJavaRegEx="^[\S]{5,30}$"
PasswordJavaScriptRegEx="^[\S]{5,30}$"
PasswordJavaRegExViolationErrorMsg="Password length should be within 5 to 30 characters"
RolenameJavaRegEx="[a-zA-Z0-9._\-|//]{3,30}$"
RolenameJavaScriptRegEx="^[\S]{3,30}$"
SCIMEnabled="false"
IsBulkImportSupported="false"
EmptyRolesAllowed="true"
PasswordHashMethod="PLAIN_TEXT"
MultiAttributeSeparator=","
isADLDSRole="false"
userAccountControl="512"
MaxUserNameListLength="100"
MaxRoleNameListLength="100"
MembershipAttributeRange="1500"
kdcEnabled="false"
defaultRealmName="WSO2.ORG"
UserRolesCacheEnabled="true"
ConnectionPoolingEnabled="false"
LDAPConnectionTimeout="5000"
StartTLSEnabled="false"
ConnectionRetryDelay="120000"
- Атрибут class для внешнего Active Directory — это org.wso2.carbon.user.core.ldap.ActiveDirectoryUserStoreManager:
[user_store]
class="org.wso2.carbon.user.core.ldap.ActiveDirectoryUserStoreManager"
type = "active_directory"
base_dn = "cn=Users,dc=example,dc=local"
Примечание: обратите внимание, что эти настройки будут автоматически применены к user-mgt.xml-файлу, поэтому вам не нужно его редактировать.
Ниже приведен пример конфигурации внешнего хранилища пользователей с возможностью чтения/записи user-mgt.xml:
<UserStoreManager class="org.wso2.carbon.user.core.ldap.ActiveDirectoryUserStoreManager">
<Property name="IsBulkImportSupported">true</Property>
<Property name="MaxUserNameListLength">100</Property>
<Property name="defaultRealmName">WSO2.ORG</Property>
<Property name="isADLDSRole">false</Property>
<Property name="userAccountControl">512</Property>
<Property name="EmptyRolesAllowed">true</Property>
<Property name="MultiAttributeSeparator">,</Property>
<Property name="MembershipAttributeRange">1500</Property>
<Property name="DisplayNameAttribute"></Property>
<Property name="TenantManager">org.wso2.carbon.user.core.tenant.CommonHybridLDAPTenantManager</Property>
<Property name="UserSearchBase">ou=Users,cn=Users,dc=example,dc=local</Property>
<Property name="GroupNameSearchFilter">(&(objectClass=groupOfNames)(cn=?))</Property>
<Property name="ConnectionPoolingEnabled">false</Property>
<Property name="StartTLSEnabled">false</Property>
<Property name="UserNameSearchFilter">(&(objectClass=person)(uid=?))</Property>
<Property name="LDAPConnectionTimeout">5000</Property>
<Property name="UserNameAttribute">uid</Property>
<Property name="GroupNameAttribute">cn</Property>
<Property name="UsernameJavaRegEx">[a-zA-Z0-9._-|//]{3,30}$</Property>
<Property name="WriteGroups">true</Property>
<Property name="AnonymousBind">false</Property>
<Property name="RolenameJavaScriptRegEx">^[\S]{3,30}$</Property>
<Property name="RolenameJavaRegEx">[a-zA-Z0-9._-|//]{3,30}$</Property>
<Property name="GroupEntryObjectClass">groupOfNames</Property>
<Property name="PasswordJavaRegEx">^[\S]{5,30}$</Property>
<Property name="PasswordHashMethod">PLAIN_TEXT</Property>
<Property name="GroupSearchBase">ou=Groups,cn=Users,dc=example,dc=local</Property>
<Property name="ReadGroups">true</Property>
<Property name="ReplaceEscapeCharactersAtUserLogin">true</Property>
<Property name="ConnectionRetryDelay">120000</Property>
<Property name="MembershipAttribute">member</Property>
<Property name="Referral">follow</Property>
<Property name="UserEntryObjectClass">identityPerson</Property>
<Property name="PasswordJavaRegExViolationErrorMsg">Password length should be within 5 to 30 characters</Property>
<Property name="MaxRoleNameListLength">100</Property>
<Property name="PasswordJavaScriptRegEx">^[\S]{5,30}$</Property>
<Property name="BackLinksEnabled">false</Property>
<Property name="UsernameJavaRegExViolationErrorMsg">Username pattern policy violated</Property>
<Property name="UserRolesCacheEnabled">true</Property>
<Property name="GroupNameListFilter">(objectClass=groupOfNames)</Property>
<Property name="SCIMEnabled">false</Property>
<Property name="UserNameListFilter">(objectClass=person)</Property>
<Property name="MemberOfAttribute">memberOf</Property>
<Property name="UsernameJavaScriptRegEx">^[\S]{3,30}$</Property>
<Property name="kdcEnabled">false</Property>
</UserStoreManager>
При работе с Active Directory учитывайте следующее:
- Рекомендуется включить свойство GetAllRolesOfUserEnabled следующим образом:
<AuthorizationManager class="org.wso2.carbon.user.core.authorization.JDBCAuthorizationManager">
<Property name="AdminRoleManagementPermissions">/permission</Property>
<Property name="AuthorizationCacheEnabled">true</Property>
<Property name="GetAllRolesOfUserEnabled">true</Property>
</AuthorizationManager>
Хотя использование менеджера хранилища пользователей не зависит от этого свойства, его включение необходимо рассмотреть, если в вашей производственной среде возникают проблемы с производительностью. Включение этого свойства влияет на производительность при входе пользователя в систему. Это зависит от пользователей, ролей и статистики разрешений.
- Если вы используете ldaps (защищенный LDAP) для подключения к Active Directory, как показано в примере ниже, вам необходимо импортировать сертификат Active Directory в client-truststore.jks:
ConnectionURL="ldaps://ldap1.example.local:636"
-
Также необходимо включить пул соединений для LDAPS-соединений при запуске сервера, что повысит его производительность.
-
Если вы настраиваете основное хранилище пользователей и хотите, чтобы конфигурация была доступна для всех арендаторов, следуйте приведенной ниже настройке, чтобы получить атрибут утверждения objectGUID. ObjectGUID — это бинарный атрибут. Добавьте в файл deployment.toml следующее свойство хранилища пользователей:
transformObjectGUIDToUUID="false"
-
Для Active Directory можно использовать параметр Referral="follow" для включения переадресации запросов внутри хранилища пользователей. Хранилище пользователей AD может быть разделено на несколько доменов. Однако, согласно конфигурациям хранилища пользователей в файле deployment.toml, мы подключаемся только к одному из доменов. Поэтому, когда в хранилище пользователей поступает запрос на объект, свойство Referral="follow" гарантирует, что для поиска запрошенного объекта будут выполнены поиски во всех доменах каталога.
-
Укажите атрибут, который будет использоваться в качестве имени пользователя, обычно это `cn` либо `uid` для LDAP. В идеале UserNameAttribute и UserNameSearchFilter должны ссылаться на один и тот же атрибут. Если вы не уверены, какой атрибут доступен в вашем хранилище пользователей, обратитесь к администратору LDAP/Active Directory. Например:
UserNameAttribute=" cn"
UserNameSearchFilter="(&(objectClass=person)( cn=?))"
-
Вы можете установить свойство LDAPConnectionTimeout. Если соединение с LDAP остается неактивным в течение времени (в миллисекундах), указанного этим свойством, соединение будет разорвано.
-
Установите свойство ReadGroups в значение «true», если разрешено чтение ролей из этого хранилища пользователей. Если это свойство имеет значение «true», необходимо также указать значения и для свойств GroupSearchBase, GroupSearchFilter и GroupNameAttribute. Если свойство установлено в значение «false», из хранилища пользователей можно читать только пользователей. Вы можете настроить чтение ролей из хранилища пользователей, считывая сопоставление пользователя/роли на основе членства или атрибута обратной ссылки, как показано ниже. Чтобы прочитать сопоставление пользователя/роли на основе членства (это используется в ApacheDirectory и OpenLDAP):
- Включите свойство ReadGroups:
ReadGroups = "true"
- Установите свойство GroupSearchBase, указав имя каталога, где хранятся роли. Роли, созданные с помощью консоли управления вашего продукта, будут храниться в этом каталоге. Кроме того, при поиске групп LDAP он будет начинать поиск с этого каталога. Например:
GroupSearchBase="ou=Groups,cn=Users,dc=example,dc=local"
- Установите атрибуты GroupSearchFilter и GroupNameAttributes. Например:
GroupNameSearchFilter="(&(objectClass=groupOfNames)(cn=?))"
GroupNameAttribute="cn"
- Установите MembershipAttribute, как показано ниже:
MembershipAttribute = "member"
Для чтения ролей на основе атрибута обратной ссылки используйте следующий фрагмент кода вместо приведенного выше:
ReadGroups="false"
GroupSearchBase="ou=system"
GroupNameSearchFilter="(objectClass=groupOfNames)"
GroupNameAttribute="cn"
MembershipAttribute="member"
BackLinksEnabled="true"
MembershipOfAttribute="memberOf"
Шаг 2: Обновление системного администратора
Администратор — это суперпользователь, который сможет управлять всеми остальными пользователями, ролями и разрешениями в системе с помощью консоли управления продукта. Поэтому пользователь, обладающий правами администратора, должен быть сохранен в хранилище пользователей при первом запуске системы. Поскольку в хранилище пользователей Active Directory можно записывать данные, у вас есть возможность создать нового администратора в хранилище пользователей при первом запуске системы. В качестве альтернативы вы также можете использовать идентификатор пользователя, уже существующий в хранилище пользователей.
Эти две альтернативные конфигурации могут быть выполнены, как описано ниже.
- Найдите действительного пользователя, который уже есть в хранилище пользователей. Например, допустимое имя пользователя — AdminSOA. Обновите раздел [super_admin] вашей конфигурации, как показано ниже. Вам не нужно обновлять элемент пароля, поскольку он уже установлен в хранилище пользователей.
[super_admin]
username = "AdminSOA"
admin_role = "admin"
create_admin_account = false
- Если хранилище пользователей доступно для записи, вы можете добавить пользователя-суперпользователя в хранилище пользователей. Поэтому параметр create_admin_account следует установить в значение `true`, как показано ниже:
[super_admin]
username = "admin"
admin_role = "admin"
create_admin_account = true
Шаг 3: Запуск сервера
Запустите сервер и попробуйте войти в систему под указанным вами именем администратора.
Настройка хранилища пользователей Active Directory с возможностью чтения и записи
Ниже приведены минимальные параметры конфигурации, необходимые для настройки менеджера хранилища пользователей Active Directory с возможностью чтения и записи:
| Название конфигурации | Отображаемое имя | Описание |
|---|---|---|
| type | userstore Type | Указывает на тип используемого нами менеджера хранилища пользователей. Для менеджера хранилища пользователей LDAP только для чтения это значение должно быть read_only_ldap_unique_id. |
| base_dn | User Search Base | DN контекста или объекта, под которым хранятся записи пользователей в хранилище пользователей. При поиске пользователей хранилище пользователей начинает поиск с этого места в каталоге. Примеры значений: ou=Users,dc=example,dc=local |
Свойства, используемые в хранилище пользователей Active Directory с возможностью чтения и записи
В следующей таблице перечислены свойства, используемые в Active Directory для чтения и записи, и их описание. Любое из следующих свойств можно настроить для PRIMARY-хранилища пользователей, добавив его следующим образом в файл <APIM-HOME>/repository/conf/deployment.toml:
| Property Id | Primary Userstore Property | Secondary Userstore Property | Описание |
|---|---|---|---|
| UserEntryObjectClass | user_entry_object_class | User Entry Object Class | Класс объекта, используемый для создания записей пользователей. По умолчанию: identityPerson (это пользовательский класс объекта, определенный в APIM Identity Server) |
| UserNameAttribute | user_name_attribute | Username Attribute | Уникальный идентификационный атрибут, представляющий собой имя пользователя. Аутентификация пользователей может осуществляться с помощью адреса электронной почты, UID и т. д. Значение атрибута считается именем пользователя. По умолчанию: uid |
| UserNameSearchFilter | user_name_search_filter | User Search Filter | Критерии фильтрации, используемые для поиска конкретной записи пользователя. По умолчанию: (&(objectClass=identityPerson)(uid=?)) |
| UserNameListFilter | user_name_list_filter | User List Filter | Критерии фильтрации для поиска записей пользователей в хранилище пользователей. Этот запрос или фильтр используется при поиске пользователей с различными атрибутами поиска. По умолчанию: (objectClass=identityPerson). В этом случае поиск отображает только объекты, созданные на основе класса объектов person |
| UserDNPattern | user_dn_pattern | User DN Pattern | Шаблон для DN пользователя, который можно определить для улучшения поиска. Когда в хранилище пользователей LDAP много записей о пользователях, определение UserDNPattern оказывает большее влияние на производительность, поскольку LDAP не нужно проходить по всему дереву, чтобы найти пользователей. Пример значений: uid={0},ou=Users,dc=example,dc=local |
| DisplayNameAttribute | display_name_attribute | Display name attribute | Это необязательное свойство. Атрибут «Отображаемое имя» — это имя, под которым пользователи будут отображаться в списке пользователей в консоли управления. По умолчанию: blank |
| ReadGroups | read_groups | Read Groups | Если параметр WriteGroups установлен в значение false, это указывает, следует ли считывать группы из хранилища пользователей. Если эта функция отключена путем установки значения false, ни одна из групп в хранилище пользователей не может быть прочитана, и следующие параметры конфигурации групп НЕ являются обязательными: GroupSearchBase, GroupNameListFilter или GroupNameAttribute. По умолчанию: true Возможные значения: true: читать группы из хранилища пользователей false: не читать группы из хранилища пользователей |
| WriteGroups | write_groups | Write Groups | Указывает, следует ли записывать группы в хранилище пользователей. По умолчанию: true. Возможные значения: true: записывать группы в хранилище пользователей; false: не записывать группы в хранилище пользователей, поэтому могут быть созданы только внутренние роли. В зависимости от значения свойства ReadGroups, будет ли оно считывать существующие группы из хранилища пользователей или нет |
| GroupSearchBase | group_search_base | Group Search Base | DN контекста или объекта, под которым хранятся записи групп в хранилище пользователей. При поиске групп хранилище пользователей начинает поиск с этого места в каталоге. По умолчанию: ou=Groups,dc=example,dc=local |
| GroupEntryObjectClass | group_entry_object_class | Group Entry Object Class | Класс объекта, используемый для создания записей группы. По умолчанию: groupOfNames |
| GroupNameAttribute | group_name_attribute | Group Name Attribute | Атрибут, используемый для уникальной идентификации записи группы. Этот атрибут следует рассматривать как название группы. По умолчанию: cn |
| GroupNameSearchFilter | group_name_search_filter | Group Search Filter | Критерии фильтрации, используемые для поиска записи в определенной группе. По умолчанию: (&(objectClass=groupOfNames)(cn=?)) |
| GroupNameListFilter | group_name_list_filter | Group List Filter | Критерии фильтрации для поиска групповых записей в хранилище пользователей. Этот запрос или фильтр используется при поиске групп с различными атрибутами поиска. По умолчанию: ((objectClass=groupOfNames)) В этом случае операция поиска предоставляет только объекты, созданные из класса объектов groupOfName. |
| RoleDNPattern | role_dn_pattern | Role DN Pattern | Шаблон для DN группы, который можно определить для улучшения поиска. Когда в хранилище пользователей LDAP много записей о группах, определение RoleDNPattern оказывает большее влияние на производительность, поскольку LDAP не нужно проходить по всему дереву, чтобы найти группу. Пример значений: cn={0},ou=Groups,dc=example,dc=local |
| MembershipAttribute | membership_attribute | Membership Attribute | Определяет атрибут, содержащий отличительные имена (DN) пользовательских объектов, входящих в группу. По умолчанию: member |
| MemberOfAttribute | member_of_attribute | Member Of Attribute | Определите атрибут, содержащий отличительные имена (DN) групповых объектов, к которым назначен пользователь. Возможные значения: memberOf |
| BackLinksEnabled | back_links_enabled | Enable Back Links | Определяет, включена ли поддержка обратных ссылок. Если вы используете атрибуты MemberOfAttribute, это значение следует установить на 'true'. По умолчанию: false |
| UsernameJavaRegEx | username_java_regex | Username RegEx (Java) | Регулярное выражение, используемое серверными компонентами для проверки имени пользователя. По умолчанию допускается длина строк, содержащих непустые символы, от 3 до 30 символов. В свойствах RegEx можно указать диапазоны букв, цифр, а также диапазоны значений ASCII. По умолчанию: [a-zA-Z0-9._-|//]{3,30}$ |
| UsernameJava ScriptRegEx |
username_java_ script_regex |
Username RegEx (Javascript) | Регулярное выражение, используемое компонентами интерфейса для проверки имени пользователя. По умолчанию: ^[\S]{3,30}$ |
| UsernameJavaReg ExViolationErrorMsg |
username_java_reg_ ex_violation_error_msg |
Username RegEx Violation Error Message | Сообщение об ошибке, если имя пользователя не соответствует шаблону UsernameJavaRegEx По умолчанию: Username pattern policy violated |
| PasswordJavaRegEx | password_java_regex | Password RegEx (Java) | Регулярное выражение, используемое серверными компонентами для проверки паролей. По умолчанию допускается длина строк, содержащих непустые символы, от 5 до 30 символов. В свойствах RegEx можно указать диапазоны букв, цифр, а также диапазоны значений ASCII. По умолчанию: ^[\S]{5,30}$ |
| PasswordJava ScriptRegEx |
password_java_ script_regex |
Password RegEx (Javascript) | Регулярное выражение, используемое компонентами интерфейса для проверки паролей. По умолчанию: ^[\S]{5,30}$ |
| PasswordJavaReg ExViolationErrorMsg |
password_java_reg ex_violation_error_msg |
Password RegEx Violation Error Message | Сообщение об ошибке, если пароль не соответствует регулярным выражениям JavaJava. По умолчанию длина пароля должна быть от 5 до 30 символов |
| RolenameJavaRegEx | rolename_java_regex | Role Name RegEx (Java) | Регулярное выражение, используемое серверными компонентами для проверки имен ролей. По умолчанию допускается длина строк, содержащих непустые символы, от 3 до 30 символов. В свойствах RegEx можно указать диапазоны букв, цифр, а также диапазоны значений ASCII. По умолчанию: [a-zA-Z0-9._-|//]{3,30}$ |
| SCIMEnabled | scim_enabled | Enable SCIM | Параметр определяет, поддерживается ли хранилище пользователей для SCIM-проведения. Возможные значения: True: Поддержка SCIM-проведения в хранилище пользователей. False: Хранилище пользователей не поддерживает SCIM-проведение. Значение по умолчанию: false. |
| PasswordHashMethod | password_hash_method | Password Hashing Algorithm | Указывает алгоритм хеширования паролей, используемый для хеширования пароля перед сохранением в хранилище пользователя. Возможные значения: SHA — использует метод дайджеста SHA. SHA-1, SHA-256. MD5 — использует метод дайджеста MD5. PLAIN_TEXT — пароли в открытом виде (по умолчанию). Если вы просто настроите SHA, он будет считаться SHA-1. Всегда лучше настраивать алгоритм с более высоким битовым значением, так как размер бита дайджеста увеличится. Большинство LDAP-серверов (таких как OpenLDAP, OpenDJ, AD, ApacheDS и т. д.) поддерживают хранение паролей в виде salted hashed values (SSHA). Поэтому NEOMSA APIM просто передает пароль в подключенное хранилище пользователей в виде открытого текста. Затем хранилище пользователей LDAP может хранить его в виде хешированного значения. Чтобы передать открытый текст на LDAP-сервер, необходимо установить PasswordHashMethod в значение “PLAIN_TEXT”. Но если ваш LDAP не поддерживает хранение паролей пользователей в виде хешированных значений, вы можете настроить сервер APIM для хеширования пароля и передачи хешированного пароля на LDAP-сервер. В этом случае вам необходимо настроить свойство PasswordHashMethod с использованием SHA (SHA-1), SHA-256, SHA-512. Обратите внимание, что сервер APIM не может создать пароль с хешированием (SSHA) для передачи в LDAP. |
| MultiAttributeSeparator | multi_attribute_separator | Multiple Attribute Separator | Это свойство используется для определения символа, разделяющего несколько атрибутов. Это гарантирует, что он не будет отображаться как часть значения. Обычно для разделения нескольких атрибутов используется запятая («,»), но вы можете определить «,,,» или «...» или аналогичную последовательность символов. По умолчанию: «,» |
| MaxUserName ListLength |
max_user_name _list_length |
Maximum User List Length | Этот параметр управляет количеством пользователей, отображаемых в хранилище пользователей продукта. Это полезно, когда у вас большое количество пользователей, и вы не хотите отображать их всех. Установка этого свойства в 0 отображает всех пользователей. Значение по умолчанию: 100. В некоторых хранилищах пользователей существуют политики, ограничивающие количество записей, которые могут быть возвращены запросом. Установка значения 0 отобразит максимальное количество результатов, возвращаемых хранилищем пользователей. Если вам нужно увеличить это значение, необходимо установить его на уровне хранилища пользователей. Например: в Active Directory есть свойство MaxPageSize со значением по умолчанию 1000 |
| MaxRoleName ListLength |
max_role_name _list_length |
Maximum Role List Length | Этот параметр управляет количеством ролей, отображаемых в хранилище пользователей продукта. Это полезно, когда у вас большое количество ролей, и вы не хотите отображать их все. Установка этого параметра в 0 отображает все роли. Значение по умолчанию: 100. В некоторых хранилищах пользователей существуют политики, ограничивающие количество записей, которые могут быть возвращены запросом. Установка значения 0 отобразит максимальное количество результатов, возвращаемых хранилищем пользователей. Если вам нужно увеличить это значение, необходимо установить его на уровне хранилища пользователей. Например: в Active Directory есть свойство MaxPageSize со значением по умолчанию 1000. |
| kdcEnabled | kdc_enabled | Enable KDC | Если ваше хранилище пользователей способно выступать в качестве центра распространения ключей Kerberos (KDC) и вы хотите включить эту функцию, установите для этого свойства значение true. Значение по умолчанию: false |
| UserRoles CacheEnabled |
user_roles _cache_enabled |
Enable User Role Cache | Этот параметр указывает, следует ли кэшировать список ролей пользователя. По умолчанию: true. Возможные значения: false: установите значение false, если роли пользователя изменяются внешними средствами, и эти изменения должны мгновенно отражаться в экземпляре Carbon. По умолчанию: true |
| ConnectionPooling Enabled |
connection_pooling _enabled |
Enable LDAP Connection Pooling | Определяет, включено ли объединение соединений LDAP. Возможные значения: True: Включить объединение соединений. Включение повысит производительность. False: Отключить объединение соединений. По умолчанию: false |
| LDAPConnectionTimeout | ldap_connection_timeout | LDAP Connection Timeout | Тайм-аут при установлении первоначального LDAP-соединения. Задается в миллисекундах. По умолчанию: 5000 |
| ReadTimeout | read_timeout | LDAP Read Timeout | Значение этого свойства - это время ожидания чтения в миллисекундах для операций LDAP. Если поставщик LDAP не может получить ответ LDAP в течение этого периода, он прерывает попытку чтения. Целое число должно быть больше нуля. Целое число меньше или равное нулю означает, что время ожидания чтения не указано, что эквивалентно бесконечному ожиданию ответа до его получения. По умолчанию: не настроено |
| MembershipAttributeRange | membership_attribute_range | Membership Attribute Range | Это позволяет определить максимальное количество пользователей роли, возвращаемое хранилищем пользователей LDAP/AD. Это не зависит от максимального размера страницы хранилища пользователей. По умолчанию: не настроено |
| RetryAttempts | retry_attempts | Retry Attempts | Повторите запрос на аутентификацию, если истекло время ожидания. По умолчанию: не настроено |
| java.naming.ldap.attributes.binary | ldap_binary_attributes | LDAP Binary Attributes | Параметр для определения двоичных атрибутов LDAP, разделенных пробелом. По умолчанию: не настроено |
Расширенные настройки¶
Изменение транспорта по умолчанию¶
API состоят из конфигураций Apache Synapse, к которым NEOMSA APIM обращается через транспортный протокол. По умолчанию в API Manager используется транспорт PassThrough, но вы можете настроить другой транспорт по умолчанию в файле deployment.toml.
Информация. NEOMSA APIM не использует конфигурации протокола передачи сервлетов HTTP/S, которые находятся в файле axis2.xml. Вместо этого консоль управления NEOMSA APIM использует протоколы передачи сервлетов уровня Tomcat, которые доступны в файле <APIM-HOME>/repository/conf/tomcat/catalina-server.xml.
HTTP PassThrough Transport
HTTP PassThrough Transport — это реализация неблокирующего HTTP транспорта по умолчанию, основанная на HTTP Core NIO и специально предназначенная для потоковой передачи сообщений.Он похож на старый транспорт для передачи сообщений, но не учитывает тип контента и просто передает все полученные сообщения. Также у него более простая и понятная модель для пересылки сообщений туда и обратно. Два класса, реализующие API получателя и отправителя, — это org.apache.synapse.transport.passthru.PassThroughHttpListener и org.apache.synapse.transport.passthru.PassThroughHttpSender, соответственно. PassThrough Transport не требует binary relay builder и expanding formatter.
Корректное завершение работы транспортного протокола PassThrough
По умолчанию, когда узел NEOMSA APIM начинает корректное завершение работы, он продолжает считаться доступным в течение некоторого времени, прежде чем фактически завершить работу. Это связано с тем, что время ожидания корректного завершения работы транспортного протокола PassThrough определяется значением параметра socket_timeout socket timeout, и узел остается доступным до истечения этого периода. Чтобы сократить это окно, уменьшите значение socket_timeout [transport.http] в <APIM-HOME>/repository/conf/deployment.toml файле до меньшего значения вместо значения по умолчанию 180000 мс. Обратите внимание, что это значение все еще должно быть достаточно высоким, чтобы обеспечить комфортное время ответа любых выполняющихся запросов, чтобы реальный трафик не прерывался преждевременно.
Параметры транспортного приемника
| Имя параметра | Описание | Обязательность | Возможные значения | Значение по умолчанию |
|---|---|---|---|---|
| port | Порт, на котором этот транспортный приемник должен прослушивать входящие сообщения. | Нет | Положительное целое число меньше 65535 | 8280 |
| non-blocking | Установка этого параметра в true имеет решающее значение для надежной передачи сообщений и корректной работы других сценариев. | Да | true или false | true |
| bind-address | Адрес интерфейса, к которому должен быть привязан слушатель транспорта | Нет | Имя хоста или IP-адрес | 127.0.0.1 |
| WSDLEPRPrefix | Префикс URL, который будет добавлен ко всем EPR сервисов и EPR в WSDL и т. д. | Нет | A URL of the form <protocol>://<hostname>:<port>/ | |
| httpGetProcessor | Точка расширения, используемая для выполнения специального перехватчика для HTTP-запросов GET. | Да | Точка расширения | org.wso2.carbon.mediation.transport.handlers .PassThroughNHttpGetProcessor |
| priorityConfigFile | Расположение файла, содержащего конфигурацию для диспетчеризации на основе приоритетов. | Нет | Расположение файла |
Параметры отправителя транспорта
| Имя параметра | Описание | Обязательность | Возможные значения | Значение по умолчанию |
|---|---|---|---|---|
| non-blocking | Установка этого параметра в значение true имеет решающее значение для надежной передачи сообщений и корректной работы ряда других сценариев. | Да | true или false | true |
| warnOnHTTP500 | Регистрирует предупреждения для ответов HTTP 500 только для указанных типов контента. Например, <parameter name="warnOnHTTP500 locked="false">x-application/hessian|none</parameter> будет регистрировать предупреждения для ответов HTTP 500 с типом содержимого «x-application/hessian» или сообщений, в которых отсутствует тип содержимого. |
Нет | Список типов контента, разделенных символом «|». | |
| http.proxyHost | Если исходящие сообщения должны отправляться через HTTP-прокси-сервер, используйте этот параметр для указания целевого прокси-сервера. | Нет | Имя хоста или IP-адрес | |
| http.proxyPort | Порт, через который целевой прокси-сервер принимает HTTP-трафик. | Нет | Положительное целое число меньше 65535 | |
| http.nonProxyHosts | Список хостов, на которые HTTP-трафик должен направляться напрямую, без прохождения через прокси. | Нет | Список имен хостов или IP-адресов, разделенных символом «|» |
Регулирование соединения
Используя транспортный протокол HTTP PassThrough, вы можете включить регулирование соединения, чтобы ограничить количество одновременных открытых соединений. Чтобы включить регулирование соединения, отредактируйте <APIM-HOME>/repository/conf/deployment.toml и добавьте следующую конфигурацию в конфигурации passthough_http.
Это ограничит количество одновременно открытых входящих подключений до 2. Чтобы отключить регулирование, удалите настройку max_open_connections или установите для нее значение -1.
Информация. Регулирование соединения никогда не бывает точным. Например, установка этого свойства на 2 приведет к примерно двум одновременным открытым соединениям в любой момент времени.
Настройка passthru_http параметров подключения
Вы можете настроить параметры соединения для passthru_http отправителя транспортного уровня. Эти параметры управляют поведением соединений в пуле соединений:
transport.sender.connection.idle.time - максимальное время (в миллисекундах), в течение которого соединение может оставаться в пуле в режиме ожидания.
transport.sender.connection.maximum.lifespan - максимальная продолжительность жизни соединения в пуле (в миллисекундах).
transport.sender.connection.grace.time - время (в миллисекундах), в течение которого не следует использовать соединение при его закрытии.
Для применения изменений необходимо добавить следующие конфигурации в файл deployment.toml
HTTP Transport Receiver Parameters
HTTP Transport Sender Parameters
HTTP Transport Receiver Parameters
HTTPS Transport Sender Parameters
Настройка кэширования¶
Когда вызов API попадает в API Gateway, шлюз выполняет проверки безопасности, чтобы убедиться, что токен действителен. Во время этих проверок API Gateway извлекает параметры (такие как токен доступа, имя API и версию API), которые ему передаются. Поскольку весь объём трафика к API проходит через API Gateway, этот процесс верификации должен быть быстрым и эффективным, чтобы избежать избыточности и задержек. NEOMSA APIM использует кэширование для этой цели, где информация о проверке кэшируется с токеном, именем API и версией, а кэш хранится либо на API Gateway, либо на сервере Key Manager.
Размер кэша по умолчанию для любого типа кэша в продукте NEOMSA составляет 10 000 элементов/записей. Удаление из кэша происходит с 10001-го элемента. Все кэши в продуктах NEOMSA можно настроить с помощью файла <APIM-HOME>/repository/conf/deployment.toml. Если вы не задали значение для времени ожидания кеша по умолчанию в конфигурациях сервера, будет применено значение defaultCacheTimeout, равное 15 минутам, которое установлено по умолчанию.
Эти настройки применяются глобально ко всем кэшам. Вы можете переопределить эти значения для конкретных кешей, используя пользовательский интерфейс или различные конфигурационные файлы, как описано в каждом разделе ниже.
Примечание. В распределенной среде настройки кеширования, которые вы делаете на одном узле, одинаково реплицируются на всех узлах.
Кроме кеширования ответов, все остальные кеши включены продуктом. Когда компоненты NEOMSA APIM объединены в кластер, они работают как распределенные кеши. Это означает, что изменения, внесенные одним узлом, видны другому узлу в кластере.
Кэш API Gateway
Когда кеширование включено на шлюзе и запрос достигает шлюза, он сначала заполняет кешированную запись для данного токена. Если кэшированной записи в кэше нет, он вызывает сервер Key Manager. Этот процесс осуществляется с помощью веб-сервисных вызовов. После того, как сервер Key Manager возвращает информацию о валидации, она сохраняется в шлюзе. Поскольку API Gateway отправляет вызов веб-службы только на сервер Key Manager, если у него нет записи в кэше, этот метод сокращает количество вызовов веб-службы на сервер Key Manager. Поэтому он быстрее альтернативного метода.
По умолчанию кэш API Gateway включен. Его можно отключить, изменив следующий атрибут в файле <APIM-HOME>/repository/conf/deployment.toml.
Когда токен отзывается в Key Manager, событие отзыва токена отправляется в Traffic Manager. Шлюзы получают это событие контроллера отзыва токена и очищают кэш соответствующим образом.
Эта функция включена по умолчанию, и события отзыва токенов публикуются классом org.wso2.carbon.apimgt.notification.TokenRevocationNotifierImpl.java.
Если вам нужно изменить поведение по умолчанию, вы можете реализовать интерфейс org.wso2.carbon.apimgt.notification.TokenRevocationNotifier и подключить новую реализацию с помощью следующей конфигурации в файле deployment.toml.
[apim.token.revocation]
notifier_impl="org.wso2.carbon.apimgt.notification.TokenRevocationNotifier"
Кэш ресурсов
Ресурсы API — это HTTP-методы, которые обрабатывают определенные типы запросов, такие как GET, POST и т.д. Они аналогичны методам определенного класса. Каждый ресурс имеет параметры, такие как уровень throttling, тип аутентификации и др.
Пользователи могут отправлять запросы к API, вызывая любой из HTTP-методов API. API Manager использует кэш ресурсов в узле Gateway для хранения параметров уровня API (тип аутентификации и уровень throttling). Запись в кеше идентифицируется с помощью ключа кеша, который основан на контексте API, версии, пути запроса и HTTP-методе. Кеширование позволяет избежать необходимости выполнять отдельный вызов к бэкенду для проверки типа аутентификации и уровня троттлинга ресурса каждый раз, когда поступает запрос к API. Это улучшает производительность.
Обратите внимание, что при обновлении API кэш ресурсов становится недействительным, а изменения вступают в силу в течение нескольких минут.
По умолчанию кэш ресурсов включен. Его можно отключить, изменив следующий атрибут в файле <APIM-HOME>/repository/conf/deployment.toml.
Key Manager состоит из кеша OAuth.
Кэш OAuth
Токен OAuth сохраняется в этом кэше, который включен по умолчанию. Каждый раз, когда создается новый токен OAuth, он сохраняется в этом кеше, чтобы избежать постоянных обращений к базе данных. Если срок действия OAuth не истек или он не был отозван, тот же токен отправляется обратно для того же пользователя. Таким образом, вам не нужно менять этот кешированный токен.
Кэш издателя
Кэш ролей издателя
Это указывает, нужно ли включать кэш ролей в Publisher. Он включен по умолчанию. Если он отключен, для всех вызовов издателя API будет происходить обращение к Key Manager. По умолчанию его срок действия составляет 15 минут. Рекомендуется оставить этот кеш включенным. Однако если система находится в состоянии, когда добавление и удаление ролей происходит бесшовно, кеширование может не работать так, как ожидается. [apim.cache.publisher_roles]
Портал разработчиков имеет несколько кешей для уменьшения времени загрузки страниц и повышения его отзывчивости при одновременном доступе нескольких пользователей.
Кэш тегов
Этот кэш сохраняет теги API после их извлечения из реестра. Если ваши API и связанные с ними теги часто меняются, рекомендуется настроить более короткое время обновления кеша (в миллисекундах). Этот кэш отключен по умолчанию. Чтобы включить его, откомментируйте следующий элемент в файле <APIM-HOME>/repository/conf/deployment.toml.
Этот кэш сохраняет пять последних добавленных API. По умолчанию он отключен. Если у вас есть несколько изменений API за короткий промежуток времени, рекомендуется не включать этот кэш. Чтобы включить его, откомментируйте следующий раздел в файле <APIM-HOME>/repository/conf/deployment.toml и установите enable на true.
Этот параметр определяет, берутся ли области из кэша или нет. По умолчанию отключен. Если вы часто изменяете подписки приложений, изменяете роли пользователей или часто обновляете подписанные API, рекомендуется не включать этот кэш. Чтобы включить его, откомментируйте следующий раздел в файле <APIM-HOME>/repository/conf/deployment.toml и установите enable на true.