Skip to content

Авторизация

Одним из способов обеспечения безопасности и защиты от злоумышленников является авторизация. Авторизация — это механизм предоставления пользователю определённых разрешений и прав на доступ к чему-либо или выполнение определённых действий.

Во Flussonic Media Server реализован механизм идентификации пользователей и отслеживания подключений с помощью авторизационных бэкендов. Авторизационный бэкенд определяет правила авторизации, чтобы разрешать или отклонять запросы. Роль авторизационного бэкенда может играть внешняя система (например, ваш сайт), скрипт на диске, часть конфигурации Flussonic или IPTV плагин — в любом случае он определяет правила авторизации.

Основная идея авторизации во Flussonic заключается в следующем: ваш сайт опознает клиента, который собирается играть видео, (например, по cookie-файлам) и добавляет к URL-адресу Flussonic в плеере уникальный ключ. Плеер запрашивает у Flussonic видео с этим ключом. Flussonic отправляет запрос авторизационному бэкенду (например, обратно вашему сайту) и уточняет, можно ли этому плееру играть видео с этим ключом. Если авторизационный бэкенд разрешил проигрывание, то клиент получает доступ к видео.

Чтобы наглядно увидеть, как Flussonic Media Server взаимодействует с авторизационным бэкендом, посмотрите видео ниже:

Подробнее о работе Flussonic Media Server с бэкендом читайте в разделе Авторизация через бэкенд.

Во Flussonic по протоколу HLS используются HTTP-механизмы отслеживания сессий, а по протоколам RTMP, RTSP и MPEG-TS — обрабатываются постоянные TCP-сессии. Также отслеживается экспорт архива в формате MPEG-TS и MP4.

Кроме того, Flussonic Media Server имеет встроенный механизм базовой защиты от вставки плеера на других сайтах. Более подробно про такую защиту вы можете прочесть в разделе Domain lock.

Flussonic Media Server также может проверять пароль при публикации потока. Подробнее см. раздел Авторизация при публикации потока.

Авторизация через бэкенд

Авторизационный бэкенд устанавливает правила, по которым запросы одобряются либо отклоняются. Flussonic Media Server поддерживает несколько авторизационных бэкендов.

Flussonic позволяет настроить внешнюю или внутреннюю авторизацию через бэкенд:

  • Внешняя авторизация используется в случае, если вы предпочитаете, чтобы внешняя система утверждала или отклоняла запросы. В этом случае Flussonic не знает кому можно/нельзя давать доступ к потоку. Алгоритм действий следующий:

1) Пользователь запрашивает доступ к потоку у Flussonic. 2) Flussonic обращается к авторизационному бэкенду. 3) Бэкенд проверяет можно ли этому пользователю дать доступ к потоку и возвращает соответствующий ответ. 4) Flussonic разрешает или запрещает пользователю доступ.

  • Внутренняя авторизация используется в случае, если вы предпочитаете, чтобы Flussonic Media Server утверждал или отклонял запросы. Теперь Flussonic знает кому можно/нельзя давать доступ к потоку. Подробнее см. Конфигуратор бэкендов.

Во Flussonic реализованы два типа авторизации с помощью бэкенда:

  • Авторизация сессий проигрывания (on_play)

Позволяет изменить настройки потока в момент обращения Flussonic к авторизационному бэкенду. См. Авторизация сессий проигрывания.

  • Авторизация сессий публикации (on_publish)

Позволяет настроить поток в момент обращения Flussonic к авторизационному бэкенду. См. Авторизация сессий публикации.

Описание процедуры авторизации

Этап 1.

Вы размещаете Flash-плеер или HTML-тег <video> на веб-сайте или Middleware, указывая в пути к видео ключ авторизации (token), созданный веб-сайтом, одним из следующих способов:

  • В виде строки запроса (query string) для HLS, HTTP MPEG-TS и других доступов по HTTP:

http://192.168.2.3:80/stream1/index.m3u8?token=60334b207baa для HLS

  • В виде адреса для RTMP: rtmp application rtmp://192.168.2.3/static stream name: stream1?token=60334b207baa
  • В виде адреса для RTSP: rtsp://192.168.2.3/stream1?token=60334b207baa

