Использование Keycloak для Single sign-on (SSO) в Directum RX

Как мы знаем, в Directum RX вход возможен не только по логину-паролю от самой системы, но также и с использованием других методов аутентификации: по протоколу LDAP, Kerberos, NTLM, OpenID, SamL и другие. И это все внутри самого RX, т.е. он связывается с доменом, получает токен доступа, авторизуется под конкретной учетной записью.

Но бывают случаи, когда у заказчика не один домен, а несколько. А система RX по умолчанию может в момент времени соединяться только с одним доменом. Можно, конечно, поиграться с самими доменами, сделав доверие между ними, и тогда все будет гуд, но порой для безопасной безопасности это не вариант.

Тут мы подходим к теме нашей статьи, а именно – к решению KEYCLOAK. Итак, что это за зверь, и зачем он нужен. 

Keycloak – это решение с открытым исходным кодом по управлению идентификацией и доступом, предназначенное для современных приложений и сервисов. Keycloak предлагает такие функции как

• единый вход (SSO),
• посредничество в идентификации и вход через социальные сети,
• объединение пользователей,
• клиентские адаптеры,
• домены,
• консоль администратора и консоль управления учетной записью.

Впервые о Keycloak я услышал, когда вышло решение HR Pro от Директум. Там описывалась возможность аутентификации в системе посредством оного решения. И как раз один из заказчиков просил реализовать двухдоменную аутентификацию в условиях, когда доверия между доменами нет. Отсюда и возникла идея использовать Keycloak для RX. Развернули тестовый стенд, настроили и показали бизнесу – их все устроило. И заказчик отправился разворачивать стенд на своих мощностях.

Кейс

Расскажу вкратце, как устроено решение, и как оно взаимодействует с RX. Протокол, который был использован – LDAP.

Порты, необходимые для реализации:

• 636 – используется LDAP через SSL/TLS (LDAPS) для безопасной связи.
• 3269 – используется LDAP через SSL/TLS для поиска по глобальному каталогу.
• 135 – (UDP и TCP) – взаимодействие между контроллерами домена (DC, КД) и DC и клиентами;
• 9000, 8080, 8443, 443 – порты Keycloak + java

О том, как установить и настроить Keycloak, есть очень много статей на просторах интернета. В них описаны решения как для host, так и для Docker контенйера. Keycloak также универсален в плане БД. Я настраивал на Postgres, но может быть использован как MariaDB, так и MSSQL.

Часть, которая прописывается в Config.yml сервера (плеча/плечей приложений) RX:

EXTERNAL_AUTHENTICATION_TYPE: 'OpenIdConnect'
AUTHENTICATION_WIN_ACCOUNT_CLAIM_TYPE: 'preferred_username'
OIDC_CLIENT_ID: 'c1'
OIDC_CLIENT_SECRET: '80DY8AuPgg8ypaw50MTR23MvoqTXVtf8'
OIDC_USE_BASIC_AUTH_FOR_CLIENT_SECRET: 'false'
OIDC_CALLBACK_PATH: '/b1'
OIDC_METADATA_ADDRESS: 'https://keycloak.starkovgrp.ru:7443/realms/master/.well-known/openid-configuration'

Схема взаимодействия

А теперь более подробно

Секции в YML:

• EXTERNAL_AUTHENTICATION_TYPE: 'OpenIdConnect' –протокол для связи RX и Keycloak
• AUTHENTICATION_WIN_ACCOUNT_CLAIM_TYPE: 'preferred_username' –тип утверждения, в котором передается имя учетной записи
• OIDC_CLIENT_ID: 'c1' –идентификатор веб-клиента Directum RX. Задается при регистрации в Keycloak, может быть любым
• OIDC_CLIENT_SECRET: '80DY8AuPgg8ypaw50MTR23MvoqTXVtf8' – значение клиентского секрета из Keycloak. Используется для настройки безопасности. Ввеcти значение секрета, которое сгенерировалось на провайдере идентификации
• OIDC_USE_BASIC_AUTH_FOR_CLIENT_SECRET: –метод передачи клиентского секрета. Обычно задается при настройке на стороне провайдера аутентификации. Возможные значения:
  • false – используется механизм базовой аутентификации (Basic), секрет передается в теле HTTP-запроса. Значение по умолчанию;
  • true – секрет передается в заголовке Authorization.
• OIDC_CALLBACK_PATH: '/b1' – часть пути до веб-клиента Directum RX, на который будет перенаправлен пользователь после попытки аутентификации. Вводится значение, которое указывалось в перенаправлении Keycloak;
• OIDC_METADATA_ADDRESS: 'https://keycloak.starkovgrp.ru:7443/realms/master/.well-known/openid-configuration' – адрес точки входа для получения метаданных, поддерживается только https.

Настройка клиента RX на стороне самого Keycloak подробно описана в справке решения HR Pro: https://club.directum.ru/webhelp/directumrx/4.9/web/index.html?lk_admin_keycloak_nastr.htm

Нам осталось только внести в Keycloak параметры LDAP(s), проверить  вход в систему RX и все. Для добавления пути LDAP идем в User Federation, добавляем нового провайдера и настраиваем его. Таких записей может быть сколько угодно. Главное  – чтобы домены видели сервер Keycloak.

В последствии при переходе по ссылке rx.domen.ru вы будете переброшены на страницу входа keycloak и после ввода логина пароля от своей УЗ в домене успешно авторизуетесь в системе.

Заключение

Keycloak очень гибкая вещь с точки зрения аутентификации разных сервисов – не только RX, но и других. Также он позволяет организовать управление пользователями и обеспечить  безопасность в широком смысле. Безопасность – это всегда сложно и больно, а Keycloak берёт эту историю на себя.

Как было когда-то: мы приходили в приложение с логином и паролем, получали постоянный токен и дальше нас по нему авторизовало. Если токен утекал, начинались серьёзные проблемы. А потом в Oauth2 предложили вариант с динамически меняющимися токенами. Это уменьшило площадь атак и сделало систему надёжнее и безопаснее. Теперь мы реже используем пароль, а значит реже подвергаем его риску утечки. А ключи, по которым пользователь авторизуется на сайте, автоматически обновляются каждые несколько минут.