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

У меня есть требование, при котором я должен заменить аутентификацию пользователя по умолчанию аутентификацией центрального сервера, то есть сервера SSO.
Отладив Drupal, я узнал, что все управление сессиями происходит в includes/session.incфайле. Я хочу сделать аутентификацию, как показано на рисунке:

СЦЕНАРИЙ: Вход в систему
Детали шагов будут:

1. Замените форму входа, чтобы отправить имя пользователя и пароль на сервер единого входа ( не на Drupal , а на .NET).
2. Аутентифицировать пользователя на сервере единого входа, используя базу данных этого сайта; и отправить ответ обратно на какую-то пользовательскую страницу PHP моего сайта (или форму с помощью модуля?).
3. Используя ответ, определите пользователя в таблице users и создайте сеанс для этого пользователя без проверки пароля (так как это будет означать двойную аутентификацию). По умолчанию Drupal устанавливает cookie с именем $insecure_session_nameпеременной и со значением $sid. Я хочу, чтобы Drupal не устанавливал здесь cookie, вместо этого отправлял значения переменных на сервер SSO.
4. Сервер единого входа примет значения, создаст cookie-файл и поместит его в основной домен domain.com(чтобы напомнить и то, my websiteи другое sso serverнаходится в поддомене основного домена, который также отсутствует в Drupal). Затем сайт drupal может войти в систему с помощью этого файла cookie.

Я знаю, что это сложный вопрос, я просто ищу указатели о том, как мне начать? как говорится "не стоит взламывать ядро". Итак, мои вопросы:

1. Где я должен искать, чтобы понять, как работает аутентификация Drupal и управление сессиями?
2. Есть ли способ, где я мог бы вызывать функции при includes/session.incиспользовании хуков (поскольку в комментариях к функциям говорится «только для внутреннего использования / не подлежит изменению»)?

ПРИМЕЧАНИЕ. Я буду использовать тот же метод для регистрации пользователя, чтобы запись оставалась в центральной базе данных сервера единого входа. И во время этого введет некоторый нежелательный пароль для того же пользователя в базе данных сайта Drupal (так как пароль не будет проверяться при входе в систему).

Drupal поддерживает внешнюю аутентификацию . Для Drupal существует множество альтернативных модулей аутентификации, таких как OpenID (входит в ядро), OAuth Connector или LDAP . Узнайте больше о том, как работает аутентификация Drupal; Лучше всего было бы взглянуть на модули OpenID и OAuth, а в основную форму входа отправить обратный вызов. Но, AFAIK, они всегда начинают нормальный сеанс Drupal после успешной аутентификации.

Для управления сессиями Drupal подключается к обработке сессий PHP и регистрирует свои собственные обработчики. Бэкенд сеанса Drupal сам по себе подключаемый, вы можете установить session_incпеременную по пути к файлу, обеспечивающему альтернативные реализации функций, найденных в includes/session.inc. Модуль memcache использует это для хранения сессии в memcached.

Для ссылок модуль OpenID обрабатывает успешную аутентификацию, в openid_authentication()которой сам прекращает работу и вызывает обработчик отправки формы входа пользователя (т.е. user_login_submit()). Этот обработчик отправки сам по себе прост, он загружает успешно аутентифицированного пользователя user_load()в глобальную $userпеременную, затем вызывает вызывающую user_login_finalize()сессию, метку времени входа в userтаблицу и вызывает hook_user_login()реализации.

Другим вариантом является использование user_external_login_register()функции. Функция регистрирует внешнего пользователя. При необходимости также создает локального пользователя. Если вам нужно больше контроля над созданием локального пользователя, вы всегда можете использовать user_save(), user_set_authmaps(), user_login_submit()и user_external_load()от вас заказа вызова, используя в user_external_login_register()качестве матрицы того , что должно быть сделано.

user_authenticate () APi может пригодиться здесь.

3. Используя ответ, определите пользователя в таблице пользователей и создайте сеанс для этого пользователя без проверки пароля (поскольку это будет означать двойную аутентификацию). По умолчанию Drupal устанавливает cookie с именем $insecure_session_nameпеременной и со значением $sid. Я хочу, чтобы Drupal не устанавливал здесь cookie, вместо этого отправлял значения переменных на сервер SSO.

РЕДАКТИРОВАТЬ: Как только SSO-сервер вернется с верным, используйте этот API для входа в систему пользователя, который автоматически позаботится о сессиях для вас. Я думаю, что лучше, если вы используете user_authenticate()вместо создания сессий самостоятельно. Это не должно создавать проблем даже при двойной аутентификации, если предоставляется действительный p-assowrd.

Не уверен в 4. Хотите ли вы, чтобы куки были видны в обоих доменах? Если так, то в settings.php инициализируй $cookie_domainдомен. Тогда куки на дочернем сайте будут доступны на родительском сайте.