МИНИСТЕРСТВО НАУКИ И ВЫСШЕГО ОБРАЗОВАНИЯ РОССИЙСКОЙ

ФЕДЕРАЦИИ
ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ АВТОНОМНОЕ ОБРАЗОВАТЕЛЬНОЕ
УЧРЕЖДЕНИЕ ВЫСШЕГО ОБРАЗОВАНИЯ
«КАЗАНСКИЙ (ПРИВОЛЖСКИЙ) ФЕДЕРАЛЬНЫЙ УНИВЕРСИТЕТ»
ИНСТИТУТ ВЫЧИСЛИТЕЛЬНОЙ МАТЕМАТИКИ И ИНФОРМАЦИОННЫХ
ТЕХНОЛОГИЙ
КАФЕДРА ИНФОРМАЦИОННЫХ СИСТЕМ
Направление: 09.03.02 Информационные системы и технологии
Профиль: Информационные системы в образовании

ВЫПУСКНАЯ КВАЛИФИКАЦИОННАЯ РАБОТА

РАЗВИТИЕ СИСТЕМЫ ДИСТАНЦИОННОГО ОБУЧЕНИЯ КФУ И

ОБНОВЛЕНИЕ ИНТЕРФЕЙОВ КУРСОВ, РАЗВИТИЕ И ДОРАБОТКА
МОДУЛЕЙ СДО MOODLE НА PHP

Студент 4 курса
группы 09-561
"___"_________ 2019 г. ________________ (И.Г. Сунгатов)
Научный руководитель
канд. пед. наук, доцент
"___"_________ 2019 г. _________________ (Е.Е. Лаврентьева)
Заведующий кафедрой
канд. физ.-мат. наук, доцент
"___"_________ 2019 г. _________________ (Ф.М. Гафаров)

Казань – 2019
 Содержание

Оглавление
Содержание ................................................................................................................................................. 2
Введение ...................................................................................................................................................... 3
1. Теоретическая часть ................................................................................................................................ 5
1.1 Управление учетными записями и правами доступа ..................................................................... 5
1.2 Основные решения управления учетными записями пользователей и правами доступа .......... 8
1.3 Контроль за доступом ....................................................................................................................... 9
1.3.1 Аутентификация ............................................................................................................................. 9
1.3.2 Авторизация.................................................................................................................................... 9
1.3.3 Аудит ............................................................................................................................................. 10
1.4 Сквозная аутентификация (Single Sign-On) .................................................................................. 10
2. Обзор существующих стандартов и технологий .................................................................................11
2.1 SAML................................................................................................................................................ 11
2.2 X.509 ................................................................................................................................................. 12
2.3 Active Directory ................................................................................................................................ 12
2.4 LDAP ................................................................................................................................................ 13
2.5 Shibboleth ......................................................................................................................................... 15
3. Настройка LMS Moodle для автоматической авторизации ................................................................18
3.1 Общие сведения о платформе Moodle........................................................................................... 18
3.2 Использование СДО Moodle в КФУ .............................................................................................. 19
3.3 Интеграция LDAP ........................................................................................................................... 20
3.4 Интеграция Shibboleth .................................................................................................................... 23
3.5 Анализ .............................................................................................................................................. 26
Заключение ................................................................................................................................................27
Список использованных источников .......................................................................................................29
ПРИЛОЖЕНИЕ ............................................................................................................................................30

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

Дистанционные образовательные технологии активно внедряются в

КФУ с целью повышения эффективности учебного процесса и
продуктивности научно-исследовательской работы. Электронное обучение
применяется как в очном, так и в заочном обучении на различных уровнях: в
программах высшего образования, дополнительного образования, повышения
квалификации и профессиональной переподготовки кадров[1].

В больших системах электронного обучения возникает необходимость

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

Большое количество логинов с паролями для различных ресурсов

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

Актуальность данной дипломной работы обусловлена тем, что портал

КФУ состоит из нескольких сайтов, использующие разные системы

