Программные продукты и системы

Тенденция к расширению и углублению сотрудничества между научными центрами в России и за рубежом приводит к необходимости объединения вычислительных и сетевых ресурсов сотрудничающих организаций. Для такого объединения необходима интеграция как на уровне сетевой инфраструктуры, так и на административном уровне: установление доверительных отношений, унификация правил доступа к разделяемым ресурсам и так далее. В числе наиболее важных вопросов объединения сетевых ресурсов – обеспечение контроля доступа и интеграция систем аутентификации и авторизации пользователей. Одним из подходов к решению данной проблемы является построение федеративной инфраструктуры управления идентификацией пользователей. Федеративный доступ позволяет пользователям использовать один набор учетных данных для доступа к ресурсам сетей, установивших доверительные отношения, согласовавших правила доступа к ресурсам и входящих в ассоциацию безопасности, называемую федерацией [1]. В качестве примера федеративного доступа к сетевым ресурсам можно привести проекты европейской научно-образова­тельной сети GEANT eduGAIN и eduroam.

Eduroam (Educational Roaming) представляет собой распределенную инфраструктуру доступа к сети для мобильных пользователей. Данная технология позволяет использовать одно имя пользователя и пароль как в организации постоянного пребывания пользователя, так и в любой другой организации-члене федерации eduroam. В настоящее время в федерацию eduroam входят операторы научных и образовательных сетей 54 стран, включая большинство европейских стран, страны Юго-Восточной Азии, Южной Америки, Австралию и отдельные университеты США.

Технология eduroam

Основными компонентами архитектуры eduro­am являются следующие:

–      сервер доступа к сети (СДС) – коммутатор или беспроводная точка доступа, обеспечивающая доступ клиентов к сети;

–      клиент – конечное устройство, обеспечивающее аутентификацию и доступ к сети на стороне пользователя;

–      сервер аутентификации (СА) – програм- мно-аппаратный комплекс, осуществляющий аутентификацию и авторизацию клиентов и динамическую конфигурацию СДС; СА хранит информацию об учетных данных пользователей; в eduroam в качестве СА используется RADIUS [2];

–      IEEE 802.1X [3] – стандарт контроля доступа на основе порта;

–      IEEE 802.1Q [4] – стандарт, описывающий передачу информации о принадлежности к VLAN.

IEEE 802.1X

Стандарт IEEE 802.1X является протоколом контроля доступа на основе порта пользователя. Устройство, поддерживающее данный стандарт, предоставляет доступ к сети только клиентам, успешно прошедшим аутентификацию и авторизацию. Для аутентификации пользователей используется расширяемый протокол аутентификации (Extensible Authentication Protocol – EAP) [5]. Аутентификационные данные передаются по локальной сети (EAP over LAN – EAPoL) и инкапсулированными в протокол RADIUS (рис. 1). При этом СДС лишь передает сообщения клиента и СА и предоставляет либо запрещает доступ к сети на основе ответа СА. 802.1Х дает возможность использовать различные методы аутентификации на основе EAP, что позволяет каждой сети-члену федерации самостоятельно выбирать наиболее удобные для данной сети методы аутентификации независимо от других членов федерации, в частности, методы с взаимной аутентификацией клиента и сервера аутентификации. Такие методы позволяют пользователю удостовериться в подлинности СА перед передачей СА конфиденциальных данных, таких как имя пользователя и пароль доступа. К ним относятся EAP-TLS, EAP-TTLS, EAP-PEAP. При использовании любого из этих методов клиент может проверить полученный от СА сертификат с помощью предустановленной копии открытого ключа удостоверяющего центра и, возможно, списка отзыва сертификатов.

Важно также отметить, что, хотя в процессе аутентификации клиент и СА обмениваются зашифрованными сообщениями, после аутентификации клиента данные, передаваемые по сети, могут быть незашифрованными. Для шифрования трафика авторизованного клиента необходимо использовать один из методов шифрования: WEP, WPA или WPA2. При этом 802.1Х вкупе с одним из методов аутентификации может использоваться для распространения ключей, которыми будут шифроваться данные клиента.

IEEE 802.1Q

Стандарт IEEE 802.1Q определяет способ построения виртуальных локальных сетей (Virtual LAN, VLAN). В случае, когда коммутатор поддерживает IEEE 802.1Q, можно динамически назначать клиентам различные VLAN. Это особенно актуально в рамках федеративного контроля доступа, так как позволяет автоматически настраивать различные уровни доступа для различных классов пользователей. Например, классу пользователей-сотрудников может предоставляться полный доступ к ресурсам, классу студентов – ограниченный доступ, классу гостевых пользователей может быть запрещен доступ к внутренним ресурсам сети. При использовании RADIUS и IEEE 802.1X можно определять класс доступа пользователя и назначать им соответствующий VLAN. Для этого СА передает СДС пары атрибут–значение, на основании которых СДС назначает порту тот или иной VLAN.

