Topic outline

  • Collapse all Expand all

    • Мокрієв М.В.

      Національний університет біоресурсів і природокористування

      Використання Google LDAP для авторизації користувачів на сайті Moodle

      Організація допуску користувачів до ресурсів навчального порталу є однією з перших найважливіших справ, які потрібно вирішити при створенні навчального порталу вищого закладу освіти. І якщо за основу беремо таку систему як LMS Moodle, то вже маємо купу (“з коробки” це десять [1]) різних способів авторизації користувачів.

      Проте, є кілька важливих питань, на які потрібно відповісти, щоб вдало вибрати спосіб авторизації:

      1. Де буде розташовуватися база користувачів?

      Тут відповідь, буде залежати від того, яку саме систему ми будуємо.

      Якщо ми збираємося обмежити все лише навчальним порталом, то беремо за основу локальне розташування в тій же базі даних, що і власне система moodle.

      Якщо ж, наш навчальний портал це лише частинка з інформаційно-освітнього середовища навчального закладу, то логічно буде створити окрему базу користувачів, з якої буде відбуватися авторизація у всі частини такого інформаційно-освітнього середовища. Такою базою може бути реляційна реалізація на будь-якій СКБД або ієрархічна база на ldap сервері, або зовнішні хмарні сервіси, які підтримують авторизацію за стандартом OAuth 2. Такими, наприклад, є провайдери послуг Google, Microsoft, Facebook та LinkedIn.

      2. Другим важливим питанням є, чи будемо ми проводити централізовану реєстрацію всіх наших користувачів на навчальному порталі та в необхідних електронних навчальних курсах, чи дозволимо самореєстрацію за потребою?

      Якщо ми будуємо інформаційно-освітнє середовище з різнопланових компонентів, які хоча й можуть взаємно інтегруватися, проте є окремими компонентами з власною авторизацією, то кожен такий компонент не знає про своїх потенційних користувачів до моменту поки користувач не спробував авторизуватися тут вперше. Для частини підсистем інформаційно-освітнього середовища такий підхід є прийнятним, але для навчального порталу — ні. Оскільки, відповідно до навчального плану студенти повинні бути долученими до відповідних навчальних дисциплін та проходити їх визначений термін. А для цього викладачі або відповідальні особи повинні мати на сервері з moodle повний список студентів, яких потрібно зарахувати на курси, а також мати можливість проаналізувати навчальні здобутки всіх студентів. Поки що залишимо за дужками нововведення з індивідуальною траєкторією навчання, яка, проте, все одно ще залишає потребу бачити весь список студентів для аналізу як вибору так і результатів навчання.

      Постановка проблеми. Відповідаючи на наведені вище питання з вибору способу створення бази користувачів та авторизації на навчальному поталі ми можемо прийти до певного роду конфлікту між нашими потребами. Для викладення наступних міркувань визначимо, що ми хочемо використовувати сервіс зовнішнього провайдера Google для ведення бази користувачів. Цей вибір зумовлено доєднанням навчального закладу до сервісу Google Workspace for Education та використанням сервісів, які надаються закладам в цьому пакеті, на рівні з можливостями власне moodle.

      Цей вибір дозволяє нашим користувачам (як студентам так і викладачам) авторизуватися в різних частинах нашого інформаційно-освітнього середовища використовуючи свій університетський обліковий запис з Google Workspace. Проте, тих студентів, яких адміністратор Google Workspace додасть до користувачів, викладачі на moodle не зможуть побачити та додати до своїх курсів доки студенти не зайдуть хоча б раз на навчальний портал. І тут потрібно враховувати, що ми повинні обліковувати навіть тих студентів, які поступили але з певних причин так і не приступили до навчання. Отже, їх все одно потрібно бачити в списках студентів, навіть з позначкою “ніколи не заходили”.

      Далі розберемося, як можна подолати таку проблему.

      Виклад матеріалу.

      Відразу відзначимо, що спосіб авторизації через OAuth 2 чудово підійде на інших підсистемах нашого інформаційно-освітнього середовища, де користувачі не обов’язково повинні бути представленими у списку користувачів, де користувачі самі зацікавлені в авторизації для подальшої роботи. Цей же спосіб підійде для авторизації викладачів на навчальному порталі, оскільки, знову ж таки, викладачі зацікавлені і зобов’язані зайти, щоб почати свою роботу з навчальними матеріалами та студентами на свої курсах.

      Проблема виникає саме зі список студентів. Хотілося б мати можливість один раз завести студентів як користувачів Google Workspace та далі мати їхній список доступним для курсів moodle. Проте, OAuth 2 не дає нам можливості забрати список з хмарного сервісу і в подальшому проводити синхронізацію для актуалізації списку.

      Але модулі авторизації moodle із зовнішніх баз даних таку можливість дають. Зокрема, якщо ми використовуємо ldap сервер як базу користувачів, то ми можемо здійснювати синхронізацію списку користувачів із ldap та внутрішнім списком у moodle [3].

      Для того, щоб досягти бажаної мети, мати єдину базу користувачів на Google та синхронізувати її з локальною таблицею користувачів у moodle, ми маємо можливість використовувати сервіс LDAP, який Google надає своїм клієнтам Workspace [4].

      Для ведення користувачів у адміністратора Google Workspace нічого не змінюється. Як і до цього створюється ієрархічна база користувачів (рис.1)

      Рисунок 1 - Ієрархія користувачів у базі Google.

      Але для гілки студентів підключаємо сервіс Secure LDAP (рис 2), який адміністратор може знайти в меню Додатки. Підключення цього сервісу вимагатиме вказати, до якої гілки (в термінології Google це “організаційний підрозділ”) в базі користувачів потрібно дозволити його використання. Оскільки нас в подальшому цікавитиме лише список студентів, то потрібно вказати саме цю гілку. Викладачі будуть реєструватися за OAuth 2.

      Також, потрібно згенерувати сертифікат доступу та користувача, якому надаватиметься право читати цей список LDAP користувачів.

      Рисунок 2 - Підключення Secure LDAP до бази користувачів

      Наступним кроком необхідно налаштувати під'єднання модуля ldap автентифікації у moodle.

      Тут важливо вказати, що ми приєднуємося саме до сервера LDAP Google та вказати ім’я та пароль спеціального користувача, який нам згенерував сервіс Google (рис 3.)

      Рисунок 3 - Налаштування підключення до LDAP в moodle

      Також, для правильного перенесення даних студентів з Google LDAP до локального списку Moodle потрібно налаштувати синхронізацію полів:

      • ім’я — givenName
      • прізвище — sn
      • електронна пошта — mail
      • індивідуальний номер — employeeNumber

      В результаті після запуску moodle процесу синхронізації користувачів з сервісом Google LDAP, всі заведені адміністратором студенти будуть доступні по списку на сайті moodle.

      Після видалення адміністратором студентів із сервісу Google відповідні дії (блокування або повне видалення, в залежності від налаштувань) будуть виконані і з локальним списком на moodle.

      Студенти зможуть заходити до навчального порталу свого закладу використовуючи свою університетську пошту (надану в рамках Google Workspace) та той же пароль, що і на цій пошті.

      На інші підсистеми нашого інформаційно-освітнього середовища для студентів та викладачів налаштовується однаковий вхід через OAuth 2.

      Таким чином ми досягаємо використання єдиної бази користувачів для адміністрування та імітації єдиної точки входу для користувачів.

      Використовуючи сервіс Google Secure LDAP ми отримуємо також ще одну можливість роботи з групами Google. За допомогою використання додаткового до moodle модуля LDAP syncing scripts [5] ми можемо також синхронізовувати групи з LDAP та гурти (cohorts) в moodle (рис.4). Таким чином, ми можемо повноцінно використовувати групи в Google зі всіма їх можливостями, а також автоматично отримувати ці групи, разом зі списком їх учасників до системи moodle. Отже, адміністраторам студентських груп не доведеться робити подвійну роботу заводячи студентів в групи і на Google і в moodle.

      Рисунок 4 - Налаштування модуля LDAP syncing scripts

      Висновки. Використання сервісу Google Secure LDAP надає нам додаткові можливості у спрощенні адміністрування користувачів інформаційно-освітнього середовища навчального закладу за рахунок ведення єдиної бази користувачів. Проте, на відміну від способу автентифікації за допомогою OAuth 2, такий спосіб надає також можливість синхронізувати користувачів з локальним списком moodle, що є важливим компонентом ведення навчальної підготовки студентів через навчальний портал та дає можливість будувати коректні навчальні звіти.

      Проте, необхідно сказати, що цей сервіс від Google не є в повній мірі зручним та масштабованим. Хоча Google надає можливість додати власні необхідні поля облікових записів, вони є обмеженими по функціональності та проблемними з доступу до них через LDAP. А це значить, що подальші дослідження та доопрацювання технології повинні проводитися.

      Список використаних джерел

      1. Authentication. Authentication plugins. Moodle documentation. URL: https://docs.moodle.org/404/en/Authentication

      2. Google Workspace for Education. URL: https://edu.google.com/

      3. Authentication. LDAP authentication. Moodle documentation. URL: https://docs.moodle.org/404/en/LDAP_authentication#User_account_synchronisation

      4. About the Secure LDAP service. Google Workspace Admin Help. URL: https://support.google.com/a/answer/9048516

      5. LDAP syncing scripts. Moodle plugins directory. URL: https://moodle.org/plugins/local_ldap

      6. Learn about Google Groups. Google Groups Help. URL: https://support.google.com/groups/answer/46601

    • Forum icon
      Форум обговорення доповіді Forum
    • Forum icon
      Оголошення Forum