Авторизация¶

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

Во 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 и CORS для защиты плеера.

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

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

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

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

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

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

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

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

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

Ограничивает доступ к проигрыванию неавторизованным пользователям. См. Авторизация сессий проигрывания.

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

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

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

Этап 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. Конфигурация вставки рекламных видео клипов в проигрываемый поток. См. Вставка рекламы.

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

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

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

on_play PATH_TO_AUTH;

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

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

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

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

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

Как можно сохранить сессию при изменении IP адреса клиента?¶

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

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

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

hash(name + ip + proto + token)

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

Чтобы указать ключи сессии, перейдите в раздел Media > нажмите имя потока > Auth > выберите ключи сессии из выпадающего списка Select 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.

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

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

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

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

Flussonic позволяет настроить авторизацию сессий проигрывания и публикации потоков для сессии (per session).

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

Перед проигрыванием потока Flussonic должен убедиться, что у пользователя есть права доступа для просмотра контента.

Когда клиент запрашивает поток для проигрывания, Flussonic отправляет запрос авторизационному бэкэнду. Если поток запущен и у клиента есть разрешение на его просмотр, авторизационный бэкэнд возвращает HTTP 200 и Flussonic отправляет клиенту URL потока.

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

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

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

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

Это работает следующим образом: пользователь устанавливает соединение с Flussonic Media Server и запрашивает разрешение на публикацию. Перед началом публикации Flussonic отправляет POST-запрос авторизационному бэкенду. JSON-тело этого объекта содержит поля, описанные в схеме API. По сути это параметры, идентифицирующие сессию и позволяющие проверить, есть ли у пользователя разрешение на публикацию контента. 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;
}