Розуміння управління сеансом Drupal та аутентифікації користувачів

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

СЦЕНАРІО: Вхід
Інформація про кроки буде:

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

Я знаю, що це складний запит, я просто шукаю вказівники, як мені почати? як то кажуть, "не варто зламати ядро". Отже, мої запитання:

1. Де слід шукати, щоб зрозуміти, як глибоко працює аутентифікація Drupal та управління сеансами?
2. Чи є спосіб, коли я міг би викликати функції за includes/session.incдопомогою гачків (як в коментарях до функцій сказано "лише для внутрішнього використання / не змінювати")?

ПРИМІТКА: Я використовую той самий метод для реєстрації користувача, щоб запис залишався в центральній базі даних сервера SSO. І під час цього буде введено якийсь непотрібний пароль того ж користувача в базу даних 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.

EDIT: Після того, як сервер SSO повернеться з правдою, використовуйте цей API для входу в систему користувача, який автоматично піклується про сеанси для вас. Я думаю, що краще, якщо використовувати user_authenticate()замість того, щоб створювати сеанси самостійно. Він не повинен створювати проблеми навіть у подвійній аутентифікації, якщо надається дійсний p-assowrd.

Я не впевнений у 4. Ви хочете, щоб печиво було видно в обох доменах? Якщо так, то в settings.php ініціалізуйте $cookie_domainдо домену. Тоді файли cookie в підпільнику будуть доступні на батьківському сайті.