Настройка авторизации проигрывания¶

Без авторизации проигрывания инсталяция Catena SE доступна всем желающим в интернете и довольно быстро превратится в бесплатный источник для чужих сервисов.

Чтобы смотреть могли только ваши абоненты, необходимо настроить авторизацию и связать её с вашей middleware.

В Catena SE базовый подход такой:

клиент получает URL проигрывания, в котором есть токен;
Catena SE проверяет этот токен локально (securelink) или через ваш backend (middleware).

Правила проверки токена описываются в авторизационных бекендах.

Авторизационный бекенд - это набор правил, позволяющих:

сразу разрешить клиенту просмотр на основании его IP адреса или известного токена
сразу запретить просмотр на основании геолокации или других признаков
проверить токен по определенным правилам локальной
отправить токен на проверку в стороннюю систему, например middleware

Токены¶

Токен — это строка, которая добавляется к URL проигрывания (в query string) и позволяет:

отличить “своего” клиента от “чужого”;
ограничить время жизни ссылки (TTL);
(опционально) привязать просмотр к IP/устройству/сессии;
(опционально) собирать статистику и ограничивать мультискрин.

Практическое правило: токен должен быть короткоживущим и генерироваться вашей системой выдачи ссылок (портал/middleware).

Securelink без backend middleware¶

Если вы не хотите (или пока не можете) делать отдельный backend для проверки прав, можно использовать “securelink” — проверку токена по общей формуле с секретным ключом.

Схема работы:

ваш портал генерирует токен по формуле и хеширует его секретным ключом;
клиент открывает поток с этим токеном;
Catena SE пересчитывает ожидаемый токен тем же способом и сравнивает;
если совпало — доступ разрешён, если нет — запрещён.

Обычно в токен включают:

имя канала (или другой идентификатор контента),
время начала/окончания действия токена (TTL),
(опционально) IP клиента,
(опционально) user_id (для ограничения количества одновременных сессий).

Плюсы securelink:

не нужен отдельный сервис проверки на каждый просмотр;
высокая производительность и простая эксплуатация.

Минусы securelink:

сложнее сделать тонкие политики (пакеты каналов, гео, устройства, аудит) без усложнения токена;
при компрометации ключа придётся оперативно его менять.

Для включения securelink, надо включить возможность этой проверки в настройках авторизационного бекенда.

Как работает backend middleware¶

В “классической” схеме Catena SE проверяет доступ через backend (middleware) с помощью механизма on_play.

Схема работы:

клиент запрашивает URL у middleware;
middleware возвращает URL с уникальным токеном;
при открытии новой сессии Catena SE обращается к backend и спрашивает, можно ли проигрывать;
middleware отвечает “разрешить/запретить” и (опционально) возвращает дополнительные параметры сессии.

Важно: Catena SE не ходит в middleware на каждый сегмент. Проверка делается при открытии сессии и затем периодически перепроверяется (это снижает нагрузку на backend).

Этот вариант лучше всего подходит, когда вам нужно:

включать/отключать доступ по подписке в реальном времени;
ограничивать мультискрин и/или собирать статистику;
применять сложные правила (гео, устройства, пакеты, родительский контроль и т.п.).

Session keys: что это и зачем¶

Catena SE ведёт понятие “сессии” проигрывания. Сессия идентифицируется на основе набора ключей (например: протокол, имя канала, IP, токен).

По умолчанию (идеологически) это выглядит так:

session_id = hash(name + ip + proto + token)

Если меняется любой из ключей, с точки зрения сервера это новая сессия, и он может:

заново проверить доступ у backend,
заново применить лимиты (например, “сколько одновременных просмотров разрешено”),
пересоздать состояние (что иногда видно пользователю как “переподключение”).

Зачем управлять session keys:

мобильные сети: у клиента может меняться IP при переходе между сотами;
NAT/прокси: реальный IP может быть нестабильным или общим для группы пользователей;
устойчивость сессий: иногда важнее “не рвать просмотр” при смене IP, чем жёстко привязывать токен к IP.

Компромисс здесь простой:

чем меньше параметров участвует в идентификаторе сессии, тем стабильнее просмотр при сетевых изменениях;
чем больше параметров (например, IP), тем сильнее защита от передачи ссылки “другому человеку”.

Если вы используете middleware backend, настройку session keys имеет смысл фиксировать в вашей архитектуре авторизации как отдельное решение “безопасность vs UX”.

Для настройки ключей сессии надо редактировать их список в авторизационном бекенде.

Multiauth¶

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

Для этого достаточно в конфигураторе авторизационного бекенда указать несколько серверов.