Matrix Element и Jitsi с прозрачной авторизацией и аватаром / forpes.ru

Главная
Matrix Element и Jitsi с прозрачной авторизацией и аватаром

Matrix Element и Jitsi с прозрачной авторизацией и аватаром -1

22.11.2024 18:32

Metaip 0 608 Источник

Введение

В одной небольшой организации, плотно сидевшей на продуктах майкрософт, для коммуникаций использовался lync (skype), интегрированный с AD. В один момент руководству надоел аська-стайл мессенджер. К тому же вызывало дикое раздражение обмен картинками в lync - захотел передал, захотел не передал, в групповых чатах картинки вообще непонятно где прятались. Решили перейти на современные.

Итак, задача - мессенджер и ВКС, но чтобы запускался как lync с полным именем и аватаром, без запроса логинов и паролей.

Выбор пал на matrix element и jitsi. Не буду описывать нудные критерии выбора, в сети много обзоров.

Все данные о пользователях хранятся в AD, значит авторизация по kerberos, а данные получаем по ldap. Нас интересует конкретно только три параметра - полное имя, почта, аватар.

Вводные данные:

сервер - linux debian
клиент - matrix element
matrix сервер - synapse с авторизацией oidc
провайдер авторизации - keycloak
ВКС - jitsi
web сервер - apache

Сервер предварительно вводим в домен и генерируем keytab файл. Я сделал это двумя командами:

$ net ads join
$ net ads keytab add http/m.example.local@EXAMLE.LOCAL

Не принципиально как это делать, главное, чтобы у нас в системе был файл /etc/krb5.keytab с server principal = http/m.example.local@EXAMPLE.LOCAL.
В тексте ниже опустим описание установок задействованных приложений, в интернете уйма руководств, не будем засорять пространство.

Установка keycloak

Устанавливаем согласно официальной документации, ничего сложного нет.
Создаем в интерфейсе администрирования новый realm с именем synapse. В новом realm создаем клиента с именем synapse, включаем Client authentication и Authorization в ON, остальное по-умолчанию. Запоминаем, что во вкладке Credentials находится ClientSecret, который нам пригодится позже.

Идем в Identity providers, создаем новый с Alias=synapse, Client ID=synapse. Остальное по умолчанию.

Идем в User federation, добавляем LDAP провайдера, в нем стандартные параметры топопривязки ldap - server, bind dn и т.д. Главное включаем kerberos, здесь как раз пригодился Server principal из введения.

Не забываем, что нужна фотография для аватара пользователя, поэтому переключаемся на вкладку Mappers и добавляем mapper с именем picture. Ldap атрибут wWWHomePage содержит ссылку на jpeg фото пользователя. Остальные значения имени и почты там уже присутствуют.

Установка synapse

Устанавливаем согласно официальной документации, тут тоже все без сложностей. В данной ситуации нас интересует только интеграция с keycloak. Параметр client_secret берем из установки keycloak. В ip_range_whitelist добавляем локальные сети, без этого synapse не будет качать фото из picture_template.

ip_range_whitelist:
  - '172.16.0.0/12'
  - '192.168.0.0/16'

oidc_providers:
  - idp_id: keycloak
    idp_name: "EXAMPLE"
    issuer: "https://m.example.local:8443/realms/synapse"
    client_id: "synapse"
    # секрет берем из установки keycloak
    client_secret: "АБРАКАДАБРА"
    scopes: ["openid", "profile"]
    user_mapping_provider:
      config:
        localpart_template: "{{ user.preferred_username }}"
        display_name_template: "{{ user.given_name }}"
        email_template: "{{ user.email }}"
        # именно picture как в mapper установки keycloak 
        picture_template: "{{ user.picture }}"
    backchannel_logout_enabled: false
    allow_existing_users: true

Установка jitsi

Ну все как обычно - официальная документация, сложностей ноль. В качестве web сервера выбираем apache с доменным именем v.example.local.

После установки отключаем опцию prejoin. Нам не надо запрашивать имя пользователя, ведь мы все делаем автоматически.

На будущее в файле /etc/jitsi/meet/${HOSTNAME}-config.js зададим параметр для gravatar. Просто так.

    prejoinConfig: {
         enabled: false,
    },

    gravatar: {
         baseUrl: 'https://va.example.local/avatar/',
    },

Клиент element

Запускаем с параметром --profile на директорию, содержащую файл config.json:

{
    "default_server_config": {
        "m.homeserver": {
            "base_url": "https://m.example.local",
            "server_name": "m.example.local"
        }
    },
    "disable_custom_urls": true,
    "disable_guests": true,
    "disable_login_language_selector": false,
    "disable_3pid_login": true,
    "force_verification": false,
    "default_country_code": "RU",
    "default_federate": false,
    "default_theme": "dark",
    "permalinkPrefix": "https://m.example.local",
    "room_directory": {
        "servers": ["m.example.local"]
    },
    "jitsi": {
        "preferred_domain": "v.example.local"
    }
}

Запускаем.
Выбираем “Продолжить с EXAMPLE”.

Continue.

Виола!
Клиент запустился, подтянул имя пользователя, почту, аватар и при этом ничего не просил вводить руками, просто два клика. Проверяем виджет с групповой видеоконференцией. Тоже все работает как надо. Имя и аватар на месте.

Можно сдавать проект? А вот и нет. Руководство хочет отдельно пользоваться ВКС без запуска виджета в element.

Настройка jitsi