3
управления. У пользователя может быть несколько учетных записей на
каждую систему. На данный момент для авторизации пользователю
необходимо проходить аутентификацию независимо на каждом сайте портала
КФУ.

Целью дипломной работы является развитие системы дистанционного

обучения. Для этого были рассмотрены различные решения для доступа к
платформе Moodle, которую КФУ использует для дистанционного
образования, а также проведены исследование и настройка систем и
технологий для автоматической аутентификации.

4
 1. Теоретическая часть

1.1 Управление учетными записями и правами доступа

В современном мире задача управления учетными записями

пользователей и правами доступа к информации и корпоративным сервисам
становится все более актуальной.

По мере развития любой организации усложняется ее структура, растет

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

Эффективный механизм управления учетными записями и правами

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

Управление учетными записями и правами доступа (Identity & Access

Management, IAM) — это комплекс подходов, практик и специальных
программных средств, основной целью которых является обеспечение
защищенности информационных ресурсов и информационных систем
предприятия путем установления контроля за доступом пользователей к ним,
а также сокращение издержек предприятия, связанных с осуществлением
такого контроля[2].

При построении программных средств авторизации могут применяться

следующие схемы:

 децентрализованная схема;
 централизованная схема.

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

Рисунок 1. Децентрализованная схема

Децентрализованная схема (Рисунок 2) является наиболее часто

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

Использование децентрализованной схемы создает различные

проблемы:

• поскольку идентификационная информация повторяется для каждого

ресурса, это влечет за собой уменьшение контроля над
безопасностью данных и систем;
• необходимость управлять безопасностью в разных системах;

6
 • неудобства в запоминании большого числа паролей – пользователь
может использовать либо легкие пароли, либо записывать их на
листах бумаги, что ставит под угрозу безопасность его данных.

Рисунок 2. Централизованная схема

При втором подходе (Рисунок 2), основанном на централизованном

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

Благодаря своей централизованной инфраструктуре, данная схема

способна заменить децентрализованную систему, основанную на автономном
управлении как идентичностями, так и доступом. Она обеспечивает ряд
преимуществ:

• эффективный контроль безопасности;

• повышение прозрачности управления правами доступа;
• уменьшение количества паролей / учетных данных;
• большая гибкость при добавлении нового ресурса;

7
 • более эффективная организация, поскольку права доступа могут быть
быстро изменены.

В централизованной системе производительность и надежность системы

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

1.2 Основные решения управления учетными записями

пользователей и правами доступа

В зависимости от выполняемых функций управление учетными

записями и правами доступа можно разделить на следующие классы:

• управление учетными записями (User Administration and

Provisioning). Позволяют управлять идентификационными данными,
производить интеграцию с кадровыми системами. Синхронизируют
управление учетными записями и запрещают создание некорректных
записей;
• управление доступом (Identity Access Management). Предоставляют
возможности для контроля доступа пользователей к различным
системам. Обеспечивают выявление и предотвращение
несанкционированного доступа;
• управление удостоверениями (Identity and Access Governance).
Централизованный контроль прав доступа к системам, автоматизация
процессов согласования предоставления прав доступа;
• обеспечение единого доступа (Enterprise Single Sign On).
Обеспечивают возможность для централизованной аутентификации
пользователей. Исключают необходимость повторного ввода пароля
при входе в различные системы организации.

8
 Главной задачей управления учетными записями и правами доступа
является повышение производительности и безопасности системы, снижение
затрат и упрощение использования ресурсов для пользователей.

1.3 Контроль за доступом

Контроль доступа является ключевым аспектом сетевой

инфраструктуры. С помощью него можно контролировать, пользователи с
какими учетными данными могут войти в систему и какие ресурсы могут быть
фактически использованы после входа. Доступ к защищённой информации
должен предоставляться только авторизованным пользователям.

Термин AAA (от англ. Authentication, Authorization, Accounting)

используется для описания процесса предоставления доступа и контроля над
ним[3].

1.3.1 Аутентификация

С помощью аутентификации проверяется подлинность данных о

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

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