Если веб-сайт или Middleware не указывает ключ token в пути к видео, то Flussonic Media Server генерирует его автоматически.

Этап 2.

Получив запрос к потоку с ключом token, сервер Flussonic Media Server проверяет, открыта ли сессия (транслируется ли уже поток с сервера на этот клиент) с помощью идентификатора сессии. Идентификатором сессии (session_id) служит хеш-сумма, создаваемая для имени потока (name), IP-адреса клиента (ip) и токена (token) следующим образом:

hash(name + ip + token)

Если пользователь меняет свой IP-адрес или переключается на другой поток, то создается новая сессия.

Этап 3.

Если открытых сессий еще нет, Flussonic Media Server отправляет запрос в авторизационный бэкенд. Полный список параметров, которые отправляются в запросе, можно найти в схеме Authorization Backend API.

Этап 4.

Бэкенд возвращает ответ, в котором содержится следующее:

  1. Информация о сессии: в течение какого периода времени сессия активна, сколько открытых сессий разрешено для этого пользователя.
  2. Конфигурация проигрываемого потока. Ее можно использовать для перезаписи текущей конфигурации. См. Авторизация сессий проигрывания.
  3. Конфигурация вставки рекламных видео клипов в проигрываемый поток. См. Вставка рекламы.

Полный список параметров, которые возвращаются в ответ, можно найти в схеме Authorization Backend API.

Включение бэкенда

Настройка бэкенда производится путём добавления директивы on_play в конфигурационный файл:

on_play PATH_TO_AUTH;

, где в качестве PATH_TO_AUTH можно указать:

  • сетевой адрес HTTP

Если в качестве бэкенда указан сетевой адрес HTTP, то Flussonic Media Server будет делать HTTP-запросы по этому адресу, передавая параметры сессии бэкенду.

  • путь на диске

Если в качестве бэкенда указан путь на диске, то он интерпретируется как путь к скрипту, который будет выступать в роли бэкенда.

Как можно "сбросить сессию" при неизменном токене?

Каждая сессия характеризуется своим идентификатором (session_id), который зависит от токена. Если токен меняется, то идентификатор сессии меняется соответственно. Но что если нам нужно "сбросить сессию", т.е. закрыть одну сессию и создать другую, оставив тот же токен? Это можно сделать с помощью ключей сессии, которые используются для генерации идентификатора сессии.

Можно использовать сделующие ключи сессии:

Ключ Описание Статус
proto протокол обязательный
name имя потока обязательный
ip IP-адрес обязательный
token токен факультативный

Идентификатор сессии рассчитывается по следующей формуле (хеш-сумма):

hash(name + ip + proto + token)

Таким образом, сессия будет "сброшена", если поменяется любой из ключей (необязательно токен).

Чтобы указать ключи сессии, перейдите в раздел Media > нажмите имя потока > Auth > выберите ключи сессии из выпадающего списка Select session keys.

Session keys

Вы также можете указать параметр session_keys в настройках on_play URL, в конфигурации потока.

На список элементов session_keys накладываются следующие ограничения:

  • ключи ip, name и proto обязательны и указываются явно (порядок не имеет значения);
  • список может содержать дубликаты, которые обрабатываются явно, что повлияет на конечный результат;
  • элементы списка перечисляются через запятую , без пробелов;
  • если значение ключа не найдено, в хеш будет включён ключ со значением undefined.

Пример конфигурации:

stream example_stream {
  input fake://fake;
  on_play http://IP-ADDRESS:PORT/php-auth-script.php session_keys=ip,name,proto,token;
}

В примере выше ip, name, proto и token используются для вычисления ID сессии (session_id).

Сессия открыта

Если бэкенд разрешил открытие сессии, то, по умолчанию, Flussonic Media Server будет перепроверять статус сессии раз в 3 минуты, чтобы определить, что сессия всё ещё активна.

Чтобы изменить это время, отправьте новое значение в HTTP-заголовоке X-AuthDuration (указывается в секундах).

Через 3 минуты (или другой промежуток времени, если он был изменен с помощью X-AuthDuration) запрос к сессии приведёт к повторному обращению к бэкенду.

Если бэкенд недоступен или возвращает статус 500, то Flussonic Media Server сохранит предыдущий статус, полученный от бэкенда, и попробует ещё раз обратиться к нему.

