Здравствуйте. Я был озадачен подобной темой ещё лет семь назад, поэтому расскажу вам об эволюции в своих представлениях об этой теме. Пара плагинов аутентификации были моими первыми разработками для moodle 1.9
Когда я делал первую связку между ИС вуза и moodle, думал примерно также как и вы. Я сразу перешагнул попытку подключаться из moodle к бд ИС соответствующим модулем moodle, чтобы системы могли быть максимально автономными и мобильными, легко сосуществую даже будучи разделенными брандмауэром. Единственное, что я использовал GET-запросы, но это неправильный вариант, так как логины/пароли в этом случае фиксируются в логах прокси и веб-серверов, а это не очень правильно - получив доступ к файлу лога веб-сервера можно получить пароль админа в чистом виде. Но я просто отключил логгирование в веб-сервере.
Основные ошибки этого подхода в следующем: пароли вообще никогда не должны передаваться в открытом виде между системами. Любое предложение одной системы использовать пароль от другой системы - уже угроза безопасности, даже если обе системы ваши. Так, например, для одного проекта, когда не было доступа к базе данных сотрудников, я делал следующим образом: плагин запрашивал логин/пароль, обращался на другой сайт с этим логином/паролем, и в случае, если он подходил, парсил страницу, находил место, выводится Фамилия и Имя текущего пользователя и обновлял этими данными текущего пользователя. Для пользователя это выглядит как использование одних и тех же учетных данных в двух системах, но на деле это настоящее воровство паролей.
Поэтому нормальные системы всегда делают проверку паролей сами. Для примера vk и google. Как это должно работать: Когда вы заходите в систему, вас перебрасывает на сервер авторизации вашей ИС. При этом в запросе передается адрес, куда вернуть данные. Внешняя система проверяет адрес для возвращения данных по списку доверенных систем, и если он из списка, отображает форму проверки логина/пароля. После этого ИС возвращает по адресу для возвращения данных некий секретный токен в get-запросе. В зависимости от реализации токен может сразу содержать данные пользователя и электронную цифровую подпись (хэш-сумму) информационной системы, а может только некий идентификатор сессии. ЭЦП нужна, чтобы нельзя было подделать ответ ИС и зайти в moodle от имени другого пользователя. Если передается только идентификатор сессии, то moodle обращается с ним в ИС по альтернативному каналу (минуя браузер пользователя), проверяет, действительно ли логин/пароль проверялся, и забирает данные пользователя.
Преимущество этого способа в том, что вы можете сделать совершенно иную страницу проверки логина/пароля. Например, предложив студенту выбрать факультет, группу, номер зачетки из списка и указать дату рождения в качестве пароля. Сомнительна потребность, но в moodle таких изощренных вариантов точно не сделать. Минус в том, что сложнее в реализации и если вы захотите таким образом авторизовать несколько систем, то придется писать плагин авторизации для нескольких из них.
Я реализовывал и первый, и второй способ. Но вот в чем беда - когда у вас только ИС и Moodle, то можно увязать множеством способов. Когда у вас появляются дополнительные системы, а они точно начнут появляться, добавлять каждую новую систему становится всё сложнее, потому у всех авторизация сделана по-разному. Дополнительные системы это, к примеру, портал вуза (есть решение на битриксе), система портфолио, рейтинг студентов и ещё больше систем для преподавателей. Многие и этих систем закрыты и вы просто не сможете к ним приспособить указанные выше способы авторизации.
Поэтому сейчас я могу вам сказать следующее - вам нужен LDAP-сервер. Можно открытый, можно Active Directory. Ваша ИС должна записывать данные пользователей на этот сервер, а он уже должен служить источником для авторизации как для moodle, так и для других будущих систем - все нормальные системы работают с ldap. В будущем, если вы увидите, что какая-то система не работает с ldap (хотя бы в корпоративной версии), бегите прочь от этой системы, это какая-то несерьёзная разработка. У LDAP есть ещё одно преимущество. Вы можете в одной системе собрать учетный данные из совершенно разнородных систем. Если у вас разные базы данных для студентов, преподавателей и сотрудников вуза, каждая из этих систем может выложить эти логины/пароли в LDAP, а оттуда любая система их может забрать.
Правда у LDAP тоже есть недостатки. Большинство реализаций LDAP-аутентификации в разных системах подразумевает, что логин пользователя является постоянным и является ключевым полем. Но на практике это не так. Пользователь может сменить фамилию (если логин связан с фамилией), номер зачетки, читательского билета, перейти на другую специальность (если логин связан с чем-то из перечисленного) и т.п. Если логины в вашей ИС НИКОГДА не меняются, то всё хорошо. В идеале логин должен быть ни к чему не привязанным набором цифр, причем менять под себя должно быть запрещено даже админам системы.
Но у нас иначе. А плагин LDAP moodle при смене логина создаст новую учетку, а не переименует старую. Единственный обход - это если админ изменит логин пользователя разом во всех системах при смене его в ldap - но систем много и это может стать проблемой. Ну или сделать свой плагин аутентификации, который грамотно разрулит эту ситуацию. И тут мы возвращаемся к тому, с чего начали. Замкнутый круг.
Теперь ответы на ваши вопросы
1. Для отправки на другой сервер запроса используйте расширение PHP curl.
2. В отличие Javascript и node.js, php - это синхронный язык программирования. Он итак будет ждать ответа сервера при выполнении скрипта, а в случае долгого отсутствия ответа выдаст ошибку curl. Поэтому таймаут лучше ставить небольшой, секунд 10-30.
И ещё замечание. С учетом того, что система у вас, видимо, самодельная, то и сбои в её работе возможны, что приведет к невозможности входа в moodle. Если вы станете хранить пароли в moodle, то сможете проверять по ним в случае отсутствия связи с ИС. Стандартные плагины мудла не реализуют такой функционал, но в самодельном вы можете это реализовать. Так, например, после очередной перенастройки сети у меня выяснилось, что нет связи между moodle и ИС только недели через две от двоечников, которые ни разу не входили в систему до этого, а так бы 100% пользователей не смогли бы пользоваться системой до решения проблемы. LDAP-сервер тоже решает эту проблему, так как работает, даже когда ваша ИС не работает, плюс можно поднять два сервера и настроить между ними репликацию. В случае AD достаточно двух контроллеров домена, репликация будет автоматом.
Когда решите, каким путем идти, смогу подсказать что-то более конкретное. И все вопросы задавайте на форуме