Следующий шаг при проверке пользовательского доступа - авторизация.

Этот процесс проверяет, к каким ресурсам и данным пользователь может
получить доступ. Система предоставляет пользователю только те права,
которые ранее ему были разрешены администратором. Фактически на этапе
авторизации проверяются его полномочия. Таким образом, с помощью

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

1.3.3 Аудит

Средства аудита фиксируют в системном журнале события, которые

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

1.4 Сквозная аутентификация (Single Sign-On)

Single Sign-On (SSO) - это особая форма проверки подлинности и

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

В технологии SSO пользователи, чтобы получить доступ к ресурсу от

поставщика услуг (Service Provider, SP), сначала перенаправляются к
поставщику идентификации (Identity Provider, IdP). Основной задачей
поставщика идентификации является передача достоверной информации о
пользователе в виде токена поставщику услуг. Поставщик услуг обновляет
статус аутентификации пользователя. Если аутентификация прошла успешно,
пользователи получают доступ к защищенному ресурсу.
Сквозная аутентификация имеет явные преимущества по сравнению с
традиционными решениями:
 удобство в использовании: пользователь не должен тратить время на
многократный ввод имени пользователя и пароля, чтобы получить
доступ к ресурсам;
 универсальность: пользователь может аутентифицироваться у
определенного поставщика идентификации, чтобы получить доступ
10
 к ресурсам, защищенным поставщиком услуг. Это дает возможность
увеличения количества поставщиков услуг, которые используют
такой же механизм доступа;
 безопасность: уменьшение количества паролей, а также хранение
данных о пользователе в единой базе для обеспечения безопасности
системы.

2. Обзор существующих стандартов и технологий

2.1 SAML

SAML (англ. security assertion markup language — язык разметки

декларации безопасности) — язык разметки, основанный на языке XML.
Открытый стандарт обмена данными аутентификации и авторизации между
участниками, в частности, между поставщиком учётных записей (англ. identity
provider) и поставщиком сервиса (англ. service provider)[4].

Данный стандарт состоит из следующих элементов:

• профили (profiles) — сочетание протоколов, утверждений и привязок

для решения определенных задач;
• привязки (bindings) — механизмы передачи запросов и ответов
SAML;
• протоколы (protocols) — определяют набор поддерживаемых
запросов и ответов;
• утверждения (assertions) — сведения о подлинности конечного
пользователя. Утверждения бывают трех видов: аутентификации,
авторизации и атрибутов.

Основной целью языка разметки SAML является обеспечение сквозной

аутентификации.

11
 2.2 X.509

Сертификат Х.509 — это набор стандартных полей, содержащих

сведения о пользователе или устройстве, и их соответствующий открытый
ключ. Стандарт Х.509 определяет, какие сведения входят в сертификат и как
они кодируются (формат данных) [5]. Сертификаты Х.509 соответствуют
международному стандарту ITU-T X.509[6].

Передаются сертификаты обычно через незащищенные каналы связи.

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

В X.509-сертификат входят ее версия, открытый ключ пользователя, имя

сертификата (Distungiushed Name, или DN), период действия, идентификатор
алгоритма подписи и цифровая подпись удостоверяющего центра.

Важную роль в обеспечении контроля регистрации и сопровождения

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

2.3 Active Directory

Active Directory (AD) - это служба каталогов корпорации Microsoft, с

помощью которой можно организовать эффективное управление сетевыми
ресурсами. Это структура, которая является необходимой в каждой ИТ-среде,
где важно централизованно управлять различными ресурсами, такими как
пользователи, рабочие группы, принтеры и т. д.

Структуру Active Directory можно логически разделить на три

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

12
организации может быть внешний и внутренний домены. Дерево состоит из
одного или нескольких доменов, которые совместно используют непрерывное
пространство имен. Эти домены связаны между собой иерархическим
образом, и различные контроллеры домена могут обмениваться данными друг
с другом. Контроллером домена называется сервер, который содержит Active
Directory. Лес, представляющий собой набор деревьев, является самым
верхним уровнем структуры.