Сессия закрыта

Если бэкенд запретил открытие сессии, то информация о ней кешируется на сервере. В случае, если пользователь пытается ещё раз с тем же токеном получить доступ к потоку, Flussonic Media Server будет отказывать, не делая повторных обращений к бэкенду.

Просмотр видео в веб-интерфейсе

Администратор может просматривать любое видео в веб-интерфейсе Flussonic без авторизации, т. е. обращений к бэкенду авторизации не производится.

Технически это реализовано следующим образом: при просмотре из веб-интерфейса генерируется специальный токен ADM-xxx, который перехватывается Flussonic Media Server.
Такой токен воспринимается как разрешение воспроизводить видео без авторизации.

Можно запретить Администратору просматривать видео, защищенное при помощи механизма бэкенд-авторизации.

Простейший пример скрипта авторизации (PHP)

Будем хранить авторизацию в файле auth.txt, заполненном такими данными:

user1:token1
user2:token2
user3:token3

Следующий скрипт на PHP будет проверять, содержится ли токен в этом файле. Если ответ положительный, то разрешать открытие сессии:

<?php

$get = print_r($_GET, true);
$token = $_GET["token"];
if(!$token || !strlen($token)) {
    header('HTTP/1.0 403 Forbidden');
    error_log("No token provided", 4);
    die();
}

$tokens = array();
$contents = explode("\n", file_get_contents("auth.txt"));
foreach($contents as $line) {
    if(strlen($line) > 3) {
        $parts = explode(":", $line);
        $tokens[$parts[1]] = $parts[0];
    }
}


if($tokens[$token]) {
    header("HTTP/1.0 200 OK");
    header("X-UserId: ".$tokens[$token]."\r\n");
    header("X-Max-Sessions: 1\r\n"); // Turn this on to protect from multiscreen
} else {
    header('HTTP/1.0 403 Forbidden');
}
?>

Сбор статистики с помощью X-UserId

Бэкенд при открытии сессии может отправить Flussonic Media Server HTTP-заголовок X-UserId (к примеру, X-UserId: 100), который после закрытия сессии будет записан во внутреннюю базу данных вместе с данными о сессии.
Вы можете запрашивать данные о сессии по протоколу MySQL с указанием X-UserId для сбора статистики.

Если бэкенд отправляет заголовок X-Unique: true вместе с X-UserId, то происходит отключение всех остальных открытых сессий, которые имеют такой же X-UserId.

Warning

Отключенные сессии на некоторое время остаются в памяти сервера. Клиенты с теми же сочетаниями IP-адреса, имени потока и токена не смогут получить доступ к контенту.

При использовании опции X-Unique следует генерировать различные токены при каждом обращении пользователя к странице.

Логирование запросов к бэкенду

Подробное описание того, как сделать логирование запросов с помощью PHP, находится в отдельной статье.

Таймаут авторизационного бекенда

В случае, если авторизационный бекенд не успевает ответить за 3 секунды, возможны следующие исходы:

Cостояние сессии Исход
Не открыта Не открывается.
Разрешена Остается открытой.
Запрещена Остается запрещенной.

Авторизация сессий проигрывания и публикации

Flussonic позволяет настроить авторизацию сессий проигрывания и публикации потоков per session. Таким образом, у Вас есть возможность передавать изменения в конфигурации конкретного потока во время авторизации без прямого доступа к конфигурации Flussonic. Вы можете вносить изменения в настройки Flussonic Media Server извне. Например, Вы можете определить логику распределения запросов к транскодерам при публикации потоков.

В чём польза такого подхода?

У вас не будет необходимости трогать конфигурационный файл сервера Flussonic каждый раз, когда Вам нужно внести изменения в настройки потоков, что уменьшает ручное управление серверами. Это особенно полезно при наличии большого количества потоков и серверов.

Note

Опция on_publish уже существует во Flussonic, но в контексте live-локаций (см. Расширенная валидация публикации). Flussonic поддерживает совместимость нового on_publish и уже существующего. Таким образом, Вам необязательно менять конфигурацию, чтобы поддержать существующую логику работы Вашего сервиса, если у Вас уже используется on_publish.

Авторизация сессий проигрывания