Серверы аутентификации

Серверы аутентификации eduroam используют протокол RADIUS и выполняют аутентификацию, авторизацию клиентов и настройку СДС. При этом клиент использует EAPoL для подключения к СДС, который инкапсулирует полученные от клиента данные EAP в RADIUS и передает СА. В свою очередь СА проводит аутентификацию клиента и одобряет или отклоняет запрос. На основе решения СА СДС позволяет или запрещает доступ к сети. Ответ СА также может содержать данные о разрешенном клиенту уровне доступа. СА может поддерживать различные механизмы аутентификации. В частности, для хранения учетных данных пользователя могут использоваться текстовые файлы, реляционные базы данных, удостоверяющие центры или базы данных, использующие протокол LDAP [6] (Novel, et al.). Это позволяет различным членам федерации выбирать наиболее подходящий им способ хранения учетных данных пользователей.

Помимо передачи аутентификационных данных, протокол RADIUS предусматривает возможность передачи набора атрибутов [7], например МАС-адрес клиента. Эти атрибуты могут использоваться для мониторинга, сбора статистики и т.д. Количество пар атрибут–значение ограничено 256, и назначение новых атрибутов требует согласования со стандартизующими организациями. Существует механизм расширения пространства атрибутов путем передачи Vendor-Specific атрибута, однако на настоящий момент нет стандартного метода шифрования Vendor-Specific атрибута, поэтому использование этого механизма нежелательно.

СА RADIUS образуют фундамент авторизационной инфраструктуры eduroam (рис. 2). При этом СА может выступать как RADIUS-сервер федеративного уровня (Federal Level RADIUS Server, FLRS), провайдер сервиса доступа к сети (Service Provi­der, SP) или сервер идентификации пользователей (Identity Provider, IdP).

RADIUS-сервер федеративного уровня

FLRS является основой инфраструктуры eduroam в своей федерации. Он содержит список СА всех членов этой федерации и выполняет маршрутизацию запросов, при этом запросы к СА, находящимся в одной федерации с FLRS, направляются соответствующим СА, а запросы к СА, находящимся за пределами федерации, направляются на RADIUS-серверы конфедерации.

Благодаря тому, что RADIUS-серверы могут перенаправлять запросы без чтения их содержимого, пользователь может использовать одни и те же настройки аутентификации (имя пользователя, пароль и метод аутентификации) как в своей, так и в любой другой организации, участвующей в eduroam. При этом, если используется один из методов аутентификации, обеспечивающий шифрование (EAP-TLS, EAP-TTLS, EAP-PEAP), ни FLRS, ни любой другой RADIUS-сер­вер в иерархии eduroam не получает доступа к конфиденциальной информации о пароле и в некоторых случаях об имени пользователя.

Провайдер сервиса доступа к сети

SP осуществляет связь и маршрутизацию запросов между СДС и вышестоящими серверами RADIUS. Получая от СДС инкапсулированный в протокол RADIUS запрос на доступ к сети, SP перенаправляет его вышестоящему серверу RADIUS (обычно FLRS) и ожидает ответа. В случае успешной аутентификации пользователя SP позволяет СДС открыть пользователю доступ к сети и определяет, какой VLAN назначить соответствующему порту.

Сервер идентификации пользователей

Задача IdP сводится к хранению учетных данных пользователей и проверке запросов на аутентификацию. Стоит отметить, что роли SP и IdP можно объединить в рамках одной программно-аппаратной реализации в том случае, если организация одновременно предоставляет доступ к своей сети и позволяет своим сотрудникам пользоваться доступом к ней в других организациях-членах конфедерации eduroam.

Имя пользователя в eduroam состоит из двух частей: префикса, являющегося именем пользователя в его домашней организации, формат которого оставлен на усмотрение этой организации, и отделенного символом @ суффикса, называемого realm пользователя и совпадающего с доменным именем организации в терминах системы доменных имен DNS. Например, пользователь из МСЦ РАН может иметь имя user@jscc.ru. Маршрутизация запросов производится на основании realm пользователя. Так, в случае, если пользователь user@jscc.ru отправляет запрос, находясь за пределами Российской Федерации, он будет направлен SP, к которому подключается пользователь, далее FLRS, которому принадлежит данный SP, далее через серверы конфедерации российскому FLRS и, наконец, IdP домашней организации пользователя (в данном примере МСЦ РАН). В случае, если пользователь подключается к SP, принадлежащему к той же федерации, что и IdP пользователя, запрос будет направлен через FLRS соответствующей федерации к IdP пользователя.