В Active Directory данные пользователей хранятся в единой базе. При

изменении учётной записи любого пользователя вносимые изменения будут
видны во всей сети. Это существенно упрощает работу с системой.

С Active Directory используется упрощенный протокол доступа к

каталогам (Lightweight Directory Access Protocol, LDAP) для
централизованного хранения информации сетевого домена о проверке
подлинности и доступа к службам, с тем преимуществом, что вся эта
информация синхронизируется между различными серверами
аутентификации для доступа к сети.

Так как база данных находится на контроллере доменов Active Directory,

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

2.4 LDAP

LDAP (англ. Lightweight Directory Access Protocol —

«легкорасширяемый протокол доступа к каталогам») — протокол
прикладного уровня для доступа к службе каталогов X.500, разработанный
IETF как облегчённый вариант разработанного ITU-T протокола DAP[7].

13
 Протокол LDAP был введен с целью замены DAP (Directory Access
Protocol), поскольку последний был довольно обременительным по ресурсам.
LDAP использует TCP/ IP протокол.

Служба каталогов используется для ассоциации имен с объектами, где

каждый объект характеризуется рядом атрибутов, состоящих из имени и
набора значений. Службы каталогов оптимизированы для обращения к
объектам. Объектами в службе каталогов обычно являются элементы среды, в
которой используется служба. Например, пользователь, компьютер, принтер
или сетевые сервисы. Каждый объект содержит набор описывающих его
атрибутов. Таким образом, каталог представляет собой набор объектов, а
служба каталогов предназначена для управления этими объектами.

В LDAP информация организована иерархически (Рисунок 3), в

древовидной структуре, называемой информационным деревом каталога
(directory information tree, DIT). В DIT каждый узел представляет объект,
называемый записью (entry). Каждая запись в дереве представляет собой набор
атрибутов и идентифицируется с помощью своего уникального имени
(Distinguished Name, DN).

14
 Рисунок 3. Пример информационного дерева каталога(DIT)

У атрибута записи есть свой тип и одно или несколько значений

(Рисунок 3), например, cn используется для общих имен (cn=виталий), а ou
для обозначения организационного подразделения (ou=студенты). В корне
дерева можно найти запись, представляющую образовательное учреждение
(Domain Component, DC).

Значение специального атрибута ObjectClass в записи должно быть

именем класса объектов, а структура записи будет состоять из атрибутов,
определенных в этом классе объектов. Структура каждой записи не зависит от
других объектов и положения, в котором она находится на дереве.

2.5 Shibboleth

Shibboleth является межвузовским проектом, принадлежащий

консорциуму Internet2. Его целями являются разработка, спецификация и
внедрение систем с открытым исходным кодом для совместного

15
использования высшими учебными заведениями веб-ресурсов, которые
подлежат контролю доступа.

Этот проект был первоначально создан для упрощения доступа к

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

Shibboleth является одним из наиболее полных реализаций веб-системы

с открытым исходным кодом для автоматической аутентификации. Кроме
того, Shibboleth принял SAML для реализации большинства своих протоколов,
обеспечивая совместимость с другими системами, принадлежащими к области
управления идентификацией.

Архитектура Shibboleth включает в себя следующие элементы:

• Поставщик услуг (Service Provider, SP): система, управляющая веб-

ресурсом, к которому обращается пользователь;
• Поставщик идентификации (Identity Provider, IdP): объект, способный
аутентифицировать и предоставить достоверную информацию о
пользователе;
• User Agent (UA): это приложение, которое от имени пользователя
активирует протоколы автоматической аутентификации для доступа к
защищенному веб-ресурсу;
• Служба WAYF: служба, главной задачей которой является выбор своего
поставщика идентификации.

Между поставщиками не существует иерархии. Фактически, поставщик

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

Поставщик идентификации регистрирует пользователей и хранит

информацию о них, управляет сеансами проверки подлинности и отправляет
только необходимые данные поставщику услуг.

Поставщик услуг получает информацию, отправленную поставщиком

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

