Архитектура единой службы аутентификации, авторизации и

УДК 004.42
Архитектура единой службы аутентификации, авторизации и учета
пользователей информационных ресурсов университета
Рыбальченко М.А., студент
Россия, 105005, г. Москва, МГТУ им. Н.Э. Баумана
Научный руководитель: Остриков C.П.,
начальник Управление информатизации - ВЦ
Россия, 105005, г. Москва, МГТУ им. Н.Э. Баумана
ostrikov@bmstu.ru
ВВЕДЕНИЕ
Рост количества информационных систем, используемых в деятельности МГТУ им.
Н.Э. Баумана, делает актуальным вопрос внедрения единой службы аутентификации,
авторизации и учета пользователей информационных ресурсов Университета.
Проблемы связанные с наличием обособленных механизмов аутентификации на
уровне отдельных приложений были подробно описаны в статье “Разработка единой
системы управления пользователями в корпоративных приложениях Университета”
(Рыбальченко М.А., Остриков С.П., электронный журнал «Молодежный научнотехнический вестник» # 04, апрель 2013). В статье, также, была предложена реализация
системы единого каталога пользователей Университета синхронизированного с кадровой
информационной системой. (Кадровый справочник МГТУ им. Баумана в виде LDAPструктуры).
В
данной
статье
обсуждается
вариант
архитектуры
единой
службы
аутентификации, авторизации и учета пользователей информационных ресурсов,
интегрированной со службой единого каталога пользователей Университета.
По мнению авторов, внедрение данной службы позволит:
·
Обеспечить единый механизм доступа пользователей к информационным
ресурсам как из внутренней сети Университета, так и внешней;
·
создавать
Позволит разработчикам новых информационных систем Университета не
свою,
а
использовать
пользователями;
http://sntbul.bmstu.ru/doc/681183.html
централизованную
службу
управления
·
Существенно облегчит интеграцию информационных систем.
МОДЕЛЬ ПРОЦЕССА ПРЕДОСТАВЛЕНИЯ ДОСТУПА И КОНТРОЛЯ
ЗА НИМ
Для описания процессов предоставления доступа к информационным ресурсам и
контроля за ним традиционно используется модель ААА (Authentication, Authorization,
Accounting) [2] (Рисунок 1):
Рис. 1. Архитектура ААА модели
Рассмотрим каждый из процессов ААА модели:
Аутентификация (Authentication) – процесс сопоставления личности пользователя
с его учетной записью[2].
Авторизация (Authorization) – процесс назначения прав пользователю, после
проведенной им аутентификации и идентификации[2].
Учет (Accounting) – процесс сбора информации, связанной с получением
пользователем доступа к запрашиваемому ресурсу[2].
Стоит отметить, что одним из протоколов, часто используемых в комбинации с
ААА протоколами, является протокол LDAP (Lightweight Directory Access Protocol) [2].
Наличие
в
Университете
Единой
системы
управления
пользователями
использующий LDAP (Active Directory), с актуальной информацией о сотрудниках вуза и
Молодежный научно-технический вестник ФС77-51038
студентах, позволяет решить задачу хранения актуальных учетных записей пользователей.
[1].
Укрупненный алгоритм проведения аутентификации в модели ААА (Рисунок 1):
·
Пользователь посылает запрос на аутентификацию в приложении (пароль,
ключ и т.д);
·
Приложение, являясь клиентом службы ААА, перенаправляет запрос на
аутентификацию службе AAA;
·
Служба AAA производит аутентификацию пользователя, используя в
качестве
источника
информации
о
пользователях
единый
каталог
пользователей Университета. Служба AAA посылает ответ приложению;
·
Пользователь получает доступ к приложению (иначе пользователю отказано
в доступе).
Внедрение системы, основанной на модели ААА, обеспечивает эффективную
реализацию многих бизнес-задач и позволяет в значительной степени оптимизировать
управление ИТ-инфраструктурой вуза.
КОНЦЕПЦИЯ ЕДИНОГО ВХОДА В СЕТЬ (SINGLE SIGN ON)
Современные средства идентификации/аутентификации должны поддерживать
концепцию единого входа в сеть. Единый вход в сеть - это, в первую очередь, требование
удобства для пользователей. Так как в вузе используются информационные системы,
допускающие независимое обращение, то многократная идентификация/аутентификация
становится слишком обременительной. К сожалению, пока нельзя сказать, что единый
вход в сеть стал нормой, доминирующие решения пока не сформировались[4].
В
технологии
аутентификации,
единого
используемые
входа
другими
применяются
централизованные
приложениями
и
системами,
серверы
которые
обеспечивают ввод пользователем своих учётных данных только один раз.
К основным преимуществам технологии единого входа относятся:
·
Уменьшение парольного хаоса между различными комбинациями имени
пользователя и пароля;
·
Уменьшение времени на повторный ввод пароля для одной и той же учетной
записи;
·
Поддержка традиционных механизмов аутентификации, таких как имя
пользователя и пароль;
http://sntbul.bmstu.ru/doc/681183.html
·
Снижение расходов на IT-службу за счёт уменьшения количества запросов
по восстановлению забытых паролей;
·
Обеспечение безопасности на каждом уровне входа/выхода/доступа к
системе без причинения неудобств пользователям.
Некоторыми экспертами в качестве главного недостатка технологии единого входа
отмечается увеличивающаяся важность единственного пароля, при получении которого
злоумышленник обретает доступ ко всем ресурсам пользователя, использующего единый
вход. Поставщики менеджеров паролей также отмечают использование различных
паролей к разным информационным ресурсам как более надёжное решение по сравнению
с технологией единого входа[4].
Таким
образом,
необходимо
искать
компромисс
между
надежностью,
доступностью по цене и удобством использования и администрирования средств
идентификации и аутентификации.
ПРОТОКОЛЫ АУТЕНТИФИКАЦИИ ПОЛЬЗОВАТЕЛЕЙ
RADIUS и DIAMETER
Для выполнения функций ААА используется несколько наиболее популярных
сетевых протоколов: RADIUS и DIAMETER.
RADIUS (Remote Authentication in Dial-In User Service) – протокол для реализации
аутентификации,
разработанный
авторизации
для
и
передачи
сбора
сведений
сведений
между
об
использованных
центральной
ресурсах,
платформой
и
оборудованием[5]. Этот протокол применялся для системы тарификации использованных
ресурсов конкретным пользователем/абонентом. Центральная платформа и оборудование
Dial-Up доступа (NAS с системой автоматизированного учёта услуг), RADIUS
используется как протокол AAA[6].
DIAMETER – сеансовый протокол, созданный, для преодоления некоторых
ограничений протокола RADIUS. Обеспечивает взаимодействие между клиентами в целях
аутентификации, авторизации и учёта различных сервисов. Является основным
протоколом архитектуры IMS.
В основе протокола DIAMETER лежит концепция в создании базового протокола
с возможностью его расширения для предоставления сервисов AAA при появлении новых
технологий доступа.
Молодежный научно-технический вестник ФС77-51038
Ниже представлена таблица сравнения протоколов RADIUS и DIAMETER[7]:
Таблица 1
Сравнение протоколов RADIUS и DIAMETER
DIAMETER
RADIUS
Транспортный протокол
Ориентированные на
соединение протоколы (TCP и
SCTP)
Протокол без установления
соединения (UDP)
Защита
Hop-to-Hop, End-to-End
Hop-to-Hop
Поддерживаемые агенты
Relay, Proxy, Redirect,
Translation
Полная поддержка,
означающая, что поведение
агента может быть
реализовано на RADIUSсервере
Возможности по
согласованию
Согласовывает
поддерживаемые приложения
и уровень безопасности
Не поддерживается
Обнаружение узлов
Статическая конфигурация и
динамическое обнаружение
Статическая конфигурация
Сообщение инициации
сервера
Поддерживается. Например,
сообщение повторной
аутентификации, завершения
сессии
Не поддерживается
Максимальный размер
данных атрибутов
16,777,215 октетов
255 октетов
Поддержка сторонних
производителей
Поддерживает сторонние
атрибуты и сообщения
Поддерживает только
сторонние атрибуты
Central Authentication Service (CAS)
В ряде ведущих зарубежных Университетов среди которых: Йе́льский университе́т
(Yale University), Калифорнийский университет в Беркли (The University of California,
Berkeley),
Университет
штата
Юта
(Utah
State
University) для
аутентификации
пользователей в корпоративных приложениях используется служба CAS (Central
Authentication Service).
Центральная служба аутентификации (CAS) является единой точкой входа для вебприложений. Её целью является предоставить пользователю возможность доступа к
нескольким
приложениям,
обеспечивая
http://sntbul.bmstu.ru/doc/681183.html
при
этом
их
полномочия
(например,
идентификатор пользователя и пароль) только один раз. Она также позволяет вебприложениям производить аутентификацию пользователей без обращения к учетным
данным пользователя, таким как пароль[8].
Схема выполнения аутентификации с использованием CAS сервера представлена
на Рисунке 2[9]:
Рис. 2. Архитектура выполнения аутентификации с использованием CAS сервера
Следует
отметить
использование
ticket
(временный
идентификатор)
для
повторной аутентификации пользователей (модель SSO), который хранится в cookies
браузера пользователя.
Более подробнее про архитектуру выполнения аутентификации с использование
CAS можно прочитать здесь: http://www.jasig.org/cas/cas2-architecture.
ОРГАНИЗАЦИЯ УДАЛЕННОГО ДОСТУПА ПОЛЬЗОВАТЕЛЕЙ К
ИНФОРМАЦИОННЫМ РЕСУРСАМ УНИВЕРСИТЕТА
Отдельной задачей, является организация защищенного удаленного доступа
пользователей к корпоративным приложениям Университета.
Рассмотрим возможные варианты решения данной задачи. Одним из таких
вариантов является использование дополнительных возможностей коммуникационного
оборудования, зачастую уже имеющегося в Университете. Речь идет о технологии
SSLVPN. Технология Cisco SSLVPN была разработана для организации удаленного
доступа к сетям. Для организации безопасного соединения, SSLVPN использует Secure
Молодежный научно-технический вестник ФС77-51038
Socket Layer Protocol и Transport Layer Security (SSL/TLS1). Для организации SSLVPN
можно использовать возможности операционной системы Cisco IOS (SSL VPN дополнительный модуль), Cisco VPN 3000 Concentrator или специализированное
устройство Cisco ASA серии 5500.
VPN (Virtual Private Network – виртуальная частная сеть) – логическая сеть,
создаваемая поверх другой сети. За счёт шифрования создаются закрытые каналы.
Технология совместима с любым обозревателем, поддерживающим SSL. VPN является
незаменимым решением в плане эффективности мобильного доступа, безопасности и
экономической целесообразности.
Использование технологии SSLVPN обеспечивает 3 вида доступа (Рисунок 3):
Рис. 3. Модели удаленного доступа SSLVPN
Модели удаленного доступа:
•
Clientless SSL VPN (WebVPN). Доступ к преднастроенным URL-ссылкам через
портал к внутренним интранет-веб-сайтам компании. Common Internet File system
(CIFS). Позволяет удаленным пользователям обозревать и получать доступ к
файлам, расположенным на Windows-based-серверах в корпоративной сети[11].
•
Thin Client SSL VPN (Port Forwarding). Позволяет удаленным пользователям
запускать клиентские приложения на их ПК через шифрованное соединение в
корпоративной сети[12].
•
SSL VPN Client (SVC-Full Tunnel Mode). Посредством установки клиента
WebVPN удаленный компьютер становится частью корпоративной сети. Cisco
Secure Desktop. Дополнительно к SSL VPN (Full Tunnel) устанавливается клиент
защищенного рабочего стола Secure Desktop[12].
http://sntbul.bmstu.ru/doc/681183.html
В Таблице 2 представлена сравнительная характеристика режимов работы
WebVPN[13]:
Таблица 2
Сравнительная характеристика режимов работы SSLVPN
Clientless Mode
Thin-Client Mode
Tunnel Mode
Поддержка веб-приложений. Использование Java-апплета. Работает подобно IPsec VPN.
Файловые ресурсы по CIFS
TCP port mapping: Telnet, e- Загружается через Java или
mail,
приложения
на ActiveX.
статических портах
Поддерживаются
все
IP
приложения. Для установки
клиента
требуются
административные
права,
перезагрузка компьютера не
требуется.
Защищенный рабочий стол
В случае, если информационные системы Университета реализованы как вебприложения, то удаленный доступ к ним удобно реализовать через WebVPN.
WebVPN как средство удаленного доступа к веб-приложениям
Технология WebVPN организует эффективное VPN-взаимодействие, позволяющее
мобильным сотрудникам получить доступ к корпоративным ресурсам[10]. Основное
преимущество данной технологии в отсутствии необходимости удаленному пользователю
устанавливать специальное программное обеспечение (клиент). Для удаленного доступа к
информационным ресурсам университета (веб-приложениям) используется интернет
браузер. Процедура регистрации в корпоративной сети Университета выглядит
следующим образом.
Пользователь в интернет браузере вводит адрес единой точки удаленного доступа к
корпоративным приложениям Университета. В появившемся приглашении (Рисунок 4)
вводит свои учетные данные и получает доступ к опубликованным веб-приложениям
приложениям.
Молодежный научно-технический вестник ФС77-51038
Рис. 4. Регистрация удаленных пользователей в службе WebVPN
Для аутентификации, авторизации и учета пользователей служба WebVPN
обращается к единой службе ААА Университета.
Опубликованные информационные ресурсы представлены в виде списка ссылок
(Рисунок 5). Взаимодействие пользователя с информационными ресурсами происходит в
режиме защищенного соединения по протоколу HTTPS.
Рис. 5. Опубликованные информационные ресурсы представлены в виде списка ссылок
Таким
образом
модель
взаимодействия
удаленных
пользователей
с
информационными ресурсами Университета может быть представлена в следующем виде
(Рисунок 6)
http://sntbul.bmstu.ru/doc/681183.html
Рис. 6. Схема подключения удаленных пользователей к информационным ресурсам
Университета
Процесс подключение к корпоративной сети через WebVPN нельзя сравнивать с
процессом IPSec [10], так как в этом случае не происходит обмена ключами, а
подключение ведется с использованием сертификата.
SSL VPN Client как средство удаленного доступа к информационной сети
Университета
В отличии от WebVPN, реализация SSL VPN предусматривает установку
специального программного обеспечения на клиенте (Cisco systems VPN Client).
Установленное и настроенное программное обеспечение позволит удаленно подключаться
к информационной сети Университета и использовать информационные ресурсы.
Рабочее окно программы Cisco VPN Client с настроенным подключением выглядит
следующем образом:
Молодежный научно-технический вестник ФС77-51038
Рис. 7. Рабочее окно программы Cisco systems VPN Client
Взаимодействие пользователя с информационными ресурсами происходит в
режиме защищенного соединения по протоколу SSL.
Для аутентификации, авторизации и учета пользователей служба SSL VPN
обращается к единой службе ААА Университета
АРХИТЕКТУРА ЕДИНОЙ СЛУЖБЫ АУТЕНТИФИКАЦИИ,
АВТОРИЗАЦИИ И УЧЕТА ПОЛЬЗОВАТЕЛЕЙ ИНФОРМАЦИОННЫХ
РЕСУРСОВ УНИВЕРСИТЕТА
Таким образом единая служба аутентификации, авторизации и учета пользователей
информационных ресурсов Университета представляется авторам как обоснованный и
достаточный набор инструментов обеспечивающий высокий уровень сервиса как для
разных категорий пользователей (локальных и удаленных), так и для различных категорий
информационных систем Университета.
Наиболее сложной задачей является задача определения перечня механизмов
аутентификации, достаточного для проведения аутентификации во всех информационных
ресурсах Университета. Базовый перечень, на взгляд авторов, должен включить
следующие протоколы: CAS, LDAP, NT Domain и RADUIS [3].
Также необходимо предусмотреть способы безопасного удаленного подключения
пользователей к корпоративным приложениям вуза из внешних сетей с различных
устройств. Для решения этой задачи возможно использование VPN.
http://sntbul.bmstu.ru/doc/681183.html
Архитектура единой службы аутентификации, авторизации и учета пользователей
информационных ресурсов Университета представлена на рисунке (Рисунок 8):
Молодежный научно-технический вестник ФС77-51038
Внутренняя сеть Университета
Внутренние
пользователи
Cisco
WebVPN
SSL VPN
Е
д
и
н
а
я
с
л
у
ж
б
а
а
у
т
е
н
т
и
ф
Информационные ресурсы
Ресурс 1
CAS
RADIUS
LDAP
NT
Domain
Каталог
пользователей в
(Active Directory)
Internet
Внешние
пользователи
Рис. 8. Архитектура единой службы аутентификации, авторизации и учета пользователей
МГТУ им Н.Э. Баумана
http://sntbul.bmstu.ru/doc/681183.html
Основными элементами архитектуры являются:
·
Единая Служба ААА – является единой службой аутентификации
авторизации
и
учета
пользователей
информационных
ресурсов
Университета. В качестве источника учетных записей пользователей служба
использует
единый
каталог
пользователей
Университета
синхронизированный с кадровой информационной системой Университета
·
Информационные ресурсы – корпоративные приложения вуза, сервисы и
др. Помимо получения разрешения на доступ пользователя к ресурсу от
Единой Системы Аутентификации, информационные ресурсы могут сами
обращаться к единому хранилищу учетных записей пользователей, для
выборки дополнительной информации о пользователе и проведения
авторизации.
·
Механизмы
аутентификации
достаточных
для
проведения
–
набор
средств
аутентификации
аутентификации
пользователей
в
существующих корпоративными приложениях вуза. К ним относятся CAS,
RADIUS, NT Domain и LDAP.
·
VPN
туннель
–
защищенный
канал,
необходимый
для
доступа
пользователей к информационным ресурсам за пределами локальной сети
МГТУ им. Н.Э. Баумана.
УПРАВЛЕНИЕ УЧЕТНЫМИ ДАННЫМИ ПОЛЬЗОВАТЕЛЕЙ ЧЕРЕЗ
ЛИЧНЫЙ КАБИНЕТ
Централизованное управление учетными данными пользователей на уровне
Университета сопряжено с повседневным решением тяжелых и рутинных задач
управления учетными данными пользователей. К сожалению, даже при наличии единого
каталога пользователей отдельные атрибуты учетной записи пользователя периодически
приходится обновлять (пароль, контактных данные пользователя). Представляется
разумным, предоставить пользователю набор инструментов для управления своей учетной
записью.
Правила формирования логина и пароля учетной записи пользователя
В рамках внедрения системы с использованием модели ААА возникает
необходимость первичной выдачи пользователям их логинов и паролей. Целесообразным
Молодежный научно-технический вестник ФС77-51038
в данном случае является метод генерации логинов и паролей по установленным
правилам, при этом соблюдая политики безопасности. Для того, чтобы не выстраивать
очереди за получением учетных данных, сгенерированные логин и первичный пароль
должны быть изначально известны пользователю (содержать информацию которую
пользователь и создатель учетной записи знают, а все остальные нет).
Так, в качестве логина для сотрудников Университета можно использовать
комбинацию фамилии сотрудника, набранной латиницей и номера личного дела. Данный
номер знает каждый сотрудник, так как он написан на расчетном листке. Такое сочетание
сделает логин уникальным в рамках Университета. Пример логина сотрудника:
Ivanov05374.
Студенческим логином, по аналогии, может являться комбинация фамилии
студента и номера зачетки. Номер зачетки, к сожалению, не является уникальным в
рамках вуза, и может совпадать у отдельных студентов. Однако, в сочетании с фамилией
получается уникальный логин студента, соответствующий требованиям политики
безопасности Active Directory. Пример логина студента: Ivanov09u123.
В качестве первичного пароля можно использовать серию и номер паспорта
пользователя. Эти данные известны каждому студенту, аспиранту и сотруднику. Причем,
серия и номер паспорта берутся из кадровой и не обязательно являются актуальными но
вполне достаточными для использования в качестве первичного пароля. Так, если студент
или сотрудник сменил паспорт во время обучения или работы в вузе, то в новом паспорте
присутствует информация о серии и номере старого паспорта, поэтому эта информация
всегда известна ее владельцу. Поэтому если предложить пользователю на этапе первичной
регистрации ввести в качестве пароля серию и номер паспорта, которые содержатся в
кадровой системе, то это будет понятно владельцу и не очевидно для других. Возможно
использование других данных в качестве первичной генерации пароля. Главное, это
соблюдение принципа: «Первичный пароль это информация которая заведомо известна
владельцу и неочевидна для остальных». Если данный принцип генерации первичного
пароля вызывает недоверие с точки зрения безопасности и надежности, то следует
ограничить доступ к проведению первичной регистрации пользователями. Например
осуществлять первичную регистрацию только из внутренней сети вуза.
Таким образом использование генерации первичных пользовательских логинов и
паролей позволит быстро произвести первичную регистрацию пользователей и
обеспечить их доступом к личным кабинетам, для дальнейшего управления собственными
учетными записями.
http://sntbul.bmstu.ru/doc/681183.html
Процедура первичной регистрации пользователей в Единой Системе
Аутентификации. Получение BMSTU ID и назначение пароля.
Для проведения аутентификации пользователей в корпоративных приложениях
Университета предлагается использовать единый идентификатор – BMSTU ID. Данный
идентификатор состоит из связки фамилии и номера зачетки для студентов и фамилии и
номера личного дела для сотрудников.
Чтобы получить учетные данные, сотруднику или студенту необходимо пройти
процедуру первичной регистрации в системе. Страница регистрации пользователей
представлена на Рисунке 9:
Рис. 9. Страница регистрации нового пользователя в Единой Системе
Аутентификации
Молодежный научно-технический вестник ФС77-51038
В перечень обязательных данных для регистрации входят:
·
Фамилия и Имя
·
Пароль – пользователь указывает свой пароль, который он будет
использовать для авторизации в сервисах
·
Дата рождения – один из параметров, необходимый для подтверждения
личности пользователя
·
Email – почтовый ящик пользователя. Может использоваться любой
почтовый провайдер: bmstu.ru, mail.ru, yandex.ru и др. Необходим для
отправки рассылки, и указаний при восстановлении утерянного пароля
·
Серия
и
номер
паспорта
–
главный
параметр,
однозначно
подтверждающий личность пользователя
Указанные выше данные обязательны в заполнению обоим типам пользователей:
студентов и сотрудников. Дополнительной информацией для заполнения студентами
является Номер зачетки. Дополнительной информацией для заполнения сотрудниками
является Номер личного дела. Эта дополнительная информация необходима для
подтверждения личности пользователя.
При заполнении регистрационной формы недобропорядочному пользователю
сложно оценить какие из указанных параметров являются ключевыми в проведении
операции подтверждения личности пользователя.
После заполнения пользователем
его личных данных, на указанный им Email приходит письмо с ссылкой на страницу
активации, содержащую хеш ассоциированный с учетной записью. Это необходимо,
чтобы система, производящая активацию получила идентификатор учетной записи
пользователя.
Стоит отметить, что не смотря на то, что электронный ящик пользователя,
указанный при регистрации, будет использоваться для получения пользователем
рассылок, и восстановлении утерянного пароля, все операции, связанные с пользователем
производятся строго в личном кабинете пользователя, или с использованием сервисов
внутри вуза.
После того, как пользователь проходит по указанной ссылке, выполняется
процедура активации его учетной записи, и пользователь перенаправляется в личный
кабинет.
http://sntbul.bmstu.ru/doc/681183.html
При
первом
заходе
в
личный
кабинет
пользователю
отображается
его
идентификатор BMSTU ID, который является логином для авторизации в корпоративных
сервисах МГТУ им Н.Э. Баумана.
Таким образом, выполнив указанные выше шаги, сотрудник вуза или студент сами
выполняют регистрацию своей учетной записи, и получают логин и пароль для
авторизации в корпоративных приложениях вуза или входа в Личный кабинет
пользователя.
Преимуществами этого решения является отсутствие необходимости первичного
личного
получения
пользователями
паролей
для
входа
в
Личный
кабинет.
Использование единого хранилища учетных записей пользователей также решает
проблемы получения актуальных данных о сотрудниках и студентах вуза, что решает таки
проблемы, как например необходимость продевания студентами своих учетных записей
для использования Wi-Fi в вузе.
ВЫВОДЫ
Внедрение единой службы аутентификации, авторизации и учета пользователей
информационных ресурсов Университета с использованием модели ААА обеспечивает
эффективную реализацию многих бизнес-задач и позволяет в значительной степени
оптимизировать управление ИТ-инфраструктурой вуза.
Единый каталог пользователей Университета синхронизированный с кадровой
информационной системой Университета представляет собой надежный источник
информации о пользователях для единой службы аутентификации, авторизации и учета
пользователей информационных ресурсов.
Единая
служба
информационных
аутентификации,
ресурсов
Университета
авторизации
и
учета
представляет
собой
пользователей
обоснованный
и
достаточный набор инструментов обеспечивающий высокий уровень сервиса как для
разных категорий пользователей (локальных и удаленных), так и для различных категорий
информационных систем Университета
Использование
CAS
сервера
позволяет
производить
аутентификацию
пользователей в корпоративных веб-приложениях вуза, на основе справочника Active
Directory. Технология SSO, поддерживаемая CAS, позволяет использовать выданный
пользователю ticket для работы с множеством корпоративных приложений без
проведения повторного ввода логина и пароля пользователя в пределах одной сессии.
Молодежный научно-технический вестник ФС77-51038
Наряду
с
CAS
сервером
служба
должна
обеспечивать
возможность
аутентификации пользователей с использованием RADIUS сервера.
Управление учетными данными пользователей через личный кабинет включающее
процедуру первичной регистрации и дальнейшее обслуживание своей учетной записи
пользователем в Личном Кабинете существенно облегчает задачу администрирования
большого числа пользователей.
Список литературы
1. Рыбальченко М.А., Остриков С.П., «Разработка единой системы управления
пользователями в корпоративных приложениях Университета», Электронный
журнал «Молодежный научно-технический вестник» №04, апрель 2013.
2. «AAA
Overview»,
Cisco
IOS
Security
Configuration Guide,
URL:
http://www.cisco.com/en/US/docs/ios/12_2/security/configuration/guide/scfaaa.html,
(дата обращения 02.10.2013)
3. А. Шелупанов, С. Груздев, Ю. Назаев, «Аутентификация: теория и практика
обеспечения безопасного доступа к информационным ресурсам», Горячая линияТелеком, 2009 г.
4. «Описание модели Single Sign On», URL: http://en.wikipedia.org/wiki/Single_sign-on,
(дата обращения 02.10.2013).
5. «Remote Authentication Dial In User Service (RADIUS)», RFC 2865.
6. «RADIUS Accounting», RFC 2866.
7. Б. С. Гольдштейн, В. С. Елагин, Ю. Л. Сенченко, Протоколы ААА: RADIUS и
Diameter. Серия «Телекоммуникационные протоколы». Книга 9, СПб: БХВ –
Санкт-Петербург, 2011.
8. «CAS Architecture», URL: http://www.jasig.org/cas/cas2-architecture, (дата обращения
02.10.2013).
9. Dedra
Chamberlin,
«How
CAS
Works»,
URL:
https://wikihub.berkeley.edu/display/calnet/How+CAS+Works, Sep 03, 2009, (дата
обращения 02.10.2013)
10. Панин
И.,
«Корпоративные
VPN
на
базе
Cisco»,
журнал
«Системный
администратор», №6, 2009 г. – С. 78-84.
11. «Thin-Client
SSL
VPN
(WebVPN)
IOS
Configuration»,
URL:
http://www.cisco.com/en/US/products/ps6496/products_configuration_example09186a00
8072aa61.shtml. (дата обращения 02.10.2013).
http://sntbul.bmstu.ru/doc/681183.html
12. «Other
Security
Features
–
SSL
VPN»,
URL:
http://www.cisco.com/en/US/docs/ios/security/configuration/guide/sec_ssl_vpn.html.
(дата обращения 02.10.2013).
Молодежный научно-технический вестник ФС77-51038