Права доступа на основе групп институтов  и серверов

Хотя eduroam предоставляет возможность ограничения уровня доступа на основании классов пользователя, возможности по определению этих классов в нынешней инфраструктуре весьма ограниченны и представлены тремя классами:

–      класс локальных пользователей, принадлежащих к данному члену федерации; к нему относятся пользователи, запросы на авторизацию которых получены не от FLRS;

–      класс пользователей из национальной федерации; в него входят пользователи, чьи запросы не направлялись на RADIUS-серверы конфедерации;

–      класс всех пользователей.

Однако, если институты работают над одним проектом или кооперированы друг с другом в рамках одной организации или ведомства, может понадобиться механизм более точного определения классов пользователей. Таким механизмом может стать расширенное определение прав доступа на основе групп институтов и серверов.

Сервис-провайдер может назначать пользователю различные привилегии в зависимости от принадлежности его той или иной организации, например, подключать к VLAN с различающимся доступом к ресурсам. Это целесообразно, если институты работают над одним проектом или кооперированы друг с другом в рамках одной организации или ведомства. Решение о назначении привилегий пользователю может приниматься на основе его realm или атрибутов, получаемых сервис-провайдером от провайдера идентификации IdP при аутентификации.

Назовем сервис-провайдера, предусматривающего некоторые специальные привилегии для некоторой группы институтов, объединенных организационной принадлежностью или совместным проектом, сервис-провайдером группы. Естественно, один сервис-провайдер может быть сервис-провайдером нескольких групп. Назначение привилегий пользователю, институт которого участвует в двух и более группах, определяется политикой сервис-провайдера. Если участие в разных группах приводит к конфликту привилегий, сервис-провайдер может определить несколько беспроводных сетей с разными SSID, аутентификация в которых производится через eduroam.

Если решение о назначении привилегий пользователю принимается на основе realm пользователя, это приводит к ряду сложностей. Групповой сервис-провайдер должен иметь список realm всех участников группы. Присоединение к группе нового института требует обновления файлов настройки у всех сервис-провайдеров группы. Большое число институтов в группе может сделать настройку RADIUS у сервис-провайдера трудоемкой, и в конечном итоге требуется автоматизация распространения списка участников группы. Проблемой также является необходимость включения в группу realm, если в проекте группы участвует не весь институт/университет, а некоторые его подразделения (лаборатории, кафедры, факультеты) или даже отдельные сотрудники. При этом сервис-провайдер будет вынужден предоставить специальный доступ пользователям, которым он не нужен.

Персональное назначение привилегий может быть реализовано с использованием атрибутов, получаемых от провайдера идентификации IdP. В этом случае в локальной базе, используемой для аутентификации пользователей института, должна храниться информация о принадлежности пользователя к той или иной группе (проекту). Это достаточно сложно: локальная база пользователей может не поддерживать требуемые поля, сотрудник института может участвовать во множестве проектов, поддержание актуальности информации о принадлежности к группам требует согласованной работы администраторов и т.д. Кроме того, количество атрибутов протокола RADIUS ограничено, а механизмы расширения пространства атрибутов не поддерживают шифрование новых атрибутов и их значений, что может привести к утечке или подмене конфиденциальных данных о принадлежности пользователя к группе.

Было бы логично, если бы информация о принадлежности группе того или иного пользователя или института хранилась в единственном месте, гибко управлялась и была бы легкодоступной для сервис-провайдера. Наличие централизованного управления группой позволит обеспечить гибкий интерфейс регистрации институтов и пользователей в проекте.

Предлагается схема хранения информации о группах на основе групповых RADIUS-серверов, хранящих списки входящих в группу институтов (а возможно, и персональных учетных записей). На рисунках 3 и 4 приведены основные сценарии аутентификации с использованием RADIUS-сер­вера группы.