Механизм работы протокола автоматической аутентификации выглядит

следующим образом:

1. UserAgent (UA) требует доступа к веб-ресурсу у SP. Предполагается,

что UA не имеет активного сеанса с SP;
2. SP перенаправляет UA к WAYF или прямо к IdP. Содержимое URL-
адреса представляет собой запрос об аутентификации и содержит
информацию о запрошенном ресурсе, идентификаторе SP и конечной
точке, к которой SP намеревается получить утверждение
аутентификации;
3. если запрос поступает к WAYF, то он обрабатывает запрос и
запрашивает у пользователя IdP, который он намерен использовать.
Эта информация хранится в долгосрочном сеансе между WAYF и UA
(например, cookie). Затем WAYF перенаправляет UA на выбранный
пользователем IdP;
4. IdP идентифицирует пользователя с помощью механизма
аутентификации или использует для этого все еще активный сеанс;
5. затем IdP отправляет подтверждение об успешной аутентификации
SP с помощью SAML / POST;
6. в ответ SP запрашивает у IdP атрибуты пользователя;
7. после этого IdP отвечает на запрос атрибутов от SP;

17
 8. на основании информации о пользователе SP принимает решение о
доступе пользователя к запрашиваемому ресурсу и отправляет
соответствующий HTTP-ответ в адрес UA.

Для поддержки протоколов автоматической аутентификации

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

3. Настройка LMS Moodle для автоматической авторизации

3.1 Общие сведения о платформе Moodle

Система дистанционного обучения (СДО) Moodle (Modular Object-

Oriented Dynamic Learning Environment - модульная объектно-
ориентированная динамическая среда обучения) - это бесплатная и постоянно
развивающаяся система управления обучением (Learning Management System,
LMS) и система управления курсами (Course Management System, CMS),
которая позволяет создавать виртуальные классы для онлайн-обучения.

Тот факт, что это программное обеспечение является бесплатным и

простым в использовании, способствовал его быстрому распространению по
всему миру. Система переведена уже более чем на 80 языков. В основном СДО
Moodle используется учебными центрами, школами и университетами.

Платформа Moodle может быть установлена на любой платформе,

которая поддерживает Php, Apache и MySQL. Преимуществом СДО Moodle
является ее простота в адаптации и настройке интерфейса благодаря
возможности перемещения, удаления или добавления модулей. Система
использует каскадные таблицы стилей (CSS) и PHP, из-за чего можно
достаточно легко вносить изменения в пользовательский интерфейс.
18
 Платформа Moodle также обеспечивает расширенное управление
пользователями. Фактически, благодаря установке и интеграции MySQL
можно администрировать пользователей непосредственно в системе, разделяя
их на группы с возможностью назначения для каждого пользователя
атрибутов и пользовательских полей. СДО Moodle также позволяет добавлять,
редактировать или удалять пользователей. Есть возможность назначать роли
внутри платформы, где у каждой роли свои функции и разрешения на
определенные действия в системе.

Платформа Moodle управляет аутентификацией и авторизацией

пользователей и предоставляет различные способы доступа к своим ресурсам.
Возможны как регистрация пользователя по электронной почте, так и импорт
в базу данных пользователей через csv-файлы. Также были разработаны
плагины, позволяющие интегрировать различные системы аутентификации с
централизованным управлением: LDAP, Shibboleth, OAuth2, Mnet и другие.

3.2 Использование СДО Moodle в КФУ

Дистанционные образовательные технологии в КФУ позволяют

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

В настоящий момент в КФУ функционируют 2 площадки, работающие

на платформе LMS MOODLE:

 do.kpfu.ru – площадка для создания и тестирования курсов;

 edu.kpfu.ru – площадка, на которой происходит обучение студентов и
слушателей курсов, разработанных преподавателями[8].

Платформа электронного обучения КФУ управляется внутренним

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

19
обучения используется Moodle версии 3.3.5 на операционной системе Ubuntu
18.04.

В последние годы электронное обучение получило широкое развитие.