Вернее до-настройка.
После погружения в тему выяснилось, что jitsi у себя не хранит полное имя, почту и аватар. Даже при настройке авторизации через ldap не подтягивает оттуда ничего. Все эти три параметра динамические и задаются в строке url через якори, а якори не передаются на сторону сервера.
Решаю создать еще один виртуальный хост с авторизацией kerberos - va.example.local. Сначала думал добавить модуль mod_gssapi в apache, он возвращает principal имя и по нему задавать фильтр для выборки из ldap полного имени и фото пользователя и потом перенаправлять на v.example.local с якорями. Но потом вспомнил, что у нас же есть уже настроенный keycloak, значит ставим модуль mod-auth-openidc, который сразу отдает все значения в переменные окружения веб сервера. Пишем временный cgi скрипт для вывода переменных. Вот же они все, начинаются на OIDC_CLAIM_*. Бери и пользуйся.

Запускаем виртуальный хост на apache. Идея такая - пользователь заходит на https://va.example.local, модуль mod-auth-openidc его прозрачно авторизует и сразу работает перенаправление на v.example.local с якорями имени и почты. Аватар jitsi скачает с адреса в параметре gravatar.baseUrl, а он у нас уже задан при установке jitsi.

<VirtualHost *:443>
    ServerName va.example.local

    DocumentRoot /var/www/va


    # ...
    # ... стандартные настройки для SSL, логов и т.д.
    # ...

    OIDCProviderMetadataURL https://m.example.local:8443/realms/synapse/.well-known/openid-configuration
    OIDCRedirectURI https://va.example.local/private
    OIDCCryptoPassphrase some_password
    OIDCClientID synapse
    # здесь указываем секрет из установки keycloak, 
    # он такой же как client_secret в synapse
    OIDCClientSecret АБРАКАДАБРА
    OIDCProviderTokenEndpointAuth client_secret_basic
    OIDCRemoteUserClaim email
    OIDCScope "openid email"
    OIDCPassClaimsAs environment none

    <Location />
        AuthType openid-connect
        Require valid-user
    </Location>

    ScriptAlias "/index.cgi" "/var/www/va/index.cgi"
    RewriteEngine on
    RewriteRule ^/([a-zA-Z0-9]+)$ /index.cgi [PT]
</VirtualHost>

Создаем cgi скрипт /var/www/va/index.cgi. Здесь на bash, но можно написать на чем угодно. Хэш для фейкового gravatar-а считаю MD5, потому что jitsi почему-то по нему обращается, хотя везде в руководствах написано SHA256.

#!/bin/bash

# disable filename globbing
set -f

echo "Content-type: text/html; charset=utf-8"
echo


# должны быть права на запись в директорию /var/www/va
[ -d /var/www/va/avatar/photo ] || mkdir -p /var/www/va/avatar/photo


# качаем jpg файл с фото пользователя
/usr/bin/wget -q -nc --timeout=5 --no-proxy --directory-prefix /var/www/va/avatar/photo/ "$OIDC_CLAIM_picture"


# считаем MD5 сумму почтового адреса 
HASHMD5=`echo -n "$OIDC_CLAIM_email" | /usr/bin/md5sum | /usr/bin/awk '{print $1}'`


# создаем ярлык на фото пользователя
[ -f /var/www/va/avatar/$HASHMD5 ] || \
	ln -s /var/www/va/avatar/photo/`basename "$OIDC_CLAIM_picture"` /var/www/va/avatar/$HASHMD5

# перенаправляем клиента на адрес jitsi с параметрами имени и почты
echo "<html lang=\"en-US\">
    <head>
        <meta charset=\"UTF-8\">
        <script type=\"text/javascript\">
            window.location.href = 'https://v.example.local${REQUEST_URI}#userInfo.displayName=\"${OIDC_CLAIM_given_name}\"&userInfo.email=\"${REMOTE_USER}\"'
        </script>
        <title>Page Redirection</title>
    </head>
    <body>
    </body>
</html>"

Заходим браузером на https://va.example.local и сразу оказываемся на https://v.example.local. Видим стартовую страницу jitsi. Создаем конференцию и у нас имя, почта и аватар на месте. Ни одного ручного ввода ввода пользователь не сделал.

Но ведь у нас домен для ВКС v.example.local, а не va.example.local. Пользователь зайдет напрямую на v.example.local и увидит пустую заглушку. Вот бы сделать так, чтобы при входе на v.example.local веб сервер понимал когда на него зашли напрямую, а когда с va.example.local. Для этого есть переменная HTTP_REFERER. Пробуем.
Открываем стандартный конфиг jitsi виртуального хоста веб сервера, перед единственной директивой RewriteRule добавляем четыре строки:

<VirtualHost>
    # ...
    # ... стандартный конфиг для jitsi
    # ...
    RewriteEngine on

    #- начало вставки ----------
    RewriteCond expr "! %{HTTP_REFERER} -strmatch '*://va.example.local*'"
    RewriteCond expr "! %{HTTP_REFERER} -strmatch '*://m.example.local*'"
    RewriteCond expr "! %{HTTP_USER_AGENT} -strmatch '*Element*'"
    RewriteRule ^/([a-zA-Z0-9]+)$ https://va.example.local/$1 [R]
    #- конец вставки ----------

    RewriteRule ^/([a-zA-Z0-9]+)$ /index.html
</VirtualHost>

Проверяем. Заходим браузером на https://v.example.local. Можно после доменного имени сразу указать subdir, в случае jitsi это означает название конференции. В любом случае идет перенаправление на va.example.local и обратно. Это происходит мгновенно, даже не заметно. В итоге пользователь назван и высокохудожественно изображен. При этом как и хотели никакого ручного ввода не было (ну кроме адреса в адресной строке).

Ну и само собой если используются самоподписанные корневые центры сертификации, их сертификаты надо добавить в доверенные на системе:

системное хранилище java - cacerts
скопировать pem файлы в /etc/ssl/certs, потом c_rehash.