В первом варианте RADIUS-сервер группы (на рисунке обозначен как GRS) выступает в качестве промежуточного прокси, включенного в систему eduroam. RADIUS-сервер сервис-провайдера получает запрос на аутентификацию пользователя от сетевого оборудования и перенаправляет его на известный ему RADIUS-сервер группы. RADIUS-сервер группы проверяет принадлежность имени пользователя (включая домен user@realm) или его домена (@realm) списку группы. Если имя пользователя или домен отсутствует в списке, возвращается Reject. Если присутствует, запрос переправляется на FLRS в соответствии со стандартной процедурой eduroam. Если сервис-про­вайдер проверяет участие пользователя в нескольких группах, RADIUS-сервер SP должен направить запросы на аутентификацию RADIUS-серверам всех групп. Если пользователь участвует в нескольких группах, запросы будут продублированы на FLRS и сервер идентификации IdP по числу групп. Cер­вис-провайдер в запросе RADIUS-серверу группы должен указывать полное имя пользователя, преобразование для выделения домена (realm) из имени пользователя для запроса к FLRS выполняет RADIUS-сервер группы.

Во втором варианте RADIUS-сервер сервис-провайдера производит аутентификацию пользователя с использованием стандартной процедуры eduroam, направляя запрос на FLRS. Параллельно сервис-провайдер направляет запросы имени пользователя на все RADIUS-серверы групп, в которых он участвует. Такой запрос не содержит шифрованной части, направляемой FLRS. RADI­US-сервер группы возвращает Accept/Reject в зависимости от присутствия имени или домена пользователя в своей базе (списке членов группы). Решение о назначении привилегий сервис-провай­дер принимает в зависимости от успеха аутентификации пользователя в eduroam и ответов RADI­US-серверов групп. Если группы построены на учете организаций в целом (то есть не используют персональные учетные записи), сервис-провайдер не обязан включать имя пользователя в запрос, то есть использовать лишь @realm (anonymous@re­alm). И в первом, и во втором вариантах каждый сервис-провайдер должен знать имена RADIUS-серверов групп, в которых он участвует, их разделяемые ключи или сертификаты для шифрования запросов. Это требование можно исключить, если предусмотреть механизм направления запросов к RADIUS-серверам групп через некоторый прокси-RADIUS-сервер верхнего уровня, обслуживающий группы (GFLRS), в соответствии с общей логикой eduroam. GFLRS должен различать группы, это можно реализовать, используя доменные имена. Определим домен верхнего уровня, в котором в качестве поддоменов будут обозначены группы, причем для этой цели можно использовать любой реальный домен, например eduroam.ru. Примеры доменов групп: ras.eduroam.ru – РАН, lhc.edu­roam.ru – участники экспериментов БАК. RADI­US-сервер группы получает стандартное имя в домене группы, например gradius.lhc.eduroam.ru. Домены групп могут содержать поддомены и т.д., образуя иерархическую структуру. Каждый поддомен обслуживается соответствующим RADIUS-сервером (рис. 5).

Для аутентификации пользователя user@realm сервис-провайдер использует стандартную процедуру, направляя запрос на FLRS. Для определения принадлежности к группе сервис-провайдер направляет к GFLRS запрос, содержащий имя пользователя (user@realm), объединенное с доменным именем группы (group.edroam.tld) – user@realm. group.tld. Например, для пользователя direc­tor@jinr.ru и группы cms.lhc.eduroam.ru в запросе должно присутствовать имя director@jinr.ru.cms. lhc.eduroam.ru. GFLRS удаляет из имени пользователя в поступившем от сервис-провайдера запросе правую часть, совпадающую с доменом GFLRS, то есть director@jinr.ru.cms.lhc.eduroam.ru преобразуется в director@jinr.ru.cms.lhc. Верхний домен преобразованного таким образом имени пользователя используется для определения группы и ee RADIUS-сервера, на который будет перенаправлен запрос. В примере группой является lhc (lhc.eduroam.ru), запрос будет перенаправлен на ее RADIUS-сервер – gradius.lhc.eduroam.ru. Если запись о такой группе в GFLRS отсутствует (домен или RADIUS-сервер отсутствует в DNS), воз-вращается ответ Reject. На сервере gradius.lhc.edu­roam.edu из имени пользователя director@jinr.ru. cms.lhc будет удален домен lhc, и маршрутизация запроса будет произведена по домену cms по описанной выше процедуре для GFLRS. В конце концов запрос попадет на RADIUS-сервер группы с локальной базой. После удаления домена группы останется исходный user@realm (director@jinr.ru – в примере), который и используется для проверки принадлежности пользователя или института пользователя группе по локальной базе. Ответ переправляется обратно по цепочке прокси-RADI­US-северов сервис-провайдеру.