На площадке edu.kpfu.ru зарегистрированы тысячи пользователей. Она
включает множество активных курсов для всех студентов университета КФУ
из разных институтов, а также материалы для довузовского и дополнительного
образования.

3.3 Интеграция LDAP

Первая реализация, которую мы решили разработать, касалась

интеграции платформы Moodle со службой аутентификации LDAP.

Служба LDAP - это служба клиент-сервер, которая после интеграции

выступает в качестве посредника между пользователем и платформой Moodle.

Рисунок 4. Интеграция LDAP с платформой Moodle

Механизм работы LDAP можно увидеть на Рисунке 4:

1. пользователь запрашивает доступ к платформе электронного

обучения;

20
 2. платформа Moodle, которая в данном случае выступает в качестве
клиента, отправляет запрос на LDAP сервер;
3. сервер LDAP обрабатывает запрос, обращаясь к AD для
идентификации пользователя;
4. после идентификации сервер LDAP возвращает результаты и
атрибуты пользователя клиенту Moodle;
5. платформа Moodle распознает пользователя и разрешает ему доступ
к ресурсам.

Для выполнения этой интеграции было решено создать виртуальную

машину с операционной системой Ubuntu 16.04. Для настройки Moodle
необходимо было установить следующие пакеты:

• Apache2;
• MySQL;
• Php.

Затем необходимо установить сертификат SSL, который позволяет

приложению Moodle безопасно передавать информацию с помощью
протокола https.

После установки Moodle, необходимо было установить Php-Ldap

модуль, который является фундаментальным для работы с плагином Ldap,
установленным по умолчанию на платформе, выполнив следующую команду:

apt get php-ldap

После установки Php-Ldap модуля необходимо включить расширения,

чтобы подключить базы данных MySQL и LDAP к Php. Для этого нужно было
изменить файл php.ini, находящийся в /etc/php/7.0/apache2/php.ini и добавить
следующие строки кода:

extension=mysql.so

extension=gd.so

21
 extension=ldap.so

Для оптимального функционирования и правильной синхронизации

пользователей LDAP с системой Moodle также необходимо было правильно
настроить cron.

Для этого из терминала нужно открыть crontab:

crontab -u www-data –e

и вставить следующую строку:

*/1 * * * * /usr/bin/php /path/to/moodle/admin/cli/cron.php >/dev/null

Это позволяет перезагружать cron каждую минуту, обеспечивая

непрерывное обновление страниц. В первую очередь это важно для
оптимального взаимодействия модулей Moodle с электронной почтой.

После этого, чтобы разрешить синхронизацию пользователей,

необходимо было зайти в платформу в качестве администратора и, пройдя
путь «Администрирование» -> «Сервер» -> «Планировщик задачи» -> «Задача
синхронизации пользователей LDAP», ввести необходимые данные и
включить задачу для синхронизации.

Чтобы разрешить аутентификацию через LDAP, необходимо было

настроить плагин Moodle, предназначенный для управления аутентификацией
с сервером LDAP. Для этого нужно зайти на платформу Moodle и, пройдя путь
«Администрирование» -> «Плагины» -> «Аутентификация», включить
функцию «Сервер LDAP».

Далее должны быть введены следующие параметры:

• Параметры сервера LDAP (URL сервера, версия протокола LDAP);

• Параметры подключения (отличительное имя DN);
• Настройки поиска пользователей (тип учетной записи пользователя -
Active Directory; список контейнеров, в которых хранятся учетные
записи пользователей);
22
 • Сопоставление данных

Ниже представлен список с выбранными атрибутами:

• имя (givenName);
• фамилия (sn);
• атрибут пользователя (samaccountname);
• адрес электронной почты (mail);
• отдел (department);
• индивидуальный номер (employeeNumber).

После настройки студенты могут получить доступ к платформе, просто

введя свои учетные данные на странице входа. Затем происходит проверка
подлинности (через атрибут cn). Таким образом, он создаст учетную запись в
платформе электронного обучения, импортируя значения атрибутов,
полученных на этапе сопоставления данных.

