CC BY
93
Выбор оборудования по быстродействию и стоимости
Выбор оборудования по быстродействию. Одной из основных задач выбора вычислительной системы является задача определения компонентов системы для обеспечения максимального быстродействия при решении заранее определенных задач.
При выборе оборудования по быстродействию следует учитывать, что не любые комбинации процессорных модулей могут выпускать фирмы-вендоры. Поэтому существуют ограничения на конкретные модели узлов, такие как количество процессоров, ускорителей, объем и скорость памяти.
При данных ограничениях оптимизируется цеп
левая функция Т = тш(^ (ТЫркCR +Т1,СЬ), где Т^ -
¿=1
время передачи данных после блока Л
Данная функция представляет собой сумму значений времени выполнения всех программных блоков и обменов данными.
Выбор оборудования по стоимости. Другой задачей выбора вычислительной системы является задача определения компонентов системы для обеспечения минимальной стоимости системы при решении заранее определенных задач. Выбор оборудования по стоимости производится аналогично выбору по быстродействию и должен проводиться с учетом похожих краевых условий, кроме того, время выполнения каждой программы не должно превышать заданное. Данная задача усложняется еще и тем, что с высокой точностью аналитически задача решается только для небольших кластеров, детали которых продаются по фиксированной цене. В реальности стоимость оборудования является предметом торгов (в частности, определенных 94-ФЗ) и может меняться. Минимальная стоимость оборудования, как правило, является коммерческой тайной. Поэтому при
решении данной задачи точность может оказаться недостаточной, и данный метод может продуктивно использоваться для предварительной оценки рынка. Хорошее решение можно получить в случае, когда одна из архитектур имеет явное преимущество для данной задачи.
Разновидностью данной задачи является выбор оборудования с максимальной производительностью при фиксированной стоимости.
Описанный метод использовался в МСЦ РАН при выборе архитектуры высокопроизводительных систем. Оптимизировалось быстродействие для набора бенчмарок. Для построения априорной оценки использовалась программа BERT77/RA-TIO. С помощью данного подхода была оптимизирована архитектура таких вычислительных систем, как МВС-10ВМ, МВС-60001М, МВС-100К.
Литература
1. Телегин П.Н., Шабанов Б.М. Связь моделей программирования и архитектуры параллельных вычислительных систем // Программные продукты и системы. 2007. № 2. C. 5-8.
2. Шабанов Б.М., Телегин П.Н., Аладышев О.С. Особенности использования многоядерных процессоров // Программные продукты и системы. 2008. № 1. C. 7-9.
3. Melnikov V., Shabanov B., Telegin P. and Chernyaev A. Automatic Parallelization of Programs for MIMD Computers, in Modern Geometric Computing for Visualization. Tokyo, SpringerVerlag, 1992. С. 253-262.
4. Mattson T.G., Sanders B.A., Massingill B.L. Patterns for Parallel Programming. Addison-Wesley Professional, 2004.
5. Akl S.G. The Design and Analysis of Parallel Algorithms. Prentice Hall, 1989.
References
1. Telegin P.N., Shabanov B.M., Programmnye produkty i sistemy, 2007, no. 2, pp. 5-8.
2. Shabanov B.M., Telegin P.N., Aladyshev O.S., Programmnye produkty i sistemy, 2008, no. 1, pp. 7-9.
3. Melnikov V., Shabanov B., Telegin P. and Chernyaev A., Modern Geometric Comput. for Visualization, Tokyo, SpringerVerlag, 1992, pp. 253-262.
4. Mattson T.G., Sanders B.A., Massingill B.L., Patterns for Parallel Programming. Addison-Wesley Professional, 2004.
5. Akl S.G., The Design and Analysis of Parallel Algorithms, Prentice Hall, 1989.
УДК 004.735 004.771
МЕХАНИЗМ ПРАВ НА ОСНОВЕ ГРУПП ПОЛЬЗОВАТЕЛЕЙ В EDUROAM -ФЕДЕРАТИВНОЙ СИСТЕМЕ УПРАВЛЕНИЯ ДОСТУПОМ К СЕТЕВЫМ РЕСУРСАМ НАУЧНО-ОБРАЗОВАТЕЛЬНЫХ СЕТЕЙ
А.П. Овсянников, зав. отделом; Т.В. Овсянникова, научный сотрудник; С.А. Овчаренко, стажер-исследователь (Межведомственный суперкомпьютерный центр РАН, Ленинский просп., 32а, г. Москва, 119991, Россия, [email protected], [email protected], [email protected])
Описывается реализация федеративного контроля доступа для научных сетей на основе технологии eduroam. Технология предоставляет пользователям возможность безопасной аутентификации для доступа к сети и использования сетевых ресурсов в любой сети федерации eduroam с использованием единственного набора учетных данных.
Рассматриваются основные технологии и протоколы, используемые для обеспечения прозрачной аутентификации пользователей.
Авторами впервые предложен механизм прав доступа на основе групп институтов и пользователей. Информация о группах хранится на групповых RADIUS-серверах в виде списка институтов или списка пользователей.
Для аутентификации пользователя в eduroam сервис-провайдер передает запрос на аутентификацию, содержащий имя и пароль пользователя в зашифрованном виде, RADIUS-серверу идентификации института пользователя. Сервер идентификации определяется по доменному имени пользователя, запрос передается через иерархическую систему прокси-серверов RADIUS. Если сервис-провайдер обеспечивает специальный доступ для пользователей некоторой группы, он также направляет на RADIUS-сервер группы запрос о принадлежности пользователя этой группе. Запрос передается через иерархическую систему групповых серверов RADIUS. Иерархия прокси-серверов RADIUS федерации eduroam и групповых серверов основывается на доменной системе имен.
Реализация описанных механизмов требует незначительной модификации RADIUS-сервера сервис-провайдера для поддержки групп и не требует внесения изменений в RADIUS-серверы провайдеров идентификации и прокси-серверы системы eduroam. Поддержка групп полностью совместима с существующей системой eduroam, в одной системе могут одновременно функционировать серверы RADIUS сервис-провайдера с поддержкой групп и без поддержки.
Ключевые слова: eduroam, аутентификация, авторизация, сети науки и образования, научные телекоммуникации, RADIUS, сетевой доступ, беспроводные сети, wifi, федерация.
USERS GROUP ACCESS RIGHTS IN EDUROAM - FEDERATED USER IDENTITY MANAGEMENT SYSTEM
FOR RESEARCH AND EDUCATIONAL NETWORKS
Ovsyannikov A.P., Head of Department; Ovsyannikova T. V., Research Associate;
Ovcharenko S.A., Probationer-researcher (Joint Supercomputer Center of RAS, 32a, Leninsky Av., Moscow, 119991, Russia, [email protected], [email protected], [email protected])
Abstract. The paper describes a federated identity management infrastructure based on eduroam. This technology enables secure authentication using single netid for network and resources access in eduroam federation. Major protocols and technologies for transparent user authentication are covered.
A way of authorization, based on membership in institutional groups and individual user membership is proposed.
For user authentication a service provider sends an authentication request contained the encrypted user name and password to user's institute RADIUS server (identity provider). Identity provider is determined by the domain user name/ The authentication request is passed through th eduroam hierarchy of proxy RADIUS servers. If the service provider provides special access for a certain group of users, it also sends a request to group identity RADIUS-server. A request passes through a hierarchy of group RADIUS servers for group membership checking. Eduroam federation and group RADIUS servers hierarchies are based on the domain name system.
The implementation of these mechanisms requires a slight modification of service provider RADIUS server for group support and do not require changes of the identity provider and eduroam federations RADIUS servers. Group support is fully compatible with the existing eduroam infrastucture, the both types of RADIUS servers with and without group support can operate simultaneously.
Keywords: eduroam, authorization, authentication, eduroam, national research and educational networks, RADIUS, netid, login service, wireless, wifi, federation.
Тенденция к расширению и углублению сотрудничества между научными центрами в России и за рубежом приводит к необходимости объединения вычислительных и сетевых ресурсов сотрудничающих организаций. Для такого объединения необходима интеграция как на уровне сетевой инфраструктуры, так и на административном уровне: установление доверительных отношений, унификация правил доступа к разделяемым ресурсам и так далее. В числе наиболее важных вопросов объединения сетевых ресурсов - обеспечение контроля доступа и интеграция систем аутентификации и авторизации пользователей. Одним из подходов к решению данной проблемы является построение федеративной инфраструктуры управления идентификацией пользователей. Федеративный доступ позволяет пользователям использовать один набор учетных данных для доступа к ресурсам сетей, установивших доверительные отношения, согласовавших правила доступа к ресурсам и входящих в ассоциацию безопасности, называемую федерацией [1]. В качестве примера федеративного доступа к сетевым ресурсам можно
привести проекты европейской научно-образовательной сети GEANT eduGAIN и eduroam.
Eduroam (Educational Roaming) представляет собой распределенную инфраструктуру доступа к сети для мобильных пользователей. Данная технология позволяет использовать одно имя пользователя и пароль как в организации постоянного пребывания пользователя, так и в любой другой организации-члене федерации eduroam. В настоящее время в федерацию eduroam входят операторы научных и образовательных сетей 54 стран, включая большинство европейских стран, страны Юго-Восточной Азии, Южной Америки, Австралию и отдельные университеты США.
Технология eduroam
Основными компонентами архитектуры eduroam являются следующие:
- сервер доступа к сети (СДС) - коммутатор или беспроводная точка доступа, обеспечивающая доступ клиентов к сети;
- клиент - конечное устройство, обеспечи-
вающее аутентификацию и доступ к сети на стороне пользователя;
- сервер аутентификации (СА) - программно-аппаратный комплекс, осуществляющий аутентификацию и авторизацию клиентов и динамическую конфигурацию СДС; СА хранит информацию об учетных данных пользователей; в 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], например МАС-адрес клиента. Эти атрибуты могут использоваться для мониторинга, сбора статистики и т.д.
МАС layer
Рис. 1. Уровни EAP-аутентификации
Количество пар атрибут-значение ограничено 256, и назначение новых атрибутов требует согласования со стандартизующими организациями. Существует механизм расширения пространства атрибутов путем передачи Vendor-Specific атрибута, однако на настоящий момент нет стандартного метода шифрования Vendor-Specific атрибута, поэтому использование этого механизма нежелательно.
СА RADIUS образуют фундамент авторизационной инфраструктуры eduroam (рис. 2). При этом СА может выступать как RADIUS-сервер федеративного уровня (Federal Level RADIUS Server, FLRS), провайдер сервиса доступа к сети (Service Provider, 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. Например, пользователь из МСЦ РАН может иметь имя [email protected]. Маршрутизация запросов производится на основании realm пользователя. Так, в случае, если пользователь [email protected] отправляет запрос, находясь за пределами Российской Федерации, он будет направлен 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 по числу групп. Сервис-провайдер в запросе RADIUS-серверу группы должен указывать полное имя пользователя, преобразование для выделения домена (realm) из имени пользователя для запроса к FLRS выполняет RADIUS-сервер группы.
Во втором варианте RADIUS-сервер сервис-провайдера производит аутентификацию пользователя с использованием стандартной процедуры eduroam, направляя запрос на FLRS. Параллельно сервис-провайдер направляет запросы имени пользователя на все RADIUS-серверы групп, в которых он участвует. Такой запрос не содержит
RESPONSE = Accept ATTR = группа
f
Ответ: Reject
i
Да
Да
Запрос на
FLRS
Рис. 3. Сценарий аутентификации с использованием RADIUS-сервера группы
TLRS
Рис. 4. Сценарий аутентификации через FLRS и RADIUS-сервер группы
шифрованной части, направляемой FLRS. RADIUS-сервер группы возвращает Accept/Reject в зависимости от присутствия имени или домена пользователя в своей базе (списке членов группы).
Решение о назначении привилегий сервис-провайдер принимает в зависимости от успеха аутентификации пользователя в eduroam и ответов RADI-^-серверов групп. Если группы построены на
учете организаций в целом (то есть не используют персональные учетные записи), сервис-провайдер не обязан включать имя пользователя в запрос, то есть использовать лишь @геа1т (апопутош@ге-а1т). И в первом, и во втором вариантах каждый сервис-провайдер должен знать имена RADIUS-серверов групп, в которых он участвует, их разделяемые ключи или сертификаты для шифрования запросов. Это требование можно исключить, если предусмотреть механизм направления запросов к RADIUS-серверам групп через некоторый прокси-RADIUS-сервер верхнего уровня, обслуживающий группы (GFLRS), в соответствии с общей логикой eduroam. GFLRS должен различать группы, это можно реализовать, используя доменные имена. Определим домен верхнего уровня, в котором в качестве поддоменов будут обозначены группы, причем для этой цели можно использовать любой реальный домен, например eduroam.ru. Примеры доменов групп: ras.eduroam.ru - РАН, lhc.edu-roam.ru - участники экспериментов БАК. RADI-Ш-сервер группы получает стандартное имя в домене группы, например gradius.lhc.eduroam.ru. Домены групп могут содержать поддомены и т.д., образуя иерархическую структуру. Каждый под-домен обслуживается соответствующим RADIUS-сервером (рис. 5).
Для аутентификации пользователя user@realm сервис-провайдер использует стандартную процедуру, направляя запрос на FLRS. Для определения принадлежности к группе сервис-провайдер направляет к GFLRS запрос, содержащий имя пользователя (user@realm), объединенное с доменным именем группы (group.edroam.tld) - user@realm. group.tld. Например, для пользователя [email protected] и группы cms.lhc.eduroam.ru в запросе должно присутствовать имя [email protected]. lhc.eduroam.ru. GFLRS удаляет из имени пользователя в поступившем от сервис-провайдера запросе правую часть, совпадающую с доменом GFLRS,
то есть [email protected] преобразуется в [email protected]. Верхний домен преобразованного таким образом имени пользователя используется для определения группы и ee RADIUS-сервера, на который будет перенаправлен запрос. В примере группой является lhc (lhc.eduroam.ru), запрос будет перенаправлен на ее RADIUS-сервер - gradius.lhc.eduroam.ru. Если запись о такой группе в GFLRS отсутствует (домен или RADIUS-сервер отсутствует в DNS), возвращается ответ Reject. На сервере gradius.lhc.edu-roam.edu из имени пользователя [email protected]. cms.lhc будет удален домен lhc, и маршрутизация запроса будет произведена по домену cms по описанной выше процедуре для GFLRS. В конце концов запрос попадет на RADIUS-сервер группы с локальной базой. После удаления домена группы останется исходный user@realm ([email protected] -в примере), который и используется для проверки принадлежности пользователя или института пользователя группе по локальной базе. Ответ переправляется обратно по цепочке прокси-RADI-US-северов сервис-провайдеру.
Групповой прокси-RADIUS-сервер (кроме GFLRS), помимо передачи запроса RADIUS-сер-веру поддомена, может использовать локальную базу. Тогда сначала проверяется возможность дальнейшей маршрутизации запроса на поддомен, в случае ее невозможности выполняется поиск имени пользователя или его домена в локальной базе, и ответ Accept/Reject возвращается по результатам поиска. Например, на GFLRS направлен запрос с именем [email protected]. edu. RADIUS-сервер gradius.lhc.eduroam.ru получает запрос от GFLRS с именем researcher@itep. ru.lhc, отбрасывает lhc и не находит домена ru в списке своих групп-поддоменов. Тогда выполняется поиск пользователя [email protected] и домена @itep.ru по локальной базе gradius.lhc.edu-roam.ru (предложенный механизм см. на рис. 4).
Рис. 5. Иерархическая структура доменов группы
Принадлежность пользователя группе задается либо по домену института пользователя, либо по личной учетной записи. В университетах или крупных организациях, ведущих разноплановую научную деятельность, существует деление по подразделениям: факультетам, кафедрам, лабораториям. Возникает соблазн обозначить подразделения поддоменами домена института и использовать при задании группы в локальных базах RADIUS-серверов групп. Как правило, доменная часть в имени пользователя (user@realm) является доменом института и не содержит указания на подразделение, поэтому проверку принадлежности пользователя подразделению следует передать RADIUS-серверу его института. Запрос на проверку подразделения не включает данные, необходимые для его аутентификации, поэтому в общем случае этот RADIUS-сервер не совпадает с IdP. На рисунке 6 RADIUS-сервер института, проверяющий подразделение, обозначен как GRS института. Групповой RADIUS-сервер должен в локальной базе проверить не только имя user@realm и домен @realm, но и поддомены realm: @*.realm (например @lab.realm). В последнем случае соответствующему GRS направляется (возможно, через GFLRS) запрос, в котором имя пользователя уточнено найденным поддоменом, например [email protected].
Итак, в статье приведено описание технологии eduroam, стандартов и протоколов, на которых она основана, и предложен способ расширенного определения прав доступа на основе объединений членов федерации. Реализация описанных механизмов требует незначительной модификации RADIUS-сервера сервис-провайдера и полностью совместима с существующей системой аутентификации и авторизации eduroam, не требует внесения изменений в работу IdP и FLRS. Возможно также модифицировать FLRS для выполнения функций GFLRS, а IdP - функций IRS. При этом система сможет функционировать в составе существующей системы eduroam, корректно обрабатывая и запросы на аутентификацию от сервис-провайдера провайдеру идентификации, и запросы на проверку групповой принадлежности. Недостатком данного решения является увеличение времени, требуемого для авторизации пользователя. Для его сокращения необходимы распараллеливание запросов к FLRS и GFLRS на стороне сервис-провайдера, ускорение поиска в локальной базе RADIUS-серверов групп и IdP, высокая производительность FLRS и GFLRS, параллельная обработка запросов, обеспечение малой задержки обмена данными между RADIUS-серверами.
Увеличение времени авторизации пользователей, по мнению авторов, является приемлемой
TLRS
RADIUS Access-Accept/Reject
IdP
j I RADIUS Accept-Access/Reject
Рис. 6. Сценарий аутентификации через FLRS, 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).
References
1. Robinson A., Federated Identity Management in Higher Education, Univ. of Baltimore, 2006.
2. Rigney C., Simpson S., Willens A., Rubens W., RFC2865 — Remote Authentication Dial In User Service (RADIUS), IETF, 2010, Available at: http://tools.ietf.org/html/rfc2865 (accessed 19 September 2012).
3. 802. IX Port-Based Network Access Control, IEEE Comp. Society, 2004, Available at: http://standards.ieee.org/ge-tieee802/download/802.1X-2004.pdf (accessed 19 September 2012).
4. 802.1Q Virtual Bridged Local Area Networks, IEEE Comp. Society, 2005, Available at: http://standards.ieee.org/ge-tieee802/download/802.1Q-2005.pdf (accessed 19 September 2012).
5. Aboba B., Blunk L., Vollbrecht J., Carlson J., RFC3748 -Extensible Authentication Protocol (EAP), IETF, 2004, Available at: http://www.ietf.org/rfc/rfc3748.txt (accessed 19 September 2012).
6. RFC4511 - Lightweight Directory Access Protocol (LDAP), IETF, Available at: http://tools.ietf.org/html/rfc4511 (accessed 19 September 2012).
7. Zorn G., Leifer D., Rubens A., Shriver J., Holdrege M., Goyret I., RFC2868 - RADIUS Attributes for Tunnel Protocol Support, IETF, 2000, Available at: http://tools.ietf.org/html/rfc2868 (accessed 19 September 2012).
УДК 004.45
АЛГОРИТМ ЭФФЕКТИВНОГО РАЗМЕЩЕНИЯ ПРОГРАММ НА РЕСУРСАХ МНОГОПРОЦЕССОРНЫХ ВЫЧИСЛИТЕЛЬНЫХ СИСТЕМ
Е.А. Киселёв, стажер-исследователь; О.С. Аладышев, к.т.н., зав. отделом
(Межведомственный суперкомпьютерный центр РАН, Ленинский просп., 32а, г. Москва, 119991, Россия, [email protected], [email protected])
В статье рассмотрен новый подход к решению задачи эффективного размещения параллельной программы на ресурсах многопроцессорной вычислительной системы, основанный на использовании параллельной реализации алгоритма моделирования отжига. Предложена модель многопроцессорной вычислительной системы, учитывающей неоднородность вычислительных и коммуникационных ресурсов, а также модель параллельной программы, основанная на учете типовых схем передачи данных между ветвями программ. Для повышения качества размещения ветвей параллельной программы на ресурсах многопроцессорной вычислительной системы предложена параллельная реализация алгоритма моделирования отжига. Проведена оценка влияния конкуренции в сети на время выполнения параллельной программы.
Ключевые слова: граф вычислительной системы, информационный граф параллельной программы, алгоритмы эффективного размещения программ, алгоритм моделирования отжига.
AN EFFICIENT APPLICATION MAPPING ALGORITHM FOR MULTIPROCESSOR SYSTEMS
Kiselev E.A, Probationer-researcher; Aladyshev O.S., Ph.D., Head of Department (Joint Supercomputer Center of RAS, 32a, Leninsky Av., Moscow, 119991, Russia, [email protected], [email protected])
Аbstract. This article describes a new application mapping approach for multiprocessor systems based on simulated annealing algorithm. The authors propose a model of multiprocessor system, which takes into account the heterogeneity of computing and communication resources, as well as a model of a parallel program based on the identification of typical communication operations between theprogram threads.The authors propose a parallel implementation of the algorithm simulation annealing to improve the quality of application mapping on the resources of multiprocessor computer system.The authors investigated the effect of competition in the network at the application work time.
Keywords: system graph, application graph, parallel algorithms, application mapping, simulated annealing algorithm.
В современных многопроцессорных вычислительных системах (МВС) время выполнения параллельной программы может существенно зависеть от того, как ее отдельные ветви размещены по вычислительным узлам (ВУ) и процессорам [1].
Значительное влияние на время выполнения параллельной программы оказывает конкуренция между взаимодействующими ветвями за коммуникационный ресурс или память ВУ [2]. В качестве примера можно рассмотреть схемы размещения