Групповой прокси-RADIUS-сервер (кроме GFLRS), помимо передачи запроса RADIUS-сер­веру поддомена, может использовать локальную базу. Тогда сначала проверяется возможность дальнейшей маршрутизации запроса на поддомен, в случае ее невозможности выполняется поиск имени пользователя или его домена в локальной базе, и ответ Accept/Reject возвращается по результатам поиска. Например, на GFLRS направлен запрос с именем researcher@itep.ru.lhc.edu­roam. edu. RADIUS-сервер gradius.lhc.eduroam.ru получает запрос от GFLRS с именем researcher@itep. ru.lhc, отбрасывает lhc и не находит домена ru в списке своих групп-поддоменов. Тогда выполняется поиск пользователя researcher@itep.ru и домена @itep.ru по локальной базе gradius.lhc.edu­roam.ru (предложенный механизм см. на рис. 4).

Принадлежность пользователя группе задается либо по домену института пользователя, либо по личной учетной записи. В университетах или крупных организациях, ведущих разноплановую научную деятельность, существует деление по подразделениям: факультетам, кафедрам, лабораториям. Возникает соблазн обозначить подразделения поддоменами домена института и использовать при задании группы в локальных базах RADIUS-серверов групп. Как правило, доменная часть в имени пользователя (user@realm) является доменом института и не содержит указания на подразделение, поэтому проверку принадлежности пользователя подразделению следует передать RADIUS-серверу его института. Запрос на проверку подразделения не включает данные, необходимые для его аутентификации, поэтому в общем случае этот RADIUS-сервер не совпадает с IdP. На рисунке 6 RADIUS-сервер института, проверяющий подразделение, обозначен как GRS института. Групповой RADIUS-сервер должен в локальной базе проверить не только имя user@realm и домен @realm, но и поддомены realm: @*.realm (например @lab.realm). В последнем случае соответствующему GRS направляется (возможно, через GFLRS) запрос, в котором имя пользователя уточнено найденным поддоменом, например user@lab.realm.

Итак, в статье приведено описание технологии eduroam, стандартов и протоколов, на которых она основана, и предложен способ расширенного определения прав доступа на основе объединений членов федерации. Реализация описанных механизмов требует незначительной модификации RADIUS-сервера сервис-провайдера и полностью совместима с существующей системой аутентификации и авторизации eduroam, не требует внесения изменений в работу IdP и FLRS. Возможно также модифицировать FLRS для выполнения функций GFLRS, а IdP – функций IRS. При этом система сможет функционировать в составе существующей системы eduroam, корректно обрабатывая и запросы на аутентификацию от сервис-провайдера провайдеру идентификации, и запросы на проверку групповой принадлежности. Недостатком данного решения является увеличение времени, требуемого для авторизации пользователя. Для его сокращения необходимы распараллеливание запросов к FLRS и GFLRS на стороне сервис-провайдера, ускорение поиска в локальной базе RADIUS-серверов групп и IdP, высокая производительность FLRS и GFLRS, параллельная обработка запросов, обеспечение малой задержки обмена данными между RADIUS-серверами.

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

Литература

1.     Robinson A. Federated Identity Management in Higher Education, University of Baltimore, 2006.

2.     Rigney C., Simpson S., Willens A., Rubens W. RFC2865 – Remote Authentication Dial In User Service (RADIUS), IETF, 2010. URL: http://tools.ietf.org/html/rfc2865 (дата обращения: 19.09.2012).

3.     802.1X Port-Based Network Access Control, IEEE Computer Society. 2004. URL: http://standards.ieee.org/getieee802/ download/802.1X-2004.pdf (дата обращения: 19.09.2012).

4.     802.1Q Virtual Bridged Local Area Networks, IEEE Computer Society, 2005. URL: http://standards.ieee.org/getieee802/ download/802.1Q-2005.pdf (дата обращения: 19.09.2012).

5.     Aboba B., Blunk L., Vollbrecht J., Carlson J. RFC3748 – Extensible Authentication Protocol (EAP), IETF, 2004. URL: http://www.ietf.org/rfc/rfc3748.txt (дата обращения: 19.09.2012).

6.     RFC4511 – Lightweight Directory Access Protocol (LDAP): The Protocol, IETF. URL: http://tools.ietf.org/html/ rfc4511 (дата обращения: 19.09.2012).

7.     Zorn G., Leifer D., Rubens A., Shriver J., M. Holdrege M., Goyret I. RFC2868 – RADIUS Attributes for Tunnel Protocol Support, IETF, 2000. URL: http://tools.ietf.org/html/rfc2868 (дата обращения: 19.09.2012).