Одним из преимуществ данного решения является синхронизация

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

3.4 Интеграция Shibboleth

После успешной проверки интеграции платформы Moodle со службой

аутентификации LDAP переходим к реализации интеграции с помощью
Shibboleth.

23
 Рисунок 5. Интеграция Shibboleth с платформой Moodle

Как видно на Рисунке 5, структура Shibboleth включает в себя:

 поставщик услуг (SP): система, которая управляет веб-ресурсом, к

которому обращается пользователь;
 поставщик идентификации (IdP): объект, главной задачей которого
является аутентификация пользователя.

Чтобы настроить поставщика услуг SP также нужна выделенная

виртуальная машина с операционной системой Ubuntu с установленной на ней
Moodle.

Для установки модуля Shibboleth нужно ввести команду:

sudo apt-get install libapache2-mod-shib2

Необходимо было создать сертификат с помощью службы SSL и

вставить в папку Shibboleth:

sudo openssl req -x509 -sha256 -nodes -days 3650 –newkey rsa:2048 -subj
"/CN=$HOSTNAME" -keyout /etc/shibboleth/sp-key.pem –out /etc/shibboleth/sp-cert.pem

Важно, чтобы сертификаты были затем указаны в конфигурационном

файле shibboleth2.xml.

24
 Для передачи информации доверенным поставщикам идентификации и
поставщикам услуг Shibboleth использует метаданные. Метаданные в
основном используются как ключ, который позволяет ассоциировать
поставщика идентификации с поставщиком услуг, и таким образом, позволить
пользователям получить доступ к ресурсу посредством IdP.

Метаданные поставщика идентификации IdP необходимо загрузить и

вставить в папку/var/run/shibboleth.

В файле shibboleth2.xml нужно было указать адрес SP в области entityID.

Также необходимо вставить ссылку, связанную с генерацией метаданных IdP,
в разделе MetadataProvider <type="XML" uri=”https ://idp.mytest.it/idp/shibboleth”…>.

Чтобы разрешить аутентификацию через Shibboleth, необходимо было

настроить его плагин. Для этого нужно на платформе Moodle в категории
Администрирование /Плагины/Аутентификация включить плагин Shibboleth.
В этом плагине важно указать логин, который будет использоваться для
проверки учетных записей, а также заполнить поля в категории
Сопоставление данных, как мы делали при настройке конфигурации LDAP.

Для того чтобы разрешить доступ к Moodle, необходимо было изменить

конфигурацию Apache2 для поддержки аутентификации Shibboleth.

Чтобы разрешить IdP сопоставлять атрибуты с LDAP нужно в файле

/etc/shibboleth/attribute-map.xml удалить комментарии блока <!-Examples of
LDAP-based attributes…-> .

Для настройки конфигурации IdP необходимо файл с метаданными SP в

xml формате вставить в папку /opt/shibboleth/metadata.

Затем нужно было изменить файл attribute-filter.xml, определяя атрибуты

пользователей, предназначенные для импорта в SP.

25
 Также необходимо модифицировать файл metadata-provider.xml, для
того чтобы указать путь, по которому берутся метаданные. Таким образом,
IdP распознает SP:

<MetadataProvider id="LocalMetadata"

xsi:type="FilesystemMetadataProvider"

metadataFile="path/sp-metadata.xml"/>

После того, как эти файлы были изменены и перезагрузки сервера,

пользователи могут аутентифицироваться через IdP.

3.5 Анализ

В тематической работе были исследованы и реализованы два типа

аутентификации: LDAP и Shibboleth. В обоих случаях удалось достичь цели
аутентификации пользователей на платформе Moodle.

Рассмотрим основные преимущества и недостатки обоих типов

аутентификации.

LDAP

Преимущества:

• интеграция автономным и быстрым способом, путем получения данных

непосредственно из AD и без необходимости сертификатов, метаданных
или запросов к внешним службам;
• простая установка модуля Php-LDAP и настройка конфигурации, а
также связывание атрибутов для доступа к платформе Moodle;
• много онлайн документации для настройки данной службы.