Перед проигрыванием потока Flussonic должен убедиться, что пользователь обладает правами, необходимыми для просмотра контента. Когда клиент запрашивает поток, Flussonic посылает запрос авторизационному бэкенду, чтобы получить информацию о том, активен ли поток и может ли этот зритель его проиграть.
В случае, если поток активен и у зрителя есть разрешение на его просмотр, Flussonic высылает URL клиенту.

Для каждой сессии проигрывания Flussonic будет делать GET-запрос на указанный в on_play адрес. Чтобы перезапись (override) прошла успешно, необходимо, чтобы бэкенд вернул JSON с нужной конфигурацией.

Caution

В том случае, когда происходит перезапись конфигурации потока, например, для конкретного пользователя, то эти изменения затронут всех зрителей, как уже проигрывающих поток, так и тех, кто только собирается его проигрывать. Конфигурация потока не уникальна для каждого зрителя. Предположим, 1000 зрителей смотрят онлайн трансляцию. Как только 1001-ый зритель проходит процедуру авторизации, авторизационный бэкенд отправляет Flussonic запрос на изменение конфигурации потока, запрещая проигрывание по протоколу HLS. Все клиенты, проигрывающие поток по HLS будут отключены, а их сессии проигрывания прервутся.

Чтобы настроить авторизацию для сессии проигрывания, используйте опцию on_play в рамках шаблона конфигурации template или потока stream:

template on-play-example {
  on_play http://IP-ADDRESS:PORT/PATH_TO_SCRIPT;
}

Давайте рассмотрим пример: изменим (перезапишем) источник потока с помощью авторизационного бэкенда, чтобы минимизировать прямое взаимодействие с конфигурацией сервера и потоков.

Для этого:

Шаг 1. Выберите авторизационный бэкенд.

Ниже указан пример JSON, который должен вернуть ваш веб-сервис для того, чтобы перезаписать источник потока. Для перезаписи вам не нужно использовать полный конфиг, достаточно всего лишь указать ту часть, которую вы хотите изменить, в теле "config":{}. Например:

{"config":{"inputs":[{"url":"fake://fake"}]}}

Flussonic автоматически найдёт разницу и применит необходимые изменения.

Шаг 2. Добавьте путь к авторизационному бэкенду.

Используйте опцию on_play в конфигурации шаблона template или потока stream и укажите путь к авторизационному бэкенду:

stream example_stream {
  input file://vod/bunny.mp4;
  on_play http://IP-ADDRESS:PORT/on_play;
}

Шаг 3. Проиграйте поток.

Выберите протокол и проиграйте поток. Мы будем использовать протокол HLS. Тогда URL будет выглядеть следующим образом:

http://FLUSSONIC-IP/example_stream/index.m3u8

Таким образом, когда начинаем проигрывать поток example-stream, Flussonic переписывает конфигурацию и заменяет источник нашего потока с file://vod/bunny.mp4 на fake://fake.

Авторизация сессий публикации

Flussonic позволяет вам настроить авторизацию для публикаторов с помощью стороннего программного обеспечения, чтобы избежать ненадёжных источников и предоставлять права на публикацию только проверенным публикаторам. Публиковать контент могут только те пользователи, у которых есть на это разрешение. Как только они устанавливают соединение для начала сессии, Flussonic проверяет, есть ли у пользователя разрешение на публикацию.

Это работает следующим образом: пользователь устанавливает соединение с Flussonic Media Server и запрашивает разрешение на публикацию. Перед началом публикации Flussonic отправляет POST-запрос авторизационному бэкенду с некоторыми параметрами, идентифицирующими сессию, чтобы проверить, есть ли у пользователя разрешение на публикацию контента. Flussonic, основываясь на ответе от авторизационного бэкенда (HTTP 200 или HTTP 403), разрешает либо запрещает пользователю публикацию.

Таким образом, авторизация происходит как раз во временном промежутке между клиентским запросом на публикацию и созданием публикации.

Чтобы настроить авторизацию для сессии публикации, используйте опцию on_publish в настройках шаблона конфигурации template или потока stream:

template on-publish-example {
  prefix on-publish-example;
  input publish://;
  on_publish http://IP-ADDRESS:PORT/on_publish.json;
}

Процесс настройки похож на on_play.