Недостатки:

• эта служба разрешает аутентификацию только в университетских

системах и не может использоваться для доступа к внешним ресурсам;
• в безопасности данных, так как сертификаты проверки не требуются.
26
 Shibboleth

Преимущества:

• лучшая безопасность благодаря конфигурации службы SSL и обмену

метаданными;
• удобный для пользователя доступ с учетными данными университета.

Недостатки:

• без настройки федерации служба разрешает аутентификацию только во

внутренних системах;
• мало документации по установке и настройке службы.

Благодаря использованным средствам аутентификации достигается

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

Заключение
СДО Moodle обретает все большую популярность в сфере электронного
обучения. Управление учетными записями пользователей и правами доступа
к информации в рамках системы играет немаловажную роль в ее развитии и
оптимизации.

В данной работе были исследованы и настроены службы

аутентификации LDAP и Shibboleth. Эти сервисы обеспечивают
централизованное управление доступом к платформе Moodle, уменьшая
административную нагрузку, связанную с управлением учетными данными и
доступом в рамках платформы электронного обучения. Таким образом, с
помощью данных служб можно автоматизировать процессы аутентификации
и решить проблему с дублированием пользовательских данных.

27
 Для дальнейшего развития в этом направлении можно реализовать
технологию федеративной аутентификации. С одной стороны, это дало бы
возможность доступа к информационным ресурсам университета сторонних
пользователей. С другой - пользователи университета смогут воспользоваться
не только внутренними системами, но и ресурсами других организаций,
которые размещены в федерации.

28
 Список использованных источников
1. Официальный сайт Казанского федерального университета
[Электронный ресурс]. – URL: https://kpfu.ru/open
2. Управление учетными записями и правами доступа [Электронный
ресурс]. - URL: http://insightsi.com/solutions-and-services/sistemy-
informatsionnoy-bezopasnosti/upravlenie-uchetnymi-zapisyami-i-pravami-
dostupa/
3. Протокол ААА [Электронный ресурс]. – URL:
https://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%BE%D1%82%D0%BE%
D0%BA%D0%BE%D0%BB_AAA
4. Язык разметки SAML [Электронный ресурс]. – URL:
https://ru.wikipedia.org/wiki/SAML
5. Циммерман Филипп – Введение в криптографию, 2004. – стр 6.
[Электронный ресурс]. – URL: https://elibrary-book.ru/bookread-228667/page-6
6. Стандарт X.509 [Электронный ресурс] – URL:
https://ru.wikipedia.org/wiki/X.509#%D0%98%D0%B5%D1%80%D0%B0%D1
%80%D1%85%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B0%D1
%8F_PKI
7. Протокол LDAP [Электронный ресурс]. - URL:
https://ru.wikipedia.org/wiki/LDAP
8. Официальный сайт КФУ. Общие сведения LMS MOODLE
[Электронный ресурс]. – URL: https://kpfu.ru/open/moodle-obuchenie-
konsultacii/obschie-svedeniya

29
 ПРИЛОЖЕНИЕ

Для аутентификации через службу LDAP необходимо настроить плагин

Moodle. На платформе Moodle на вкладке «Администрирование» ->
«Плагины» -> «Аутентификация» должна быть включена функция «Сервер
LDAP». Этот модуль нужен для считывания атрибутов пользователя из
cервера LDAP и заполнения полей в Moodle.

Для корректной работы модуля были заполнены следующие поля:

 URL сервера: ldap://<адрес сервера>;

 Версия протокола LDAP: 3;
 Кодировка LDAP: utf-8;
 Не кэшировать пароли: Да;
 Отличительное имя: cn=ldap-user;
 Тип учетной записи пользователя: MS ActiveDirectory;
 Атрибут пользователя: samaccountname;
 Имя: givenName;
 Фамилия: sn;
 Адрес электронной почты: mail;
 Отдел: department;
 Поиск в дочерних контейнерах: Да.

30